Storing, managing, and renewing certificates can be a hassle. When will they expire? Where do I store them? Who has access to them and how is that controlled? How do I track the expiry date of these certificates so we don’t catch ourselves in a Sev 1 outage because a cert expired (hey, remember this)?
Azure Key Vault can generate certificates and automatically renew them, which makes most of the concerns listed above a non-issue. The difficulty is when we don’t have control over the process for generating and renewing certificates belonging to a trusted third-party. Luckily for us, Key Vault makes this really simple.
Supported File Types
Key Vault supports PFX- or PEM-formatted files. If you’re unfamiliar with the terminology, don’t worry. I’ll break down the difference between the two formats here 👇 in the form of a Q&A.
What is PFX? What does PFX stand for?
PFX stands for “Personal Information Exchange.” It’s the file format for the PKCS#12 standard. Think of PKCS as a family of standards that dictate how we should store and share certificates, keys, and other secure data. This particular standard (#12) says we should be able to** store the private key and public key certificate in a single, encrypted file. **Files generated in this way can have either .pfx and .p12 as the file extension.
What is PEM? How is that different from a PFX?
PEM stands for “Privacy Enhanced Mail.” This is a file format based upon a standard of the same name that was defined by the IETF in 1993. The standard itself was never widely adopted, but the filename and acronym still live on.
Many types of data can be stored in PEM files. The standard defines the storage of certificates, private keys, and certificate signing requests, all of which can be stored in — you guessed it — PEM files.
If the .pem extension indicates the file is PEM-formatted, how do we know what’s inside? This is denoted by the one-line header in the file, which looks like this:
-----BEGIN CERTIFICATE-----
Files that contain keys will begin with -----BEGIN RSA PRIVATE KEY-----, and certificate signing requests…well, you get the idea!
Extensions for PEM-formatted files vary widely. Files can end with the extensions .cer, .crt, or .key; these are all PEM formatted files and the extension here is a convenient way of telling the user what the file contains. If you are ever unsure, you can always verify what is stored in the file by reading its contents and checking the header.
**Most often, PEM files will contain either a certificate or a private key. **If you use openssl to generate a self-signed certificate and private key, by default it will spit out the key and certificate as two separate PEM files.
So a PFX contains a private key and certificate, and PEM files can contain anything?
✅ Yep! PEM files are very flexible and can contain all sorts of data. As I said earlier, usually you will see just a key or a cert in a single PEM file. A PFX will contain both the certificate and private key in the same file.
So…I can just upload my certificate (in PEM format) to Key Vault and that’s it?
No ❌. You need to upload the certificate and private key. For this reason, PFX files are easier to import into Key Vault since they contain the certificate and key together. If you have the key and certificate as separate PEM files you’ll have to combine them before importing them into Key Vault. I personally haven’t been able to just concatenate the key and cert into one file and upload that to Key Vault. In my experience, a PFX is the way to go.
#azure #cloud-computing #ssl #devops #cryptography