Bringing Your Own Certificates
Bring your own Wildcard Certificate
By default, Okteto will create a self-signed wildcard certificate for your cluster. This certificate is used to secure communication to the Okteto UI, the build service, the registry service, and to all the applications that use Automatic SSL Endpoints.
In a production environment, you should use your own certificates rather than let Okteto create a self-signed wildcard certificate for you. You can configure this via the wildcardCertificate
configuration key in your Helm configuration file.
Use cert-manager and Let’s Encrypt
Let’s Encrypt is a free, automated, and open Certificate Authority. Certificates can be automatically requested using various tools. A very popular way of requesting certificate from Let's Encrypt is by using cert-manager.
When using cert-manager, you need to use a DNS01 auth method in your Issuer, since Okteto requires a wildcart certificate. Check the list of supported providers here for more information.
Our community maintains guides on how to use cert-manager together with different Cloud Providers to generate certificates for Okteto:
You can also check out our video tutorial on how to configure certificates for your Okteto installation using cert-manager and Let's Encrypt:
Use your own wildcard certificate
For this, you'll need the private and public keys of your certificate. The certificate must be a PEM-encoded X.509 certificate in PKCS1 format, with *.SUBDOMAIN
as its Subject Alternative Name
.
Import the secret into your kubernetes cluster by running the command below:
kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE} --namespace okteto
After you create the secret, add the following to your Helm configuration file to tell Okteto and NGINX to use your certificate.
wildcardCertificate:
create: false
name: your-ssl-certificate-secret
ingress-nginx:
controller:
extraArgs:
default-ssl-certificate: $(POD_NAMESPACE)/your-ssl-certificate-secret
You can use any certificate provider you are familiar with if it's compatible with the x.509 and PKCS1 standards. Our community maintains guides for the following certificate providers:
Finally, upgrade your Okteto installation for the new configuration to be applied.
If publicOverride
is set, its value must also be included in the certificate's Subject Alternative Name
list. For example, if you use dev.example.com
as the publicOverride
, and okteto.net
as the subdomain
, you need to generate a certificate that includes *.okteto.net
and dev.example.com
in the Subject Alternative Name
list.
Bring your own Certificate Authority
By default, Okteto will trust a certificate issued by any well-know certificate authority. If your certificate is self-signed, issued by a new certificate authority, or issued by a private certificate authority, you'll need to import your certificate authority's public key.
First import your certificate authority by running the command below:
kubectl create secret generic ${CA_NAME} --from-file=ca.crt=${CA_FILE} --namespace okteto
After you create the secret, add the following to your Helm configuration file to tell Okteto to use your certificate authority.
wildcardCertificate:
create: false
name: your-ssl-certificate-secret
privateCA:
enabled: true
secret:
name: your-ca-secret
key: ca.crt
ingress-nginx:
controller:
extraArgs:
default-ssl-certificate: $(POD_NAMESPACE)/your-ssl-certificate-secret
Finally, upgrade your Okteto installation for the new configuration to be applied.