There are a couple ways to get the OpenShift API Server public certificates.

• Using the openssl s_client command
• Using oc and OpenSSL commands (this article)
• Using the OpenShift console and OpenSSL command

By far, the openssl s_client command is much easier, but only provides the server certificate (which is probably all you need anyways). The oc and OpenSSL commands (this article) provide much greater detail and understanding.

If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

The SSL public/private key pair used to establish the SSL handshake when connectiong to the OpenShift API server are in a TLS secret in the openshift-config namespace. Of course, this assumes are you able to sign into OpenShift. Check out my article FreeKB - OpenShift - Log into OpenShift using the oc login command.

The oc get secrets command can be used to list the secrets in the openshift-config namespace. In this example, there is a TLS secret named api-cert.

~]$ oc get secrets --namespace openshift-config
NAME                                      TYPE                                  DATA   AGE
api-cert                                  kubernetes.io/tls                     3      513d

The oc get secrets command with the --output yaml or --output json command should show that there are three keys in the secret, ca.crt and tls.crt and tls.key.

~]$ oc get secret api-cert --namespace openshift-config --output json
{
    "apiVersion": "v1",
    "data": {
        "ca.crt": "LS0tL.....g==",
        "tls.crt": "LS0tLS1CRUdJT.....S0tLQo=",
        "tls.key": "LS0tLS1Ud.....VktLS0tLQo="
    }

The jsonpath option can be used to return one of these keys, tls.crt in this example.

~]$ oc get secret api-cert --namespace openshift-config --output jsonpath="{.data.tls\.crt}"
LS0tLS1C.....UtLS0tLQo=

This value of the key is base64 encoded so the base64 command can be used to decode the encoded string.

~]$ oc get secret api-cert --namespace openshift-config --output jsonpath="{.data.tls\.crt}" | base64 --decode
-----BEGIN CERTIFICATE-----
MIIGeDCCBWCgAwIBAgITSAAABOyl0tY33JRdwQABAAAE7DANBgkqhkiG9w0BAQsF
vvnEPb7hvJIAIZNFiU1r9vuvKdtmb31LcKeDKA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID5DCCAsygAwIBAgITUAAAAAdlNt+xj0oR+gABAAAABzANBgkqhkiG9w0BAQsF
l9adPEkF8iFelBHfC1Jr2vSWj6kOuSk9boLpLbqpC9tQo5DQ3m2Tmw==
-----END CERTIFICATE-----

It's not too uncommon for the decoded certificate to contain a certificate chain, the root certificate authority (CA) certificate, an intermediate certificate, and a server certificate. Unforunately the openssl command does not have a great way to decode each certificate so I almost always create a file with the content of each certificate. For example, perhaps 1.pem would have the first certificate.

-----BEGIN CERTIFICATE-----
MIIGeDCCBWCgAwIBAgITSAAABOyl0tY33JRdwQABAAAE7DANBgkqhkiG9w0BAQsF
vvnEPb7hvJIAIZNFiU1r9vuvKdtmb31LcKeDKA==
-----END CERTIFICATE-----

And 2.pem would have the second certificate.

-----BEGIN CERTIFICATE-----
MIID5DCCAsygAwIBAgITUAAAAAdlNt+xj0oR+gABAAAABzANBgkqhkiG9w0BAQsF
l9adPEkF8iFelBHfC1Jr2vSWj6kOuSk9boLpLbqpC9tQo5DQ3m2Tmw==
-----END CERTIFICATE-----

And then I can use openssl to view the human readable certificate content.

openssl x509 -in 1.pem -text -noout
openssl x509 -in 2.pem -text -noout

Which should return something that begins like this.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            48:00:00:04:ec:a5:d2:d6:37:dc:94:5d:c1:00:01:00:00:04:ec
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: DC = com, DC = example
        Validity
            Not Before: Jun 18 12:59:36 2024 GMT
            Not After : Jun 18 12:59:36 2025 GMT
        Subject: C = US, ST = CA, L = Los Angeles, O = Acme, OU = Information Technology, CN = api.openshift.example.com