Create a TLS Secret

I followed the command-line method (the first method) explained in this article Creating Kubernetes Secrets Using TLS/SSL as an Example - i.e. rather than using the second (YAML file) method.

In order to do this I needed two files in the correct format.

There are multiple formats that certificate and associated key files can be in (they can even be combined into a single file). In order to create a Kubernetes TLS secret I needed to ascertain the right ones to use.

I was provided with a .pks file and needed to work out how to generate the correct artifacts from it. All I knew from the above article was that I needed a .crt and a .key file and at first I wasn't sure what these were.

What are we trying to achieve?¶

I needed obtain a TLS certificate and create a TLS Secret object in Kubernetes so that an Ingress resource could refer to the Secret in order that the certificate presented by the NGINX Ingress would look like this when visiting the associated Service in a web browser:

(i.e. the TLS/HTTPS certificate should include the CA chain.)

Getting the right files¶

To get an encrypted private key:

openssl pkcs12 -in domain.pfx -nocerts -out domain.enc.key

To get an un-encrypted private key file

openssl rsa -in domain.enc.key -outform PEM -out domain.key

Note: be sure to delete this file once uploaded to the cluster so that you don't have an un-encrypted secret on your local machine

To get the certificate file

openssl pkcs12 -in domain.pfx -nodes -nokeys -nomac -out domain.crt

The domain.crt file looks like this

In my case it contains the full CA chain and so, in my case, there are three certificates each enclosed in BEGIN CERTIFICATE and END CERTIFICATE delimiters:

-----BEGIN CERTIFICATE-----
################################################################
################################################################
-----END CERTIFICATE-----

Creating the TLS Secret in Kubernetes¶

Create Kubernetes TLS Secret:

kubectl create secret tls tlscert --key="tls.key" --cert="tls.crt"

Additional Notes¶

How to validate a key¶

This works for both encrypted or un-encrypted keys:

openssl rsa -check -in domain.enc.key

or

openssl rsa -check -in domain.key

You should see the message 'RSA key ok':

$ openssl rsa -check -in domain.enc.key
Enter pass phrase for domain.enc.pem:
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
################################################################
################################################################

Where did my PKS file come from?¶

I was provided with a .pks ( PKCS#12 ) file which had been created with the following command

openssl pkcs12 -export -out domain.pfx -inkey domain.rsa -in domain.cer -certfile CAbundle.txt

Where:

• domain.cer is the client certificate (i.e. without the Certification Authority (CA) chain )
• domain.rsa is an un-encrypted version of the private key
• CAbundle.txt contains the CA certificates to append to create the CA chain

domain.cer looks like this

As you can see if contains just a single certificate

domain.rsa looks like this

How to get the client certificate (without the full CA chain)¶

openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.cer

Some of the steps in this article are based on How to convert a PFX to a seperate .key/.crt file - by Mark Brilman

I also referred to the OpenSSL PKCS12 man pages

And to OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs

Updates¶

While following an MS Learn module I found this article on using Azure Key Vault to do much of the above: Manage certificates

"...you can connect your Key Vault with a trusted certificate issuer (referred to as an integrated CA) and create the certificate directly in Azure Key Vault. You can then request to create a certificate and the Key Vault will interact directly with the CA to fulfill the request"

Alternatively, you can also just use Key Vault to create self-signed certificates for testing, or to create an X.509 certificate signing request (CSR) to pass on to the certificate authority (CA) to process and then later request Key Vault to merge the resulting X.509 certificate with the key pair held in Key Vault.