Its not easy to determine by looking at a file extension whether it would carry a certificate or not.
I will be discussing file extensions related to certificates . This would give you some idea on what are the different types of certificates that exist. My area of expertise is in IIS, so I would be discussing related to that mostly.
SSL certificates are being used for various purposes such as:
- Authentication, The digital certificate is a common credential that provides a means to verify the identity of either the sender or the recipient.
- Privacy, which ensures that information, is only available to the intended audience. Certificates enable privacy of transmitted data using a number of different methods
- Encryption, which disguises information so that unauthorized readers are unable to decipher the message. On computers, sensitive data in the form of e-mail messages, files on a disk, and files being transmitted across the network can be encrypted using a key.
- Digital signatures, it provides strong evidence that the data has not been altered since it was signed and it confirms the identity of the person or entity who signed the data.
Different types of Certificates:
Different file format exists for certificates based upon how they are encoded and what information store. They can be classified as ones that contain the private key and the ones that doesn’t. We have many certificate file types that are supported on Windows. The most commonly used file type which allows private key to be exported is the .pfx/.p12 extension.
Certificate Signing Request (.csr)
This file type is sued by applications to submit requests to the Certification Authority or CA. The request can be base64 encoded as shown below and is enclosed between “—–BEGIN NEW CERTIFICATE REQUEST—–” and “—–END NEW CERTIFICATE REQUEST—–“.
—–BEGIN NEW CERTIFICATE REQUEST—–
Base64-encoded X.509 Certificate (.cer or .crt)
The Base64 format supports storage of a single certificate. This format does not support storage of the private key or certification path. They are Base64 encoded ASCII files. The encoded string is enclosed between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“. Right click and open a certificate (exported in the base 64 format) in a notepad:
|Base-64 encoded Certificate|
This file type is used more often for exporting certificates.
DER-encoded binary X.509 Certificate (.cer, .der or .crt)
The Distinguished Encoding Rules (DER) format supports storage of a single certificate. This format does not support storage of the private key or certification path.
DER is on of the encoding formats defined by ASN.1 in X.690. It is a variant or a subset of BER. You can refer the following Wiki article for further read:
Cryptographic Message Syntax Standard (PKCS#7) Certificate (.p7b, .p7r or .spc)
The PKCS #7 format supports storage of certificates and all certificates in the certification path. A PKCS #7 file typically has a .p7b file name extension, but this is not always the case. This again doesn’t support storage of private keys. It is generally used by the CA to provide certificate chain to clients.
However as in the case of any other data file, the creator has the authority to use the existing .p7b extension or change it as desired.
Personal Information Exchange Format (PKCS#12) Certificate (.pfx or .p12)
The Personal Information Exchange format (PFX, also called PKCS #12) defines a file format that can be used for secure storage of certificates (containing both private and public keys), and all certificates in a certification path, protected with a password-based symmetric key. PFX is a predecessor to PKCS#12.
The PKCS #12 formats is the only file format that can be used to export a certificate and its private key. A PKCS#12 certificate containing a private key is shown below:
Certificate containing a private key
Certificate Revocation List (.crl extension)
The Certificate Revocation List or CRL is a file type that identifies whether a certificate has been revocated or not. These files are provided by CA’s. The client browser while accessing a site on HTTPS will use the CRL Distribution Points field in the certificate to download the CRL. Here is one example:
Certificate from login.live.com depicting the CRL Distribution Points
NOTE: Not all certificates may have CRL distribution points. One good example is a Self-Signed certificate.
Now, once the client (browser) gets the CRL information from the server certificate, it downloads the CRL file and checks the list to ensure that the current certificate is not part of that list. The CA can make the CRL available for download to the client, via HTTP, FTP or any other protocol. Here is the downloaded CRL from the CA:
CRL file downloaded from the CA
Microsoft serialized certificate store (.sst)
This is one of the most rarely used file types. This format allows storage of multiple certificates in one single file. Typically it contains the ROOT CA certificates. It is the only file type which allows to save the certificate store. It preserves the properties of the certificate stores. There is another extension viz. “.STO”. However, I have rarely seen the usage of either of these file types.
Not much documentation is available except this:
Certificate Trust List (.stl)
Certificate Trust List is generally used during SSL/TLS handshake when Client Certificate Authentication comes in to picture. During SSL Handshake the server sends the client the list of the distinguished CA names that it supports as a part of Server Hello message. The Client uses this list to draw up a list of client certificates that is issued by any of the CA’s in the list i.e., only those client certificates which are issued by any of the CA’s in the CTL will be populated. Below is an example of how a CTL looks like
Privacy-enhanced Electronic Mail (.pem)
PEM format is a refinement of base64 encoding. It has been documented in the following RFC’s:
This file format is typically used by OpenSSL to make Private Key available from a .pfx/.p12 file. So this is more widely used in the UNIX/LINUX world and not much in Windows. Once extracted to PEM format, this is how it looks:
Command used to convert PFX to PEM:
openssl.exe pkcs12 -in Certificate.pfx -nocerts -out Certificate.pem
The two headers ”Proc-Type“ and “DEK-Info” specify the type of encryption. The string following afterwards with “5XAtC…” is Base64-encoded, encrypted, ASN.1-encoded object. Sometimes it also referred to as Base-64 encoded DER Certificate.
It is very similar to the PFX file format and can contain any/all of the following information in one single file.
- Issued Public Certificate (Client/Server)
- Intermediate CA Certificate
- Root CA certificate
- Private Key
A single PEM file can also be split into multiple PEM files each containing a part of the original PEM file.
PEM for storing Public Key
This format can also be used for storing only the public key information of a certificate. I found this article: http://www.bo.infn.it/alice/introgrd/certmgr/node20.html, which talks about extracting only the public part of the certificate. Even in this case the file is a Base-64 encoded string enclosed between “—–BEGIN PUBLIC KEY—–” and “—–END PUBLIC KEY—–“.
—–BEGIN PUBLIC KEY—–
I have personally never encountered any situation or a usage scenario where the public key information of the certificate had to be extracted.
This file format contains the private key of the certificate. On Windows there is no mechanism available to extract only the private key from the certificate, as it is not required. However, OpenSSL allows only the Private Key to be extracted from the certificate. If you open the file in a notepad, you would find that it is a Base-64 encoded string enclosed between “—–BEGIN RSA PRIVATE KEY—–” and “—–END RSA PRIVATE KEY—–“.
Command used to convert PFX to PEM:
openssl.exe pkcs12 -in Certificate.pfx -nocerts -out Certificate.pem
—–BEGIN RSA PRIVATE KEY—–
This is more widely used in JAVA & UNIX world.
More on Certificates:
When a certificate request is created for a website in IIS 6, corresponding private key is also created. The requests are stored under the Certificate Enrollment Requests store under Computer account. This contains the private key information corresponding to the request raised.
Once you have submitted the request to the CA. It will process the request and provide a certificate in .cer, crt or .der extension (DER or Base64 encoded). Now the pending request can be processed in the IIS Manager by installing the certificate which was provided by the CA.
Consider, if somehow the request for the certificate was lost i.e., the request under the Certificate Enrollment Requests was removed. Now if you install the certificate on the website you are bound to see some issues due to the missing key information. The SSL handshake will not complete and you will see a “Page cannot be displayed error message” on the browser.
By default a .cer file doesn’t contain a private key. The notion of such file is that the private key already exists on the server and during installation the binds to the certificate. Now since the request (private key) no longer exists the server doesn’t know how to decrypt the information received from client (encrypted using the public key). However, we are not totally helpless. We can try to retrieve the private key for the certificate. Here are the steps to do it:
1. Import the certificate to the personal store of computer account.
2. Now double click the certificate and go to the Details tab. Select the Thumbprint section and copy the value as shown below:
3. We will use certutil tool to map the private key to the certificate. Open a command prompt and execute the following:
|Certutil -repairstore my “73 14 b2 20 1c 57 f9 fe 19 36 cf ff 9f cb c9 1e 8c 0f 1a 02“|
If the command is successful then you will see a confirmation message as shown below:
More information on certutil tool can be found here:
Sometimes the web-administrator has to install the same certificate across various servers in a load balanced server. So, continuing from the above scenario let’s assume the web-admin has to install the cert on other 12 servers. Manually copying the .cer file to every server and running the above command is quite tedious.
Why can’t we export the certificate along with the private key to the other servers and then install it? Well, it can be done, provided the private key has been marked as exportable. Generally, you would see this if the certificate was renewed again with the private key not being exported earlier.
Go to the websites on which the certificate has been installed.
- Right click and select Properties-> Directory Security-> View Certificate.
- Now go to the details tab and click on “Copy to File…”
- Click on Next, you will now see a window provided with 2 radio buttons
- Yes, export the private key
- No, do not export the private key
Now you have a SSL certificate containing the Private Key. You can copy this to other servers and then install it on the website. You may also choose to install the certificate programmatically on IIS using the KB article 313624.