There are times that you might need to provide or have access to a X.509 certificate to verify the validity of a signed key or some other piece of data. X.509 Certificates are a standard for public key certificates and are often used to validate signatures on tokens and assertions used during user authentication, for example, when authenticating using SAML (Security Assertion Markup Language).
Recently, I needed to provide an X.509 certificate, provided by an Identity Provider, Azure AD, to an authorization service provider, Auth0. Since the X.509 certificate is a public format, the identity provider makes the certificate available in a long string format from their Federation Metadata Document, which is an .xml file publicly available. The format for the X.509 certificate provided by Azure was encoded in a base64 format, which was not accepted as is by Auth0, I needed to do some conversion prior to uploading to Auth0.
The following are steps taken to obtain and transform the X.509 certificate into a usable format across parties, (not all steps might be necessary for your use case):
- Obtain the X.509 certificate from the Identity Provider
Azure presents the X.509 certificate in the Federation Metadata Document which is a publicly available .xml document. In the metadata, there might be more than one X.509 certificate defined, this is because the certificates have differing expiration dates. If one certificate has expired, an application could then try to use another X.509 defined in the metadata for their validation needs.
Example .xml certificate
1 | <KeyDescriptor use="signing"> |
- Copy/Paste value of <X509Certificate>…</X509Certificate>
To get the certificate into format we can work with, copy/paste the value in between the <X509Certificate> .xml elements into a new .crt file.
A valid .crt certificate file contains a BEGIN and END certificate declaration. Your file should look something like this:
Example .crt file
1 | -----BEGIN CERTIFICATE----- |
- Make .crt file valid
The current format of the .crt file is not actually a valid
certificate format. We need to “fold” the long base64 string into one
where each line of the certificate is 64 characters in length. This can
be easily done with the fold command.
1 | fold -w 64 example.crt > new-example.crt |
This command will read our example.crt, perform the fold action to wrap each line after the 64th character, and then write the output to a new file with the new format.
- Convert .crt to .pem
Our example.crt might be acceptable, but I’ve found most relying parties need the X.509 certificate in a different format, often a .pem format. To convert the .crt to a .pem format we will use the openssl utility to convert between formats.
1 | openssl x509 -in new-example.crt -out example.pem |
The converted certificate can now be uploaded to the relying party.
While the steps are a bit manual, they can likely be improved and streamlined with scripting, etc. These certificates are often valid for many years or forever, so this should not be a process that needs to be performed often.
But there’s a problem - the view
ClusterRole doesn’t actually have permissions for the Cluster level
objects like Nodes and Persistent Volume Claims. So we’ll have to
create a new RBAC config.
