This is a cache of https://docs.openshift.com/container-platform/4.14/security/certificates/replacing-default-ingress-certificate.html. It is a snapshot of the page at 2024-11-26T15:02:40.445+0000.
Replacing the default ingress certificate - Configuring certificates | Security and compliance | OpenShift Container Platform 4.14
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Replacing the default ingress certificate

Understanding the default ingress certificate

By default, OpenShift Container Platform uses the Ingress Operator to create an internal CA and issue a wildcard certificate that is valid for applications under the .apps sub-domain. Both the web console and CLI use this certificate as well.

The internal infrastructure CA certificates are self-signed. While this process might be perceived as bad practice by some security or PKI teams, any risk here is minimal. The only clients that implicitly trust these certificates are other components within the cluster. Replacing the default wildcard certificate with one that is issued by a public CA already included in the CA bundle as provided by the container userspace allows external clients to connect securely to applications running under the .apps sub-domain.

Replacing the default ingress certificate

You can replace the default ingress certificate for all applications under the .apps subdomain. After you replace the certificate, all applications, including the web console and CLI, will have encryption provided by specified certificate.

Prerequisites

  • You must have a wildcard certificate for the fully qualified .apps subdomain and its corresponding private key. Each should be in a separate PEM format file.

  • The private key must be unencrypted. If your key is encrypted, decrypt it before importing it into OpenShift Container Platform.

  • The certificate must include the subjectAltName extension showing *.apps.<clustername>.<domain>.

  • The certificate file can contain one or more certificates in a chain. The wildcard certificate must be the first certificate in the file. It can then be followed with any intermediate certificates, and the file should end with the root CA certificate.

  • Copy the root CA certificate into an additional PEM format file.

  • Verify that all certificates which include -----END CERTIFICATE----- also end with one carriage return after that line.

Procedure

  1. Create a config map that includes only the root CA certificate used to sign the wildcard certificate:

    $ oc create configmap custom-ca \
     --from-file=ca-bundle.crt=</path/to/example-ca.crt> \(1)
     -n openshift-config
    1 </path/to/example-ca.crt> is the path to the root CA certificate file on your local file system.

  2. Update the cluster-wide proxy configuration with the newly created config map:

    $ oc patch proxy/cluster \
     --type=merge \
     --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'

  3. Create a secret that contains the wildcard certificate chain and key:

    $ oc create secret tls <secret> \(1)
     --cert=</path/to/cert.crt> \(2)
     --key=</path/to/cert.key> \(3)
     -n openshift-ingress
    1 <secret> is the name of the secret that will contain the certificate chain and private key.
    2 </path/to/cert.crt> is the path to the certificate chain on your local file system.
    3 </path/to/cert.key> is the path to the private key associated with this certificate.

  4. Update the Ingress Controller configuration with the newly created secret:

    $ oc patch ingresscontroller.operator default \
     --type=merge -p \
     '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \(1)
     -n openshift-ingress-operator
    1 Replace <secret> with the name used for the secret in the previous step.

Additional resources