Adding a trusted CA config & the ingress certificate in OCP 4
“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.”
RedHat official documentation
What is a CSR and what are we doing today ?
The first step to obtaining an SSL certificate is using OpenSSL to create a certificate signing request (CSR) that can be sent to a Certificate Authority (CA) . The CSR contains the common name(s) you want your certificate to secure, information about your company, and your public key. In order for a CSR to be created, it needs to have a private key from which the public key is extracted. This can be done by using an existing private key or generating a new private key.
Let’s start — Log in to your bastion server (aka — regsitry:5000).
1. Creating your answer file
When running the “openssl” command we will use an answer file. This file will contain all of the necessary details in order for the OpenSSL ctl to generate at the end your CSR.
As a base line I suggest creating a dir that will hold all of your prominent files, this will also help to keep track of the original files in case you will need to look back at them / make changes / etc:
# mkdir /root/ocp_cert_filesFirst we set a few environment variables :
# export DOMAIN="example.local"
# export SHORT_NAME="registry"Writing up the answer.txt for your clusters ingress (*.apps.<clus_name>.example.com) :
$ cat > ${SHORT_NAME}_answer.txt << EOF
[req]
default_bits = 4096
prompt = no
default_md = sha256
x509_extensions = req_ext
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=US
ST=New York
L=New York
O=MyOrg
OU=MyOrgUnit
emailAddress=me@working.me
CN = ${SHORT_NAME}.${DOMAIN}
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = ${SHORT_NAME}.${DOMAIN}
EOF(you can change the dn values as you please except for the “CN”)
For reference your finished answer.txt file should look something like this:
$ cat answer.txt
[req]
default_bits = 4096
prompt = no
default_md = sha256
x509_extensions = req_ext
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=US
ST=New York
L=New York
O=MyOrg
OU=MyOrgUnit
emailAddress=hillay@exmaple.com
CN = *.apps.ocp.redhat.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = *.apps.ocp.redhat.com2. Generating the Key:
Generating an RSA key with the length of 4096 chars.
$ openssl genrsa -out ${SHORT_NAME}.key 40963. Generating your CSR
Now we will generate the certificate request using the domain Key and the domain answer file which we created in the beginning of the this tutorial.
$ openssl req -new -key ${SHORT_NAME}.key -out ${SHORT_NAME}.csr -config <path_to_answer.txt>At this point of time I always suggest to ‘test out’ your generated CSR for DNS & alternative DNS names :
$ openssl req -in ${SHORT_NAME}.csr -noout -text | grep DNS
DNS:*.apps.ocp.redhat.com, DNS:*.apps.ocp.redhat.com3. Generating a web ingress certificate based on your CSR
All you need to do now is send your CSR in any acceptable fashion to the team that holds under their jurisdiction the PKI infrastructure in your organization / or to your PKI provider if your are in a connected environment — from your .csr file you should be provided a web ingress certificate (web certificate).
After you have received your web ingress certificate, save it locally in your bastion server under the </xxx/ocp_cert_files> dir.
4. Obtaining your CA bundle chain
Simple as it sounds, as from your PKI team the CA chain for your networks CA in a PEM format.
It should look something like this — keep in mind because this is a CA chain or (bundle chain) there can always be one or more certificates in this file and this is totally normal:
------BEGIN CERTIFICATE------
xxxxxxx
...
...
...
...
xxxxxxx
------END CERTIFICATE------The file you should have received is normally in saved with a ‘.cer’ / ‘.pem’ extension — this is how it should be as it is in PEM format. If the file you’ve received is in a different format consider asking again the PKI team or converting it — for reference on how to do so using OpenSSL you can follow the link to DigiCert’s guide on the subject.
5. Updating your cluster with a ‘trusted CA’ bundle
- 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> \
-n openshift-config- The file <example-ca.crt> is the CA certificate chain as shown in section 4.
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"}}}'- Make sure when patching to change the name in the above command if in the prior step when creating the ConfigMap you gave it a different name other than “custom-ca”.
4. Updating your clusters wildcard certificate — web ingress cert
- Create a secret that contains the wildcard certificate chain and key:
oc create secret tls <secret> \
--cert=</path/to/cert.crt> \
--key=</path/to/cert.key> \
-n openshift-ingress<secret>— the secrets name--cert— the path to the web ingress certificate as obtained in section 3--key— the path to the.keyfile as generated in step 2
2. Update the Ingress Controller configuration with the newly created secret:
oc patch ingresscontroller.operator default \
--type=merge -p \
'{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \
-n openshift-ingress-operator- Again make sure the secret’s name is the same as the name you’ve chosen in the step before whilst patching the cluster ingress controller.
Now the cluster will start changing its certificate for all ingress and proxy purposes. This will take some time don’t be alarmed.
Clear your browser cookies and try to re-login into the cluster, otherwise you can always try incognito and check the certificate shown through the browser.
