Configuring Custom Certificates

Overview

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.

Configuring a Certificate Chain

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:

  • OKD master host certificate

  • Intermediate CA certificate

  • Root CA certificate

  • Third party certificate

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.

  1. $ cat <certificate>.pem >> ca-chain.cert.pem

Configuring Custom Certificates During Installation

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.

Custom Certificate Configuration Parameters

  1. openshift_master_overwrite_named_certificates=true (1)
  2. openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}] (2)
  3. openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} (3)
1If you provide a value for the openshift_master_named_certificates parameter, set this parameter to true.
2Provisions a master API certificate. If necessary, concatenate all of the required files that form your certificate chain for the certificate file that is provided to the certFile parameter.
3Provisions a router wildcard certificate.

Example parameters for a master API certificate:

  1. openshift_master_overwrite_named_certificates=true
  2. openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master-bundle.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem"}]

Example parameters for a router wildcard certificate:

  1. openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}

Configuring Custom Certificates for the Web Console or CLI

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

  • The servingInfo.namedCertificates section serves up custom certificates for the web console.

  • The servingInfo section serves up custom certificates for the CLI and other API calls.

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 namedCertificates section should be configured only for the host name associated with the masterPublicURL and oauthConfig.assetPublicURL settings in the /etc/origin/master/master-config.yaml file. Using a custom serving certificate for the host name associated with the masterURL will result in TLS errors as infrastructure components will attempt to contact the master API using the internal masterURL host.

Custom Certificates Configuration

  1. servingInfo:
  2.   logoutURL: ""
  3.   masterPublicURL: https://openshift.example.com:8443
  4.   publicURL: https://openshift.example.com:8443/console/
  5.   bindAddress: 0.0.0.0:8443
  6.   bindNetwork: tcp4
  7.   certFile: master.server.crt (1)
  8.   clientCA: ""
  9.   keyFile: master.server.key (2)
  10.   maxRequestsInFlight: 0
  11.   requestTimeoutSeconds: 0
  12.   namedCertificates:
  13.     - certFile: wildcard.example.com.crt (3)
  14.       keyFile: wildcard.example.com.key (4)
  15.       names:
  16.         - "openshift.example.com"
  17.   metricsPublicURL: "https://metrics.os.example.com/hawkular/metrics"
1Path to the certificate file for the CLI and other API calls.
2Path to the key file for the CLI and other API calls.
3Path to the certificate file for the public host names of the OKD API and web console. If necessary, concatenate all of the required files that form your certificate chain for the certificate file that is provided to the certFile parameter.
4Path to the key file for the public host names of the OKD API and web console.

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.

  1. # Native HA with External LB VIPs
  2. openshift_master_cluster_hostname=internal.paas.example.com
  3. openshift_master_cluster_public_hostname=external.paas.example.com

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.

Configuring a Custom Master Host Certificate

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:

  1. openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]

Where the parameter values are:

  • certfile is the path to the file that contains the OKD custom master API certificate.

  • keyfile is the path to the file that contains the OKD custom master API certificate key.

  • names is the cluster public hostname.

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.

  • Two service hostnames:

    1. docker-registry.default.svc.cluster.local
    2. docker-registry.default.svc

  • Service IP address.

    For example:

    1. 172.30.252.46

    Use the following command to get the container image registry service IP address:

    1. oc get service docker-registry --template='{{.spec.clusterIP}}'

  • Public hostname.

    1. docker-registry-default.apps.example.com

    Use the following command to get the container image registry public hostname:

    1. oc get route docker-registry --template '{{.spec.host}}'

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

  1. X509v3 Subject Alternative Name:
  2.                DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98

Configuring a Custom Wildcard Certificate for the Default Router

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.

Default wildcard certificates are recommended for non-production environments only.

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.

  1. openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}

For example:

  1. openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}

Where the parameter values are:

  • certfile is the path to the file that contains the OKD router wildcard certificate.

  • keyfile is the path to the file that contains the OKD router wildcard certificate key.

  • cafile is the path to the file that contains the root CA for this key and certificate. If an intermediate CA is in use, the file should contain both the intermediate and root CA.

If these certificate files are new to your OKD cluster, change to the playbook directory and 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.

  1. # ansible-playbook [-i /path/to/inventory] \
  2.     ~/openshift-ansible/playbooks/openshift-hosted/deploy_router.yml

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

  1. ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
For this playbook to run, the certificate names must not change. If the certificate names change, rerun the Ansible deploy_cluster.yml playbook as if the certificates were new.

Configuring a Custom Certificate for the Image Registry

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.

  1. openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com (1)
  2. openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"} (2)
  3. openshift_hosted_registry_routetermination=reencrypt (3)
1The host name of the registry.
2The locations of the cacert, cert, and key files.

  • certfile is the path to the file that contains the OKD registry certificate.

  • keyfile is the path to the file that contains the OKD registry certificate key.

  • cafile is the path to the file that contains the root CA for this key and certificate. If an intermediate CA is in use, the file should contain both the intermediate and root CA.

3Specify where encryption is performed:

  • Set to reencrypt with a re-encrypt route to terminate encryption at the edge router and re-encrypt it with a new certificate supplied by the destination.

  • Set to passthrough to terminate encryption at the destination. The destination is responsible for decrypting traffic.

Configuring a Custom Certificate for a Load Balancer

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:

  1. Edit the servingInfo section of the master configuration file:

    1. servingInfo:
    2.   logoutURL: ""
    3.   masterPublicURL: https://openshift.example.com:8443
    4.   publicURL: https://openshift.example.com:8443/console/
    5.   bindAddress: 0.0.0.0:8443
    6.   bindNetwork: tcp4
    7.   certFile: master.server.crt
    8.   clientCA: ""
    9.   keyFile: master.server.key
    10.   maxRequestsInFlight: 0
    11.   requestTimeoutSeconds: 0
    12.   namedCertificates:
    13.     - certFile: wildcard.example.com.crt (1)
    14.       keyFile: wildcard.example.com.key (2)
    15.       names:
    16.         - "openshift.example.com"
    17.   metricsPublicURL: "https://metrics.os.example.com/hawkular/metrics"
    1Path to the certificate file for the public host names of the OKD API and web console. If necessary, concatenate all of the required files that form your certificate chain for the certificate file that is provided to the certFile parameter.
    2Path to the key file for the public host names of the OKD API and web console.

    Configure the namedCertificates section for only the host name associated with the masterPublicURL and oauthConfig.assetPublicURL settings. Using a custom serving certificate for the host name associated with the masterURL causes in TLS errors as infrastructure components attempt to contact the master API using the internal masterURL host.

  2. Specify the openshift_master_cluster_public_hostname and openshift_master_cluster_hostname paramaters in the Ansible inventory file, by default /etc/ansible/hosts. These values must be different. If they are the same, the named certificates will fail.

    1. # Native HA with External LB VIPs
    2. openshift_master_cluster_hostname=paas.example.com (1)
    3. openshift_master_cluster_public_hostname=public.paas.example.com (2)
    1The FQDN for internal load balancer configured for SSL passthrough.
    2The FQDN for external the load balancer with custom (public) certificate.

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

Retrofit Custom Certificates into a Cluster

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

Retrofit Custom Master Certificates into a Cluster

To retrofit custom certificates:

  1. Edit the Ansible inventory file to set the openshift_master_overwrite_named_certificates=true.

  2. Specify the path to the certificate using the openshift_master_named_certificates parameter.

    1. openshift_master_overwrite_named_certificates=true
    2. openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}] (1)
    1Path to a master API certificate. If necessary, concatenate all of the required files that form your certificate chain for the certificate file that is provided to the certFile parameter.

  3. Change to the playbook directory and run the following playbook:

    1. ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml

  4. If you use named certificates:

    1. Update the certificate parameters in the master-config.yaml file on each master node.

    2. Restart the OKD master service to apply the changes.

      1. # master-restart api
      2. # master-restart controllers

Retrofit Custom Router Certificates into a Cluster

To retrofit custom router certificates:

  1. Edit the Ansible inventory file to set the openshift_master_overwrite_named_certificates=true.

  2. Specify the path to the certificate using the openshift_hosted_router_certificate parameter.

    1. openshift_master_overwrite_named_certificates=true
    2. openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} (1)
    1Path to a router wildcard certificate.

  3. Change to the playbook directory and run the following playbook:

    1. $ cd /usr/share/ansible/openshift-ansible
    2. $ ansible-playbook playbooks/openshift-hosted/redeploy-router-certificates.yml

Using Custom Certificates with Other Components

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