Oh …I am confused with Certificate naming conventions !
My Observations
Certificates and the TLS world is always hard to understand for many of the software engineers. The lack of consistency in naming the various certificate related files does not help it either !
In my recent projects I came across various certificate files with different naming patterns and extensions . However, the lack of consistent naming conventions, inappropriate usage of file extensions forced me to stop for a moment and figure out the purpose of those files. After speaking to some of the team members the common theme was …this was like that since I have joined this project … !
In this post I will take a look at how this can be improved and the naming pattern which has worked for me !
What are commonly used extensions ?
Certificates can be stored in different formats and the following are the commonly used formats and file extensions.
.pem — Privacy enhanced Electronic Mail format (base64 encoded Certificate)
.cer — Usually in the binary Format (But I have seen server.cer is actually in PEM Format)
.crt (.cert) — Usually in the binary format ( but I have seen that the server.crt is actually in .PEM format)
.p12 — PKCS#12 format — Archive file format — usually contains the Certificate and Private key
.pfx — personal information exchange format (predecessor of pks12 format)
Note: .pfx and .p12 names are used quite interchangeably many times
What naming patterns are followed by popular servers ?
You will notice that .crt extension is used by Nginx server configuration where as Apache documentation uses .cert as an extension for certificate. However both the servers uses .key as an extension for private key.
However , in which formats these files are ?
If you read the documentation further …these files should be in the PEM format !
Naming Patterns
If we take an example of a domain (cloudmanthan.com) then there could be various naming patterns use for various files.
Certificate naming patterns
Pattern 1 — cloudmanthan.com.pem / cloudmanthan_com.pem
Pattern 2 — cloudmanthan.com.cert / cloudmanthan_com.cert
Pattern 3 — cloudmanthan.com.crt / cloudmanthan_com.crt
Pattern 4 — cloudmanthan.com.crt.pem / cloudmanthan_com_crt.pem
Pattern 5 and so on …— e.g. cloudmanthan.pem , cloudmanthan.key etc.
Private key naming patterns
Pattern 1 — cloudmanthan.com.key / cloudmanthan_com.key
Pattern 2 — cloudmanthan.com.key.pem / cloudmanthan_com_key.pem
Pattern 3 — cloudmanthan.pem / cloudmanthan.key
If you need distinct certificates for dev and test environments you would need additional certificates such as dev.cloudmanthan.com.crt or dev.cloudmanthan.key.
You would soon realise the importance of having naming patterns to avoid any confusion within the project.
This has worked for me …
- Define naming conventions if not in place
- Ensure that you and the team follow it consistently
- Reject and question different extensions
- .crt should be used as an extension for certificate and should be in PEM format (cloudmanthan.crt , dev.cloudmanthan.crt )
- .key should be used as an extension for private key (cloudmanthan.key, dev.cloudmanthan.key )
- .csr should be used used an extension for Certificate Signing Request
- Use .p12 or .pfx extension only when required e.g. Usually contains private key For example Azure Key Vault supports .PFX format.
- Password protect .p12 file as it contains the private key !
Summary
The key takeaway is to have naming conventions (.crt and .key ) and ensure those are followed consistently !
Additional Reading
If you want to create Private CA and certificates using OpenSSL, checkout the following story.
If you want to create Private CA and certificates using Terraform , checkout the following story.