Configuring Custom Certificates

Administrators can configure custom serving certificates for the public host names of the OKD API and web console. This can be done during a cluster installation or configured after installation.

If a certificate chain is used, then all certificates must be manually concatenated into a single named certificate file. These certificates must be placed in the following order:

To create this certificate chain, concatenate the certificates into a common file. You must run this command for each certificate and ensure that they are in the previously defined order.

During cluster installations, custom certificates can be configured using the openshift_master_named_certificates and openshift_master_overwrite_named_certificates parameters, which are configurable in the inventory file. More details are available about configuring custom certificates with Ansible.

Example parameters for a master API certificate:

Example parameters for a router wildcard certificate:

You can specify custom certificates for the web console and for the CLI through the servingInfo section of the master configuration file:

You can configure multiple certificates this way, and each certificate can be associated with multiple host names, multiple routers, or the OKD image registry.

A default certificate must be configured in the servingInfo.certFile and servingInfo.keyFile configuration sections in addition to namedCertificates.

The openshift_master_cluster_public_hostname and openshift_master_cluster_hostname parameters in the Ansible inventory file, by default /etc/ansible/hosts, must be different. If they are the same, the named certificates will fail and you will need to re-install them.

For more information on using DNS with OKD, see the DNS installation prerequisites.

This approach allows you to take advantage of the self-signed certificates generated by OKD and add custom trusted certificates to individual components as needed.

Note that the internal infrastructure certificates remain self-signed, which might be perceived as bad practice by some security or PKI teams. However, any risk here is minimal, as the only clients that trust these certificates are other components within the cluster. All external users and systems use custom trusted certificates.

Relative paths are resolved based on the location of the master configuration file. Restart the server to pick up the configuration changes.

In order to facilitate trusted connections with external users of OKD, you can provision a named certificate that matches the domain name provided in the openshift_master_cluster_public_hostname paramater in the Ansible inventory file, by default /etc/ansible/hosts.

You must place this certificate in a directory accessible to Ansible and add the path in the Ansible inventory file, as follows:

Where the parameter values are:

The file paths must be local to the system where Ansible runs. Certificates are copied to master hosts and are deployed within the /etc/origin/master directory.

When securing the registry, add the service hostnames and IP addresses to the server certificate for the registry. The Subject Alternative Names (SAN) must contain the following.

For example, the server certificate should contain SAN details similar to the following:

You can configure the OKD default router with a default wildcard certificate. A default wildcard certificate provides a convenient way for applications that are deployed in OKD to use default encryption without needing custom certificates.

To configure a default wildcard certificate, provision a certificate that is valid for *.<app_domain>, where <app_domain> is the value of openshift_master_default_subdomain in the Ansible inventory file, by default /etc/ansible/hosts. Once provisioned, place the certificate, key, and ca certificate files on your Ansible host, and add the following line to your Ansible inventory file.

For example:

Where the parameter values are:

If these certificate files are new to your OKD cluster, run the Ansible deploy_router.yml playbook to add these files to the OKD configuration files. The playbook adds the certificate files to the /etc/origin/master/ directory.

If the certificates are not new, for example, you want to change existing certificates or replace expired certificates, run the following playbook:

The OKD image registry is an internal service that facilitates builds and deployments. Most of the communication with the registry is handled by internal components in OKD. As such, you should not need to replace the certificate used by the registry service itself.

However, by default, the registry uses routes to allow external systems and users to do pulls and pushes of images. You can use a re-encrypt route with a custom certificate that is presented to external users instead of using the internal, self-signed certificate.

To configure this, add the following lines of code to the [OSEv3:vars] section of the Ansible inventory file, by default /etc/ansible/hosts file. Specify the certificates to use with the registry route.

If your OKD cluster uses the default load balancer or an enterprise-level load balancer, you can use custom certificates to make the web console and API available externally using a publicly-signed custom certificate. leaving the existing internal certificates for the internal endpoints.

To configure OKD to use custom certificates in this way:

For information specific to your load balancer environment, refer to the OKD Reference Architecture for your provider and Custom Certificate SSL Termination (Production).

You can retrofit custom master and custom router certificates into an existing OKD cluster.

For information on how other components, such as Logging & Metrics, use custom certificates, see Certificate Management.