Skip to main content
Version: 1.17

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.

info

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.