Raise a CSR and apply SSL on an AWS/IIS/ELB

 Basic HOWTO’s  and commands below (full explanation further below)

1. Request/create a CSR in IIS
2. Obtain purchased SSL, download from CA
3. Obtain Private Key
   Using GnuWin32  or Install OpenSSL for Windows. Alternatively  uses XCA tool with GUI (at https://hohnstaedt.de/xca/)
   Then run CMD (C:\openssl\bin ) and convert files using following commands:
   
   When you have the PFX file (that’s the most used commands below, 1.3.1 for pfx, 1.3.4 to decrypt key and 1.3.2 for p7b CA bundle is all you need):
   1.3.1 – convert the private key which is in PFX format into readable txt/pem format bypassing the encrypted format. Ready decrypted RSA pem file:
   openssl pkcs12 -in NAME1.pfx -out NAME2.key -nocerts -nodes (used to obtain the private key alone)
   openssl pkcs12 -in FILE.pfx -out FILE2.pem -nodes (used to obtain all certs within pfx)
   Used when Client provides PFX file with a password and Admin need to break it down to individual certs – usually holds the Private, Public and Intermediate/Root/Chain certificates (or only Private+Public)
   
   When you have the P7B file:
   1.3.2 -decrypting the bunch of certificates into separate pieces to import in AWS LB, Packaging 7 is another bundle holding THREE encrypted certs – it must be decrypted by:
   openssl pkcs7 -in file.pem -print_certs -out certs.pem  (if the SSL is in pkcs7 encryption – looks like this: —–BEGIN PKCS7—–)
   
   EXTRA COMMANDS:
   For exporting only the private and public key use the specific command below
   openssl pkcs12 -in myfile.pfx -nocerts -out private_key.pem -nodes      (When you have pfx file, exported from server with private key in pkcs12 encryption —–BEGIN PKCS12—–)
   
   1.3.4- the converted private key is still encrypted with password, to remove it and copy/paste in a TXT format use the command below
   openssl rsa -in site.pem -out decrypted.key  (used for private key decryption – convert from encrypted to open pem format)
   
   1.3.4 – converting signed P7B to usual pem – use inform der – (When P7b is signed data file. ALTERNATIVELY open -doubleclick – in Windows and export single files in X.509 format)

penssl pkcs7 -inform der -in a.p7b -out a.cer

1.3.5. Buildup of PFX from a single private and public keys:openssl pkcs12 -export -out Survey_Loeb_com.pfx -inkey private_key.pem -in Public-cert.pem

• Obtain Intermediate /chain/ certificates – it is specific for each CA  – usually provided in a zip within main cert file (else one may have to contact them …)
  The certificate chain includes the intermediate certificates and optionally the root certificate, one after the other without any blank lines, as shown in the following example. If you include the root certificate, your certificate chain must start with intermediate certificates and end with the root certificate. Use the intermediate certificates that were provided by your CA. Do not include any intermediaries that are not in the chain of trust path. (see Comodo sample below)

1. Apply them all three at the Load Balancer for the relevant site
2. Use https://www.sslshopper.com/ssl-certificate-tools.html as helping tools to confirm matching

7. HAPROXY

1.7.1 HAPROXY CONVERTION of pfx file  – Use Openssl to convert PFX/PEM to PKCS#8

(this is what HAProxy and Unix uses – private key must be starting with BEGIN PRIVATE KEY and not BEGIN RSA PRIVATE KEY) – (BEGIN RSA PRIVATE KEY is PKCS#1 and is just an RSA key. It is essentially just the key object from PKCS#8, but without the version or algorithm identifier in front.BEGIN PRIVATE KEY is PKCS#8 and indicates that the key type is included in the key data itself.). Includes 2 commands converting from PFX, or a single line converting from ready PEM

openssl pkcs12 -in certificatename.pfx -nocerts -nodes -out certificatename.pem
openSSL pkcs8 -in certificatename.pem -topk8 -nocrypt -out certificatename.pk8

1.7.2. HAPROXY CONCATENATE PEM – concatenate within the linux box

        cat private.pem wildcard-certificate.pem intermediates.pem > ssl-certs.pem

ALTERNATIVE GUI TOOL for Certificate management

There’s only one useful CRT convertion and exporting tool nowadays. This is XCA tool. Download at https://sourceforge.net/projects/xca/

XCA tool – X Certificate and Key management is an interface for managing asymetric keys like RSA or DSA. It is intended as a small CA for creation and signing certificates. It uses the OpenSSL library for the cryptographic operations.
This Opensource application is suitable for work with crypto keys. You can use it for making PFX files in which you keep your Code signing application signing. App keeps all keys in one file and password protected. You are not allowed to export any key from this archive without right password. It’s much secure that OpenSSL with keys in separate files.

Features

• Start your own PKI and create all kinds of certificates, requests or CRLs
• Import and export them in any format like PEM, DER, PKCS#7, PKCS#12
• Use them for your IPsec, OpenVPN, HTTPs or any other certificate based setup
• Manage your Smart-Cards via PKCS#11 interface
• Export certificates and requests to a OpenSSL config file
• Create Subject- and/or Extension- templates to ease issuing similar certs
• Convert existing certificates or requests to templates
• Get the broad support of x509v3 extensions as flexible as OpenSSL but user friendlier
• Adapt the Columns to have your important information at a glance

SSL and PFX certs are imported into tool. Export to any kind of PEM/X509/CRT/CER files is possible with few clicks.

OPENSSL FORMATS and DETAILED EXPLANATIONS (CLI) below:

Intro

There are two main objects: the private key, which is what the server owns, keeps secret, and uses to receive new SSL connections; and the public key which is mathematically linked to the private key, and made “public”: it is sent to every client as part of the initial steps of the connection.

The certificate is, nominally, a container for the public key. It includes the public key, the server name, some extra information about the server, and a signature computed by a certification authority. When the server sends its public key to a client, it actually sends its certificate, with a few other certificates (the certificate which contains the public key of the CA which signed its certificate, and the certificate for the CA which signed the CA’s certificate, and so on). Certificates are intrinsically public objects.

Some people use the term “certificate” to designate both the certificate and the private key; this is a common source of confusion. I personally stick to the strict definition for which the certificate is the signed container for the public key only.

A “.pfx” file is a PKCS#12 archive: a bag which can contain a lot of objects with optional password protection; but, usually, a PKCS#12 archive contains a certificate (possibly with its assorted set of CA certificates) and the corresponding private key. You do not distribute the .pfx file because that is the file containing the private key. You can extract and distribute the certificate (which is public) from the .pfx file via methods shown below.

On the other hand, a “.cert” (or “.cer” or “.crt”) file usually contains a single certificate, alone and without any wrapping (no private key, no password protection, just the certificate).

And .csr file is just a text file generated/based on the privete key with corresponding Identification company data

Types of Certificate – visual

Self Signed Certificate

Self Signed Certificates are certs where both the Issued To and the Issued By field of the certificates are same. In simple words it is a certificate where one issues a certificate to itself and hence the name Self Signed Certificate. Here is one example:

As seen in the above image the Issued to and Issued by are same. You may also observe the warning indicating that the certificate is not trusted. Of course it is not as it is self-signed, none of the Known Public CA’s have issued this, so it wont be trusted.

NOTE: To get past the above error put the cert in the Root CA store.

These certs come in handy as they can be created easily using several tools. Obtaining a certificate from a noted Certification Authority has a cost associated with it and may not be feasible at all times. Developers typically test their applications using a self signed certificates most of the times.

Root CA Certificate

Root CA Certificate is a CA Certificate which is simply a Self-signed Certificate. This certificate represents a entity which issues certificate and is known as Certificate Authority or the CA. The usage of the certificate distinguishes it with other normal certificates. Now a CA can be classified as either Root CA’s or Intermediate CA’s. On a Windows OS, if you are looking at the certificate store, you would see all the Root CA certificates in the Trusted Root Certification Authorities. This by default includes the list of public root CA’s which are installed with Windows and are updated periodically through Windows Updates. The number of the certificates would be lesser.

NOTE: Don’t add Intermediate CA certificates to the Trusted Root Certification Authorities store.

Identification of a Root CA:

Now how do we differentiate the CA certificates as Root CA or Intermediate CA. There is so much fuss around this. Its actually easy, look at the CA cert. If the Issued to and Issued by are same then it is a Root CA or else it is a Intermediate CA. Another identification would be to look at the Certification Path. The Cert which appears at the top of the list is the Root CA. Below is one example of one of the public root CA’s:

If you think logically this makes sense. CA’s are supposed to issue certificates. Now if I start the process from the beginning, then someone has to issue a certificate to himself and then start the process of issuing the certs down the line.

I’m not going to discuss the purpose of the CA certificate as that would lead to a whole new discussion altogether.

Intermediate CA Certificate

Intermediate CA Certificate is a CA certificate which is not a Self-signed Certificate. The purpose of this certificate may be same as the Root CA or different. Now one may think why to have a intermediate CA at all. Well here is what I think:

Initially it may not require to have a Intermediate CA, as the Root CA’s will serve the purpose. However as the requirement for PKI increases so would the number of CA’s. Understanding that CA at the end of the day is a Server Machine performing this computational task, it is required to have multiple machines. So they have to be replicated. Now it is again not viable to have many Root CA’s in the case of a Internet Scenario as this could lead to fraud and other management issues. So the concept of Intermediate CA was introduced. The Root CA’s delegated their tasks to the corresponding Intermediate CA’s for this. This way they can have one or more Intermediate CA’s.

On Windows OS, these certificates can be found in the Intermediate Certification Authorities Store. Comparatively the number of certificates in this store would be more compared to Trusted Root Certification Authorities store.

Below is a image of a certificate store of MY or Local Computer account. It contains many certificate stores, but I have only highlighted the ones relevant to this article.

Hope this article will clear some confusion at least.

Request an Internet Server Certificate (IIS 7)

To request an Internet server certificate when you must prove the identity of your Web server to clients who request content that resides on the server. Internet server certificates are issued by public certification authorities (CA).

What is a CSR? A CSR or Certificate Signing request is a block of encrypted text that is generated on the server that the certificate will be used on. It contains information that will be included in your certificate such as your organization name, common name (domain name), locality, and country. It also contains the public key that will be included in your certificate. A private key is usually created at the same time that you create the CSR.

A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. What is a CSR and private key good for if someone else can potentially read your communications? The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.

 To request an Internet server certificate (CSR)

You can perform this procedure by using the user interface (UI).

1.  
   1. Open IIS Manager and navigate to the level you want to manage. For information about opening IIS Manager, see Open IIS Manager (IIS 7). For information about navigating to locations in the UI, see Navigation in IIS Manager (IIS 7).
   1. In Features View, double-click Server Certificates.
   1. In the Actions pane, click Create Certificate Request.
   1. On the Distinguished Name Properties page of the Request Certificate Wizard, type the following information, and then click Next.
2. In the Common name text box, type a name for the certificate.
3. In the Organization text box, type the name of the organization in which the certificate will be used.
4. In the Organizational unit text box, type the name of the organizational unit in the organization in which the certificate will be used.
5. In the City/locality text box, type the unabbreviated name of the city or locality where your organization or organizational unit is located.
6. In the State/province text box, type the unabbreviated name of the state or province where your organization or organizational unit is located. 
7. In the Country/region text box, type the name of the country or region where your organization or organizational unit is located
8.  
   1. On the Cryptographic Service Provider Properties page, select either Microsoft RSA SChannel Cryptographic Provider or Microsoft DH SChannel Cryptographic Provider from the Cryptographic service provider drop-down list. By default, IIS 7 uses the Microsoft RSA SChannel Cryptographic Provider.
   1. In the Bit length drop-down list, select a bit length that can be used by the provider. By default, the RSA SChannel provider uses a bit length of 2048. A longer bit length is more secure, but it can affect performance. Choose 2048-bit
   1. Click Next.
   1. On the File Name page, type a file name in the Specify a file name for the certificate request text box, or click the browse button (…) to locate a file, and then click Finish.
   1. Send the certificate request to a public CA. Or to the Client IT department that manages the main domain!
9. Obtain SSL form Client and convert to private/public key.

How to export a private key from the webserver you have just sent the request from

• Find the certificate within the Enrollment requests
  • you may have to add the computer certificates module through MMC
• Export the certificate with the following options
  • Yes, export the private key
  • Select “Include all certificates in the certification path if possible
  • Select “Export all extended properties”
  • Set the password “password”
  • Save and finish

Converting the provided SSL to apply at Loadbalancer

• Certificate need to be converted to pem (txt) file and pasted into Amazon Loadballancer.
• The required certificates shown below:
  • Public Certificate
  • Private Certificate Key
  • Chain Certificates (Intermediate)

• The conversion is done by OpenSSL so you will need to install OpenSSL onto your workstation
• locate the bin folder within the OpenSSL
• make sure you have the private key you exported earlier into the OPENSSL\…..\BIN folder along with the keys that were provided after renewing the SSL
  • Convert a .p12/.pfx file to PEM-formatted file containing both the key(s) and certificate(s) (note: including the “-nodes” flag here will prevent using a passphrase to encrypt the private key(s)):
    • openssl pkcs12 -in filename.pfx -out site.pem
  • This will create a new file ready to decrypt
• Decrypt the file using the following command
  • openssl rsa -in site.pem -out decrypted.key
• You now have a text file of the private key
• Now you need to do similiar with the certificate you were provided with
• Run the following command
  • openssl pkcs7 -in file.p7b -print_certs -out certs.pem

Common OpenSSL Certificate Manipulations.

Convert/edit a PKCS#7 file from signed single PKCS7 certificate to a PEM (txt) cert file./If certificate is from verisign it may have extra wordings that need to be stripped:

FROM:

-----BEGIN PKCS #7 SIGNED DATA-----

TO:

-----BEGIN CERTIFICATE-----

FROM:

-----END PKCS #7 SIGNED DATA-----

TO:

-----END CERTIFICATE-----

Output all certificates in a file:

openssl pkcs7 -in file.pem -print_certs -out certs.pem

Convert a PKCS#7 file from PEM to DER:

 openssl pkcs7 -in file.pem -outform DER -out file.der

 

Export only the private key(s) from a .p12/.pfx file to a .pem file:

openssl pkcs12 -nocerts -in filename.pfx -out sitekey.pem

Strip the passphrase from a certificate with embedded, encrypted key in two steps (N.B.: postpend the certificate to the file using the appropriate shell redirection “>>”!):

openssl rsa -in somesystemcert.pem -out system.fqdn.like. this .crt

openssl x509 -in somesystemcert.pem >> system.fqdn.like. this .crt

ALTERNATIVELY one can obtain private key directly in no RSA encrypted form by:

openssl pkcs12 -in myfile.pfx -nocerts -out private_key.pem -nodes

BUILD a PFX file from all certificate

The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key into a single encryptable file. PFX files are usually found with the extensions .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

---

Requirements:

• The original private key used for the certificate
• A PEM (.pem, .crt, .cer) or PKCS#7/P7B (.p7b, .p7c) File
• OpenSSL

---

The commands below demonstrate examples of how to create a .pfx/.p12 file in the command line using OpenSSL.

PEM (.pem, .crt, .cer) to PFX

1	openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile more.crt

Breaking down the command:

• openssl – the command for executing OpenSSL
• pkcs12 – the file utility for PKCS#12 files in OpenSSL
• -export -out certificate.pfx – export and save the PFX file as certificate.pfx
• -inkey privateKey.key – use the private key file privateKey.key as the private key to combine with the certificate.
• -in certificate.crt – use certificate.crt as the certificate the private key will be combined with.
• -certfile more.crt – This is optional, this is if you have any additional certificates you would like to include in the PFX file.

PKCS#7/P7B (.p7b, .p7c) to PFX
P7B files cannot be used to directly create a PFX file. P7B files must be converted to PEM. Once converted to PEM, follow the above steps to create a PFX file from a PEM file.

1	openssl pkcs7 -print_certs -in certificate.p7b -out certificate.crt

Breaking down the command:

• openssl – the command for executing OpenSSL
• pkcs7 – the file utility for PKCS#7 files in OpenSSL
• -print_certs -in certificate.p7b – prints out any certificates or CRLs contained in the file.
• -out certificate.crt – output the file as certificate.crt

Which type of certificate Implementation team is to request from client when SSL purchased

The downloadable SSL cert have different structure for different OS.

Even though they’re all convertible the preferable type of downloading SSL is shown below marked in red –

Download the certificate and provide to IT team into format for APACHE, APPLE, Cisco, Oracle or Other – These are all .X509 type !!!

Any other would work, yet it requires time/tools to convert.

2.2 Extracting Certificate and Private Key Files from a .pfx File

Purpose

Customers sometimes have a need to export a certificate and private key from a Windows computer to separate certificate and key files for use elsewhere. Windows doesn’t provide the means to complete this process.

Exporting Certificates from the Windows Certificate Store describes how to export a certificate and private key into a single .pfx file. Follow the procedure below to extract separate certificate and private key files from the .pfx file.

Procedure

1. Take the file you exported (e.g. certname.pfx) and copy it to a system where you have OpenSSL installed. Note: the *.pfx file is in PKCS#12 format and includes both the certificate and the private key.
2. Run the following command to export the private key: openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes
3. Run the following command to export the certificate: openssl pkcs12 -in certname.pfx -nokeys -out cert.pem
4. Run the following command to remove the passphrase from the private key: openssl rsa -in key.pem -out server.key

3. Chain Certificates, Intermediate and root certificates!

Intermediate certificate authority: certificates

There are two types of certificate authorities (CAs), root CAs and intermediate CAs. In order for a certificate to be trusted, and often for a secure connection to be established at all, that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting.

If the certificate was not issued by a trusted CA, the connecting device (e.g., a web browser) will then check to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the device will usually display an error).

To facilitate this process of verifying a “chain” of trust, every certificate includes the fields “Issued To” and “Issued By”. An intermediate CA will show different information in these two fields, showing a connecting device where to continue checking, if necessary, in order to establish trust.

Root CA certificates, on the other hand, are “Issued To” and “Issued By” themselves, so no further checking is possible or necessary in order to establish trust (or lack thereof).

For example, if a certificate issued to “example.com” and issued by “Intermediate CA1”, and the visiting web browser trusts “Root CA”, trust may be established in the following manner:

Certificate 1 – Issued To: example.com; Issued By: Intermediate CA 1Certificate 2 – Issued To: Intermediate CA 1; Issued By: Intermediate CA 2Certificate 3 – Issued To: Intermediate CA 2; Issued By: Intermediate CA 3Certificate 4 – Issued To: Intermediate CA 3; Issued By: Root CA

The visiting web browser trusts “Root CA”, and a secure connection can now be established. Since this process is often called “certificate chaining,” intermediate CA certificates are sometimes called “chained certificates”. For enhanced security purposes, most end user certificates today are issued by intermediate certificate authorities.

Installing an intermediate CA signed certificate on a web server or load balancer usually requires installing a bundle of certificates.

Summary: 1. a private key is generated on the big-ip and kept in the filestore (will be used later in your clientssl profile as ‘key’)

2. a certificate signing request will be created for the specific hostname and with some specific attributes

3. you will submit the certificate signing request to a certficate authority (CA)

4. the CA with return a signed certficate. You will import it into the TMOS filestore and use it in your clientssl profile as ‘certficate’.

5. the CA will also provide a so called intermediate CA file or chain certificate. It proves, that your choosen CA is trusted by one of the root CAs. You will need the intermedidate CA certificate as ‘chain’ certificate in your clientssl profile.

3.1 Thawte and Verisign certificate example that require Chain Certificate addition and how to:

1) Top space: private key

2) Middle Space:  public key

3. Bottom space: Intermediate Certificates (Two certificates one after another)

Image of  uploading new SSL for each loadballancer that requires HTTPS/443/secure  connection:

Explanation of chains – In the chain certificate area  two certificates are copy/pasted

One is actually the SHA2 secure server (just signed by the Global Root) then the bottom is Global Root Signed by itself (global root) which is why its a root

One is the intermediate (SHA2) and the other is a root!

Example below:

 —–BEGIN RSA PRIVATE KEY—–
subject=/C=AU/ST=New South Wales/L=Sydney/O=Gilbert & Tobin/OU=Law/CN=subscriptions.gtlaw.com.au
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
subject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
—–BEGIN CERTIFICATE—–
subject=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
—–BEGIN CERTIFICATE—–

3.2 Network Solutions CA certificate example that require Chain Certificate bundle:

Network Solutions provide a zip file with couple of certeficates after CSR procedure. See image of the files included into ZIP:

1. Export the private key from pfx file, explained in previous chapter using Openssl commands.
2. Get the public certificate within the provided zip file (in that case: preferences.pbwt.crt)
   1. Use the chain certificates in the order as shown below. Copy/paste both txt file into ”Certificate Area” of the LB
      
      Network Solutions_CA.crt
      UTNAddTrustServer_CA.crt
      
      

                b. Or in the case of:

Use in the strict order:

NetworkSolutionsEVServerCA.crt

NetworkSolutionsAddTrustedEVServerCA.crt

More details to understand the reason behind chain bundle:

Let’s analyze these certs in your chain. The first one is AddTrustExternalCARoot.crt which is called the “root certificate”. This is the first cert in your chain. This root cert is installed to the Trusted Root Certification Authorities store on your server or network appliance.

The second cert in your chain is NetworkSolutions_CA.crt and the UTNAddTrustServer_CA.crt which are “intermediate certificates”. An intermediate cert is essentially a certificate issued by the Trusted Root CA specifically designed to issue SSL Certificates to you. The reason for this is because if the CA root cert were to ever be compromised, the entire chain fails. It is good security practice to use an “intermediary” to issue the certs from to prevent your root CAs from being exposed from the signing process. If an intermediate were to ever be compromised, you can always regenerate those unlike the root certs. This intermediate certificate sits between your website cert and the root cert. This intermediate cert is installed to the Intermediate Certification Authorities store on your server or appliance.

The last cert in your chain is PREFERENCES.PBWT.COM.crt which is your actual SSL cert. This is also known as your “domain certificate”. This domain cert is installed to the Personal store on your server or appliance.

So the end result is chain of certs that begins at the trusted root CA, runs through the intermediary, and finally ends with the SSL certificate issued to you for your website or appliance (preferences.pbwt.com).

More:
^{You will need to install the Intermediate CA certificates in order for browsers to trust your SSL Certification. The Intermediate CA certificates are contained within the ‘Apache_Plesk_Install.txt ‘ file that can be downloaded from the “Optional Download: Individual Certificate Files” section in Account Manager.Alternatively you can create this file yourself by combining the ‘UTNAddTrustServer_CA.crt’ file, the ‘NetworkSolutionsUTNServerCA.crt’ file, and the ‘NetworkSolutionsEVSSLCA.crt‘ file within a text document. The ‘UTNAddTrustServer_CA.crt’ cert content will be above the ‘NetworkSolutionsUTNServerCA.crt’ cert content, which will be above the’NetworkSolutionsEVSSLCA.crt‘ cert content. The files can be found in the *.zip file or downloaded individually from the “Optional Download: Individual Certificate Files” section in Account Manager. There can be no whitespace in the combined file. It is recommended that you use the .txt file already provided by Network Solutions.}

That’s how it looks when all SSL successfully applied and checked at http://www.sslshopper.com/ssl-checker.html

      3.3 GoDaddy CA

In short: convert the provided Godaddy p7b into pem using:

C:\Program Files (x86)\GnuWin32\bin>openssl pkcs7 -in gdd.p7b -print_certs -out certs-gdd.pem

The resulting file is holding two certs that need to be copied into Chain Cert field at the loadbalancer:

Copy Begin-to-End line of the first and add second cert just below the first (within the same field). Pasting both certs at one field.

Resulting converted file:

3.4 Comodo CA

Comodo provides intermediate and root certs bundle comprising of 3 certs:
Sample below – use the first one as the SSL, then add the other three as chain in aws elb.

The certificate chain includes the intermediate certificates and optionally the root certificate, one after the other without any blank lines, as shown in the following example. If you include the root certificate, your certificate chain must start with intermediate certificates and end with the root certificate. Use the intermediate certificates that were provided by your CA. Do not include any intermediaries that are not in the chain of trust path.

subject=/serialNumber=02228255/1.3.6.1.4.1.311.60.2.1.3=GB/2.5.4.15=Private Organization/C=GB/postalCode=EC1 Y8YY/ST=London/L=London/streetAddress=One Bunhill Row/O=Slaughter and May Ltd/OU=Technology/OU=COMODO EV SSL/CN=subscriptions.slaughterandmay.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Extended Validation Secure Server CA
—–BEGIN CERTIFICATE—–
MIIHwTCCBqmgAwIBAgIQL2nOpFtNzse8Y9sNiXKP+zANBgkqhkiG9w0BAQsFADCB
kjELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
29tG/9zC8YQ3oQmTNvXvqOf9anB+GtoXB2AywralskOTB4/prgxi7Yrfo24lAC3f
Sude5m30p/semVUtGRa4IV6OADWy
—–END CERTIFICATE—–

subject=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Extended Validation Secure Server CA
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
—–BEGIN CERTIFICATE—–
MIIGDjCCA/agAwIBAgIQBqdDgNTr/tQ1taP34Wq92DANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
pLwltum95OmYdBbxN4SBB7SC
—–END CERTIFICATE—–

subject=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
issuer=/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
—–BEGIN CERTIFICATE—–
MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv
PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR
pu/xO28QOG8=
—–END CERTIFICATE—–

subject=/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
issuer=/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
—–BEGIN CERTIFICATE—–
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
—–END CERTIFICATE—–

How do I make my own bundle file from CRT files?

Answer: You may do this using you favorite text editor or by using the command line.

Example:

# Root CA Certificate – AddTrustExternalCARoot.crt
# Intermediate CA Certificate 1 – UTNAddTrustSGCCA.crt
# Intermediate CA Certificate 2 – ComodoUTNSGCCA.crt
# Intermediate CA Certificate 3 – EssentialSSLCA_2.crt
# Your SSL Certificate – yourDomain.crt

Note: You will not need your SSL certificate for this exercise.

GUI Text Editor

1. Open All files in a text editor. (Remember, not your domain certificate.)
2. Create a new blank text file.
3. Copy contents of all files in reverse order and paste them into the new file.
Example: Intermediate 3, Intermediate 2, Intermediate 1, Root Certificate.
4. Save newly created file as ‘yourDomain.ca-bundle’.

Command Line

Linux or UNIX-like Operating Systems:
— cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

Windows or DOS:
— copy EssentialSSLCA_2.crt + ComodoUTNSGCCA.crt + UTNAddTrustSGCCA.crt + AddTrustExternalCARoot.crt yourDomain.ca-bundle

Note: ‘yourDomain.ca-bundle’ is only a place holder file name. You may call it anything you want.

3.5 Adding GlobalSign Intermediates to ELB

Use DomanSSL with https://support.globalsign.com/customer/portal/articles/1464460-domainssl-intermediate-certificates if exact domain is ordered

Use OrganisationSSL with https://support.globalsign.com/customer/en/portal/articles/1219303-organizationssl-intermediate-certificates if an Organisation is ordered

NOTE: See what the actual SSL says:

Check the link https://www.sslshopper.com/certificate-decoder.html and decode actual PUBLIC SSL
At the bottom it should say something like:
Issuer: GlobalSign Organization Validation CA – SHA256 – G2, GlobalSign

If its either Domain or Organisation Validated CA – use the avbbove relevant link and copy the G2 -SHA256 BASE64 pem file

EXAMPLE pem if the Intermediate is Organisation Validated:

3.6 Add the GeoSites RapidSSL SHA-2

Download the Intermediate cert at https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO28589 and add to AWS intermediates

3.7 Install by the simple way of importing cer and p7b into IIS6-IIS7 (IT DOES NOT APPLY FOR ELB Amazon Loadbalancers)

To Install an Intermediate Certificate in Microsoft IIS 7

1. Click Start, and then click Run….
2. Type mmc, and then click OK. The Microsoft Management Console (Console) window opens.
3. In the Console1 window, click the File menu, and then select Add/Remove Snap-in.
4. In the Add or Remove Snap-in window, select Certificates, and then click Add.
5. In the Certificates snap-in window, select Computer Account, and then click Next.
6. In the Select Computer window, select Local Computer, and then click Finish.
7. In the Add or Remove Snap-in window, click OK.
8. In the Console1 window, click + to expand the folder.
9. Right-click Intermediate Certification Authorities, mouse-over All Tasks, and then click Import.
10. In the Certificate Import Wizard window, click Next.
11. Click Browse to find the intermediate certificate file.
12. In the Open window, change the file extension filter to PKCS #7 Certificates (*.spc;*.p7b), select the *_iis_intermediates.p7b file, and then click Open.

NOTE: Do not install your Leaf Certificate in this area. Doing so removes your certificate from the list, and you must reinstall to correct the problem.

1. In the Certificate Import Wizard window, click Next.
2. Select Place all certificates in the following store, and then click Browse.
3. In the Select Certificate Store window, select Intermediate Certification Authorities, and then click OK.
4. In the Certificate Import Wizard window, click Next.
5. Click Finish.
6. Click OK.
7. Close the Console 1 window, and then click No to remove the console settings.

To Install an SSL Certificate in Microsoft IIS 7

1. Click Start, mouse-over Administrative Tools, and then click Internet Services Manager.
2. In the Internet Information Services (IIS) Manager window, select your server.
3. Scroll to the bottom, and then double-click Server Certificates.
4. From the Actions panel on the right, click Complete Certificate Request….
5. To locate your certificate file, click ….
6. In the Open window, select *.* as your file name extension, select your certificate (it might be saved as a .txt, .cer, or .crt), and then click Open.
7. In the Complete Certificate Request window, enter a Friendly name for the certificate file, and then click OK.

NOTE: For Wildcard SSL certificates make sure your Friendly Name to matches your Common Name (i.e. *.coolexample.com).

1. In the Internet Information Services (IIS) Manager window, select the name of the server where you installed the certificate.
2. Click + beside Sites, select the site to secure with the SSL certificate.
3. In the Actions panel on the right, click Bindings….
4. Click Add….
5. In the Add Site Binding window:
   • For Type, select https.
   • For IP address, select All Unassigned, or the IP address of the site.
   • For Port, type 443.
   • For SSL Certificate, select the SSL certificate you just installed, and then click OK.
6. Close the Site Bindings window.
7. Close the Internet Information Services (IIS) Manager window. Your SSL certificate installation is complete

If you have any questions about how to do this, contact your certificate authority or follow their SSL certificate installation instructions listed below:

Certificate Provider	Links to Installation Instructions
Comodo	Comodo Certificate Installation Instructions InstantSSL Certificate Installation Instructions
DigiCert	DigiCert Certificate Installation Instructions
Entrust	Entrust Certificate Installation Instructions
GeoTrust	GeoTrust Certificate Installation Instructions RapidSSL Certificate Installation Instructions
GlobalSign	GlobalSign Certificate Installation Instructions
GoDaddy	GoDaddy Certificate Installation Instructions
Network Solutions	Network Solutions Certificate Installation Instructions Network Solutions list of Intermediate Certificates
StartCom	StartCom Certificate Installation Instructions StartCom list of Intermediate Certificates
Thawte	Thawte SSL Web Server Certificate Installation Instructions Thawte SSL123 Certificate Installation Instructions Thawte SGC SuperCert Certificate Installation Instructions
VeriSign	VeriSign Certificate Installation Instructions VeriSign list of Intermediate Certificates

Most web browsers make it clear that you shouldn’t just continue when you receive this error. This is because, while most of the time it doesn’t, it could indicate that a phisher is trying to pass a website off as a legitimate site. You shouldn’t have to continue through this error message on legitimate web sites unless the web site owner just doesn’t want to spend a little money to buy a trusted SSL certificate. You definitely shouldn’t continue through this error on big websites like your bank.

This error is often phrased differently depending on the web browser. These are some common ways the certificate not trusted error is stated in other browsers:

 Different certificate not trusted errors in different web browsers

Web Browser	Error Message
Internet Explorer 6	“The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.”
Internet Explorer 7	“The security certificate presented by this website was not issued by a trusted certificate authority.”
Firefox 2	“Unable to verify the identity of www.paypal.com as a trusted site. Possible reasons for this error: – Your browser does not recognize the Certificate Authority that issued the site’s certificate. – The site’s certificate is incomplete due to a server misconfiguration.”
Firefox 3	“The certificate is not trusted because it is self signed.”  “The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer)”
Safari 3	“Authentication failed because the server certificate is not trusted.”
Google Chrome	“The site’s security certificate is not trusted!”

What happens if no chain certificate is present

What is contained in a CSR?

Name	Explanation	Examples
Common Name	The fully qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error.	*.google.com mail.google.com
Organization	The legal name of your organization. This should not be abbreviated and should include suffixes such as Inc, Corp, or LLC.	Google Inc.
Organizational Unit	The division of your organization handling the certificate.	Information Technology IT Department
City/Locality	The city where your organization is located.	Mountain View
State/County/Region	The state/region where your organization is located. This shouldn’t be abbreviated.	California
Country	The two-letter ISO code for the country where your organization is location.	US GB
Email address	An email address used to contact your organization.	webmaster@google.com
Public Key	The public key that will go into the certificate.	The public key is created automatically

FInally verify SSL details at https://www.sslshopper.com/ssl-certificate-tools.html and input HTTPS link to view details!!

Managing trusted root certificates for a local computer

Administrators is the minimum group membership required to complete this procedure.

To manage trusted root certificates for a local computer

1. Click Start, click Start Search, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Under Available snap-ins, click Local Group Policy Object Editor,click Add, select the computer whose local Group Policy object (GPO) you want to edit, and then click Finish.
4. If you have no more snap-ins to add to the console, click OK.
5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.
6. Double-click Certificate Path Validation Settings,and thenclick the Stores tab.
7. Select the Define these policy settings check box.
8. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates check boxes.
9. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Managing trusted root certificates for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To manage trusted root certificates for a domain

1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.
2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.
3. Click Start, point to Administrative Tools, and then click Group Policy Management.
4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.
5. Right-click the Default Domain Policy GPO, and then click Edit.
6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.
7. Double-click Certificate Path Validation Settings, and then click the Stores tab.
8. Select the Define these policy settings check box.
9. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates option in the Per User Certificate Stores check boxes.
10. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Adding certificates to the Trusted Root Certification Authorities store for a local computer

Administrators is the minimum group membership required to complete this procedure.

To add certificates to the Trusted Root Certification Authorities store for a local computer

1. Click Start, click Start Search, type mmc, and then press ENTER.
2. On the File menu, click Add/Remove Snap-in.
3. Under Available snap-ins, click Certificates,and then click Add.
4. Under This snap-in will always manage certificates for, click Computer account, and then click Next.
5. Click Local computer, and click Finish.
6. If you have no more snap-ins to add to the console, click OK.
7. In the console tree, double-click Certificates.
8. Right-click the Trusted Root Certification Authorities store.
9. Click Import to import the certificates and follow the steps in the Certificate Import Wizard.

Adding certificates to the Trusted Root Certification Authorities store for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To add certificates to the Trusted Root Certification Authorities store for a domain

1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.
2. After the Installation Results page shows that the installation of the GPMC was successful, click Close.
3. Click Start, point to Administrative Tools, and then click Group Policy Management.
4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.
5. Right-click the Default Domain Policy GPO, and then click Edit.
6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.
7. Right-click the Trusted Root Certification Authorities store.
8. Click Import and follow the steps in the Certificate Import Wizard to import the certificates.

Certificates and Encoding

At its core an X.509 certificate is a digital document that has been encoded and/or digitally signed according to RFC 5280.

X509 File Extensions

The first thing we have to understand is what each type of file extension is.   There is a lot of confusion about what DER, PEM, CRT, and CER are and many have incorrectly said that they are all interchangeable.  While in certain cases some can be interchanged the best practice is to identify how your certificate is encoded and then label it correctly.  Correctly labeled certificates will be much easier to manipulat

Encodings (also used as extensions)

•  

• .DER = The DER extension is used for binary DER encoded certificates. These files may also bear the CER or the CRT extension.   Proper English usage would be “I have a DER encoded certificate” not “I have a DER certificate”.
• .PEM = The PEM extension is used for different types of X.509v3 files which contain ASCII (Base64) armored data prefixed with a “—– BEGIN …” line.

Common Extensions

• CRT = The CRT extension is used for certificates. The certificates may be encoded as binary DER or as ASCII PEM. The CER and CRT extensions are nearly synonymous.  Most common among *nix systems
• CER = alternate form of .crt (Microsoft Convention) You can use MS to convert .crt to .cer (.both DER encoded .cer, or base64[PEM] encoded .cer)  The .cer file extension is also recognized by IE as a command to run a MS cryptoAPI command (specifically rundll32.exe cryptext.dll,CryptExtOpenCER) which displays a dialogue for importing and/or viewing certificate contents.
• .KEY = The KEY extension is used both for public and private PKCS#8 keys. The keys may be encoded as binary DER or as ASCII PEM.

The only time CRT and CER can safely be interchanged is when the encoding type can be identical.  (ie  PEM encoded CRT = PEM encoded CER)

    openssl rsa -in site.pem -out decrypted.key

Checking A Remote Certificate Chain With OpenSSL

If you deal with SSL/TLS long enough you will run into situations where you need to examine what certificates are being presented by a server to the client. The best way to examine the raw output is via (what else but) OpenSSL.¹

First let’s do a standard webserver connection (-showcerts dumps the PEM encoded certificates themselves for more extensive parsing if you desire. The output below snips them for readability.):

openssl s_client -showcerts -connect www.domain.com:443

CONNECTED(00000003)

--snip--

---

Certificate chain

 0 s:/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*.woot.com

   i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA

-----BEGIN CERTIFICATE-----

--snip--

-----END CERTIFICATE-----

 1 s:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA

   i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority

-----BEGIN CERTIFICATE-----

--snip--

-----END CERTIFICATE-----

---

Server certificate

subject=/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*.woot.com

issuer=/C=US/O=SecureTrust Corporation/CN=SecureTrust CA

---

No client certificate CA names sent

---

SSL handshake has read 2123 bytes and written 300 bytes

---

New, TLSv1/SSLv3, Cipher is RC4-MD5

Server public key is 1024 bit

--snip--

There’s a lot of data here so I have truncated several sections to increase readability. Points of interest:

1. The certificate chain consists of two certificates. At level 0 there is the server certificate with some parsed information. s: is the subject line of the certificate and i: contains information about the issuing CA.
2. This particular server (www.woot.com) has sent an intermediate certificate as well. Subject and issuer information is provided for each certificate in the presented chain. Chains can be much longer than 2 certificates in length.
3. The server certificate section is a duplicate of level 0 in the chain. If you’re only looking for the end entity certificate then you can rapidly find it by looking for this section.
4. No client certificate CAs were sent. If the server was configured to potentially accept client certs the returned data would include a list of “acceptable client CAs”.
5. Connection was made via TLSv1/SSLv3 and the chosen cipher was RC4-MD5. Incidentally, this typically means that the server you’re connecting to is IIS.

But what if you want to connect to something other than a bog standard webserver on port 443? Well, if you need to use starttls that is also available. As of OpenSSL 0.9.8 you can choose from smtp, pop3, imap, and ftp as starttls options.

openssl s_client -showcerts -starttls imap -connect mail.domain.com:139

If you need to check using a specific SSL version (perhaps to verify if that method is available) you can do that as well. -ssl2, -ssl3, -tls1, and -dtls1 are all choices here.²

openssl s_client -showcerts -ssl2 -connect www.domain.com:443

You can also present a client certificate if you are attempting to debug issues with a connection that requires one.³

openssl s_client -showcerts -cert cert.cer -key cert.key -connect www.domain.com:443

And for those who really enjoy playing with SSL handshakes, you can even specify acceptable ciphers.⁴ bash openssl s_client -showcerts -cipher DHE-RSA-AES256-SHA -connect www.domain.com:443

The cipher used above should work for almost any Apache server, but will fail on IIS since it doesn’t support 256-bit AES encryption.

---

1. The s_client command we’re using opens an interactive socket and does not automatically return to the shell prompt, so remember you will have to hit control-c or type something and hit return to terminate the process. ↩
2. This example shows an attempted SSLv2 only connection. SSLv2 should be disabled on any web server you control. It has a variety of flaws and has been superseded by SSLv3/TLSv1 for over a decade. ↩
3. This example expects the certificate and private key in PEM form. You can provide them in DER if you add -certform DER and -keyform DER (OpenSSL 0.9.8 or newer only) ↩
4. A list of available ciphers can be found by typing “openssl ciphers”, but there are also myriad ways to sort by type and strength. See the ciphers man page for more details. ↩

5. Move a SSL certificate from Microsoft IIS 5.0, 6.0, or 7.0 to Apache

Resolution

To move a SSL certificate from Microsoft IIS 5.0, 6.0, or 7.0 to Apache, the certificate must be converted from a PKCS#12 (.p12 or .pfx) to two separate files (private and public key).

Step 1: Export SSL certificate from Microsoft IIS 5.0, 6.0, or 7.0

1. From the web server, click Start
2. In the Search programs and files field, type mmc
3. From the Programs list, click mmc.exe
4. At the permission prompt, click Yes
5. From the Microsoft Management Console (MMC), click  File > Add/Remove Snap-in
6. From the list of snap-ins, select Certificates
7. Click Add
8. Select Computer account
9. Click Next
10. Select Local computer (the computer this console is running on)
11. Click Finish
12. In the Add/Remove Snap-in window, click OK
13. Save these console settings for future use
14. Double click on Certificates (Local Computer) in the center window.
15. Double click on the Personal folder, and then on Certificates.
16. Right Click on the Certificate you would like to backup and choose > All Tasks > Export
17. Follow the Certificate Export Wizard to backup your certificate to a .pfx file.
18. Choose to ‘Yes, export the private key‘
19. Choose to “Include all certificates in certificate path if possible.” (do NOT select the delete Private Key option)
20. Enter a password you will remember
21. Choose to save file on a set location
22. Click Finish
23. You will receive a message > “The export was successful.” > Click OK
24. The .pfx file backup is now saved in the location you selected.

Step 2:  Convert PFX file to compatible files for Apache

Move the .pfx file to the Apache server.

To extract the private key, run the OpenSSL command:
openssl pkcs12 -in <filename>.pfx  -nocerts -out key.pem
 
To extract the certificate (public key), run the OpenSSL command:
openssl pkcs12 -in <filename>.pfx -clcerts -nokeys -out cert.pem

Step 3: Install SSL certificate for Apache 

For installation instructions, refer to Thawte knowledge base article: SO1498
 
If these steps are unsuccessful, and you are not able to export your SSL certificate from IIS to Apache, you will need to create a new CSR and Revoke and Replace your certificate. Please see the instructions on solution: SO470
 
If you do not want to include a passphrase you can use the following command:

openssl rsa -in key.pem -out server.key

6. How to Import and Export SSL Certificates in IIS 7

Transferring IIS 7 Certificate Files

Background

Want an easier way to export? Our management & troubleshooting tool works on all Windows-based servers.

Windows servers use .pfx files to contain the public key files (your SSL Certificate files, provided by DigiCert) and the associated private key file (generated by your server as part of the CSR).

Since both the public and private keys are needed for an SSL Certificate to function, you need a .pfx backup to transfer SSL server security certificates from one server to another.

This page explains how to back up your certificate on a working server, import the certificate to another server, and then enable the certificate for use on the new server. If you have not yet installed the certificate files that you received from DigiCert on the server that generated your CSR, please see our IIS 7 installation instructions page.

Exporting/Backing Up to a .pfx File

1. On the Start menu click Run and then type mmc.
2. Click File > Add/Remove Snap-in.
3. Click Certificates > Add.
4. Select Computer Account and then click Next. Select Local Computer and then click Finish. Then close the add standalone snap-in window and the add/remove snap-in window.
5. Click the + to expand the certificates (local computer) console tree and look for the personal directory/folder. Expand the certificates folder.
6. Right-click on the certificate you want to backup and select ALL TASKS > Export.
7. Choose Yes, export the private key and include all certificates in certificate path if possible.
   Warning: Do not select the delete private key option.
8. Leave the default settings and then enter your password if required.
9. Choose to save the file and then click Finish. You should receive an “export successful” message. The .pfx file is now saved to the location you selected.

Importing from a .pfx File

1. On the Start menu click Run and then type mmc.
2. Click File > Add/Remove Snap-in.
3. Click Certificates > Add.
4. Select Computer Account and then click Next. Select Local Computer and then click Finish. Then close the add standalone snap-in window and the add/remove snap-in window.
5. Click the + to expand the certificates (local computer) console tree and look for the personal directory/folder. Expand the certificates folder.
6. Right-click on the certificate you want to backup and select ALL TASKS > Import.
7. Follow the certificate import wizard to import your primary certificate from the .pfx file. When prompted, choose to automatically place the certificates in the certificate stores based on the type of the certificate.

Enabling a New Certificate on a Server

1. On the Start menu, click Administrative Tools > Internet Information Services (IIS) Manager.
2. In the IIS Manager, click the server name.
3. Expand the sites folder.
4. Select the site that you want to secure (usually the default website).
5. On the actions menu in the edit site section, click Bindings.

• In the site bindings window, click Add. If a binding for https already exists, select the https binding and click Edit.

• Fill out the information in the add site binding window. In the type drop-down choose https. Set the IP address to the IP address of the site or choose all unassigned. The port for SSL traffic is usually 443. Enter the recently imported certificate in the SSL Certificate field.

• Click OK. Your SSL Certificate is now installed and the website is configured to accept secure connections. You may have to restart IIS or the server for it to recognize the new certificate.

 

7. AWS CLI commands remove/upload certificates:

Change / Update SSL certificate for Amazon Elastic Load Balancer with AWS Command Line Interface

1. Install and configure the AWS Command Line Interface
2. Show existing certificates to test if the AWS Cli is working:

$ aws iam list-server-certificates 

{"ServerCertificateMetadataList":[{"Path":"/","Arn":"arn:aws:iam::5xxxxxxxxxxx:server-certificate/www.example.com-201307-201407","ServerCertificateId":"AXXXXXXXXXXXXXXXXXXXX","ServerCertificateName":"www.example.com-201210-201310","UploadDate":"2012-10-10T11:25:35Z"}]}

• Upload your certificate:

$ aws iam upload-server-certificate --server-certificate-name www.example.com-2013010-2014010--certificate-body file://www.example.com.crt --private-key file://www.example.com.key --certificate-chain file://www.example.com.ca-bundle {"ServerCertificateMetadata":{"Path":"/","Arn":"arn:aws:iam::5xxxxxxxxxxx:server-certificate/www.example.com-2013010-2014010","ServerCertificateId":"AXXXXXXXXXXXXXXXXXXXX","ServerCertificateName":"www.example.com-2013010-2014010","UploadDate":"2013-10-22T16:57:36.704Z"}}

If you got the error message A client error (MalformedCertificate) occurred: Invalid Private Key. please look at this card to see how to fix it.

• Get the name of your loadbalancer:

$aws elb describe-load-balancers | grep LoadBalancerName"LoadBalancerName":"example-com",

• Update certificate on your loadbalancer:

aws elb set-load-balancer-listener-ssl-certificate --load-balancer-name example-com --ssl-certificate-id arn:aws:iam::5xxxxxxxxxxx:server-certificate/www.example.com-2013010-2014010--load-balancer-port 443

8. Errors

 8.1  “CertEnroll::CX509Enrollment::p_InstallResponse: ASN1 bad tag value met.0x8009310b”

Problem

When completing the certificate request using the PKCS#7 file in Internet Information Services (IIS) Manager 7.0, 7.5, and 8.0, the server may respond with the following error message:

There was an error while performing this operation.

Details:

CertEnroll::CX509Enrollment::p_InstallResponse:ASN1 bad tag value met. 0x8009310b (ASN: 267)
 

Cause

Microsoft IIS 7.0 currently reports an error indicating it does not accept PKCS#7 formatted certificates.  Although the ASN1 error occurs during installation, the certificate might still install successfully.

This is a known Microsoft IIS 7.0 issue.  Please see Microsoft Knowledge Base Article 959216 in regards to this issue.

Resolution

To verify the SSL certificate is successfully installed, try to bind the certificate to the web site.

To bind the certifcate to the appropriate web site, perform the following steps:

1. Click Start > Administrative Tools > Internet Information Services (IIS) Manager
2. Browse to your Server Name > Sites > Your SSL-based site
3. From the Actions pane, choose Bindings
4. In the Site Bindings window, choose Add
5. From the Add Site Bindings window, provide the binding type as HTTPS
6. Select the SSL certificate that will be used for this site
7. Click OK
8. Test the if the site is secure by using HTTPS
    

If in step 6 above, you cannot find the new certificate in the list, try restoring the private key.
 

Import certificate in to the Computer certificate store

1. Create a Certificate snap-in in a MMC console, per KB solution SO1849
2. In the left-hand pane, expand the Certificates folder, expand and select the Personal folder
3. Right-click the Certificates folder inside the Personal folder, select All Tasks, select Import
4. The Certificate Import Wizard opens. Click Next
5. Click Browse and then navigate to the file that contains the SSL certificate. Click Open > Next
6. Ensure “Place all certificates in the following store” is selected, ensure that “Personal” is listed for the certificate store, click Next > Finish

Restore Private Key

1. With the MMC console still open, select the Certificates folder inside the Personal folder in the left-hand pane.
2. Double-click the newly imported SSL certificate in the right-hand pane, then select the Details tab.
3. Scroll down and select the Thumbprint field, then select and copy the entire thumbprint (in the bottom box) to the clipboard.
4. Open a command prompt, then enter the following command:
   
   certutil -repairstore my “<thumbprint>”
   
   Example:
   
   certutil -repairstore my “00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f”
   
   If successful, the response will be “CertUtil: -repairstore command completed successfully”
    

Assign SSL certificate in IIS

1. Open the IIS Manager application.
2. From the Connections pane on the left, expand the local server, expand the Sites folder and select the web site to be secured with SSL.
3. From the Actions pane on the right, select the Bindings option (under Edit Site).
4. In the Site Bindings window, select an existing https binding and click Edit. If there are no existing https bindings, click Add.
5. Ensure the type is set to ‘https’, then select the new SSL certificate from the drop down menu. Click the View button to confirm details of the certificate, if necessary. Click OK > Close

8.2 Error: “unable to load PKCS7 object” is Displayed when Converting or Installing a PKCS #7 Certificate

Symptoms or Error – When converting and installing a public-key cryptography standards (PKCS) #7 certificate (which has .p7b file extension) to Privacy Enhanced Mail (PEM) format by using OpenSSL toolkit, the “unable to load PKCS7 object” error message is displayed.

Due to the unusual way or application that has been used to export files

---

Solution – To resolve this issue, complete the following procedure:

1. Save a copy of the .p7b certificate file on the computer.
2. Open the certificate file.
3. Expand the node in the left-pane which displays path where the certificate is stored as shown in the following screen shot.

The certificates stored on the computer are displayed in the right-pane.

1. Open the required certificate from the right-pane. The certificate opens as shown in the following screen shot.

• Activate the Details tab.

1. Click Copy to File as shown in the following screen shot.

1. Click Next in the Certificate Export Wizard as shown in the following screen shot.

1. Select the Base-64 encoded X.509 (.CER) option and then click Next as shown in the following screen shot.

1. Click Browse and specify the file name to which you want to export the certificate as shown in the following screen shot.

1. Click Next.
2. Click Finish as shown in the following screen shot.

1. Click OK as shown in the following screen shot.

1. Transfer the exported certificate to the /nsconfig/ssl directory of the NetScaler appliance as shown in the following screen shot.

1. Install the certificate.

9.View deatails of SSL and exact expiry date:

C:\OpenSSL\bin>openssl x509 -in star.domain.com.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            48:61:10:b7:bd:b8:29:51
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority –
        Validity
            Not Before: Jun 13 08:58:38 2016 GMT
            Not After : Jun 14 17:09:21 2017 GMT
        Subject: OU=Domain Control Validated, CN=*.domain.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:a4:c8:d5:5d:a5:6d:e1:4b:10:9a:6d:d4:83:30:
                    74:7a:f1:eb:d7:45:15:b1:47:1c:97:c3:9c:01:1c:
                    6d:cd:af:53:0f:27:94:a7:e5:b0:63:28:a8:56:84:
                    ef:d0:83:88:ca:ac:27:31:d4:52:7c:62:12:24:47:
                    77:d8:b9:03:ab:2c:58:d9:d5:d4:80:51:22:9b:dc:
                    2a:e5:0b:60:3a:bb:aa:7c:f4:8a:21:2e:5c:ea:dd:
                    3f:bf:4a:bd:7a:81:32:25:db:f4:e1:1e:18:36:2c:
                    d7:81:5d:8c:55:f4:bd:cc:07:4f:ca:8b:57:b6:5d:
                    89:81:8c:b1:7d:d9:11:e3:22:0c:98:39:07:3c:22:
                    32:c6:8d:eb:d8:db:87:01:ad:79:bf:bc:fa:42:a7:
                    e5:0b:ea:4c:c5:9a:e7:bf:11:2b:30:8a:a7:41:ed:
                    0b:9b:0d:d1:82:eb:8e:17:44:cb:b6:a6:66:0b:87:
                    eb:a2:c6:c4:7c:e8:a4:cc:c6:f6:b0:9e:4b:e7:c5:
                    66:9b:43:eb:cf:97:bf:83:79:0f:db:34:a5:35:68:
                    79:d1:e3:a9:0b:83:29:6f:96:f1:d0:38:63:3f:30:
                    48:1b:3f:3d:e8:5b:a2:9b:81:b6:aa:ec:2e:ee:a7:
                    71:cb:97:34:e2:99:34:e6:89:83:78:ed:83:18:44:
                    f3:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points:
                URI:http://crl.godaddy.com/gdig2s1-252.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114413.1.7.23.1
                  CPS: http://certificates.godaddy.com/repository/
                Policy: 2.23.140.1.2.1

            Authority Information Access:
                OCSP – URI:http://ocsp.godaddy.com/
                CA Issuers – URI:http://certificates.godaddy.com/repository/gdig2.crt

            X509v3 Authority Key Identifier:
                keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

            X509v3 Subject Alternative Name:
                DNS:*.domain.com, DNS: domain.com
            X509v3 Subject Key Identifier:
                68:08:6D:68:28:08:19:1C:EC:BE:EE:02:40:35:1A:C9:1D:FC:4E:AE
    Signature Algorithm: sha256WithRSAEncryption
        87:60:bd:49:8f:27:2c:4b:24:b9:6d:15:c4:e8:b5:18:46:9e:
        4e:a6:b4:df:e2:6b:7b:44:df:07:d9:1b:c7:0f:cd:19:3f:13:
        4f:dd:17:c2:5d:3a:18:9b:76:05:55:14:a4:3b:67:75:38:bd:
        35:78:79:1a:db:d7:f3:e1:a2:da:f2:f3:9f:00:64:88:fc:2f:
        de:d5:4f:e8:69:b4:65:de:dc:7b:df:8f:0b:a0:03:8b:af:90:
        2a:f2:75:ed:5c:00:89:fd:c8:50:98:e4:09:13:77:7b:03:72:
        15:e7:b3:82:f6:54:8d:5e:dd:88:39:9a:b4:ce:67:e1:75:b5:
        5d:41:08:68:49:44:96:b3:d5:70:58:7a:38:e5:6a:84:72:b5:
        62:ad:b0:7a:c5:c1:df:b9:3d:a7:3b:32:7a:36:ca:3f:b6:28:
        ba:ad:d7:6a:83:ae:32:06:d5:e1:64:96:ff:74:b6:60:93:72:
        fb:95:3b:98:f4:98:a3:b1:d1:fc:bb:08:f5:0b:15:2c:fc:48:
        84:07:01:aa:ec:83:05:f0:4d:86:73:25:51:6d:e0:0d:a5:99:
        dd:10:22:01:5d:ce:76:3c:23:5e:29:d3:ed:c4:ca:6a:8f:d9:
        51:01:4d:f2:96:86:e7:ab:50:fe:be:c1:7b:83:c4:60:dc:3d:
        47:ce:29:17
—–BEGIN CERTIFICATE—–
MIIFKTCCBBGgAwIBAgIISGEQt724KVEwDQYJKoZIhvcNAQELBQAwgbQxCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMRow
GAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UECxMkaHR0cDovL2NlcnRz
LmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQDEypHbyBEYWRkeSBTZWN1
cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwHhcNMTYwNjEzMDg1ODM4WhcN
MTcwNjE0MTcwOTIxWjA6MSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0
ZWQxFTATBgNVBAMMDCouY29uY2VwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKTI1V2lbeFLEJpt1IMwdHrx69dFFbFHHJfDnAEcbc2vUw8nlKfl
sGMoqFaE79CDiMqsJzHUUnxiEiRHd9i5A6ssWNnV1IBRIpvcKuULYDq7qnz0iiEu
XOrdP79KvXqBMiXb9OEeGDYs14FdjFX0vcwHT8qLV7ZdiYGMsX3ZEeMiDJg5Bzwi
MsaN69jbhwGteb+8+kKn5QvqTMWa578RKzCKp0HtC5sN0YLrjhdEy7amZguH66LG
xHzopMzG9rCeS+fFZptD68+Xv4N5D9s0pTVoedHjqQuDKW+W8dA4Yz8wSBs/Pehb
opuBtqrsLu6nccuXNOKZNOaJg3jtgxhE8ycCAwEAAaOCAbYwggGyMAwGA1UdEwEB
/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQE
AwIFoDA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vY3JsLmdvZGFkZHkuY29tL2dk
aWcyczEtMjUyLmNybDBdBgNVHSAEVjBUMEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYB
BQUHAgEWK2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9y
eS8wCAYGZ4EMAQIBMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuZ29kYWRkeS5jb20vMEAGCCsGAQUFBzAChjRodHRwOi8vY2VydGlmaWNh
dGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2RpZzIuY3J0MB8GA1UdIwQYMBaA
FEDCvSeOzDSDMKIz1/tss/C0LIDOMCMGA1UdEQQcMBqCDCouY29uY2VwLmNvbYIK
Y29uY2VwLmNvbTAdBgNVHQ4EFgQUaAhtaCgIGRzsvu4CQDUayR38Tq4wDQYJKoZI
hvcNAQELBQADggEBAIdgvUmPJyxLJLltFcTotRhGnk6mtN/ia3tE3wfZG8cPzRk/
E0/dF8JdOhibdgVVFKQ7Z3U4vTV4eRrb1/Photry858AZIj8L97VT+hptGXe3Hvf
jwugA4uvkCryde1cAIn9yFCY5AkTd3sDchXns4L2VI1e3Yg5mrTOZ+F1tV1BCGhJ
RJaz1XBYejjlaoRytWKtsHrFwd+5Pac7Mno2yj+2KLqt12qDrjIG1eFklv90tmCT
cvuVO5j0mKOx0fy7CPULFSz8SIQHAarsgwXwTYZzJVFt4A2lmd0QIgFdznY8I14p
0+3EymqP2VEBTfKWhuerUP6+wXuDxGDcPUfOKRc=
—–END CERTIFICATE—–

Or alternatively VIEW details of SSL:

10. Move or copy an SSL certificate from a Windows server to another Windows server

If you have multiple Windows servers that need to use the same SSL certificate, such as in a load-balancer environment or using a wildcard or UC SSL certificates, you can export the certificate to .pfx file and import it on a new Windows server. This may also be necessary when you switch hosting companies. We will go over the exact process with step-by-step instructions in this article. If necessary, you can copy the SSL certificate to an Apache or other type of server.

Explanations of all file types – Raise a CSR and apply SSL on an AWS/IIS/ELB

We will assume that you have already successfully installed the SSL certificate on one Windows web server. You will follow these steps to move or copy that working certificate to a new server:

1. Export the SSL certificate from the server with the private key and any intermediate certificates into a .pfx file.
2. Import the SSL certificate and private key on the new server.
3. Configure your web sites to use them in IIS.

On a Windows server you will need to export your certificate from the MMC console to a .pfx file with your private key. You can then copy that .pfx file to the new Windows server and import it. The following screenshots are from a Windows Server 2008 machine but any differences for Windows Server 2003 are noted.

10.1 Export the certificate from the Windows MMC console

The export is done with a .PFX file holding the private amd intermediate keys, secured with a password!

Note: These instructions will have you export the certificate using the MMC console. If you have Windows Server 2008 (IIS7) you can also import and export certificates directly in the Server Certificates section in IIS. Click here to hide or show the images

1. Click on the Start menu and click Run.
2. Type in mmc and click OK.

1. Click on the File menu and click Add/Remove Snap-in…

1. If you are using Windows Server 2003, click on the Add button. Double-click on Certificates.

1. Click on Computer Account and click Next.

1. Leave Local Computer selected and click Finish.

1. If you are using Windows Server 2003, click the Close button. Click OK.

1. Click the plus sign next to Certificates in the left pane.

1. Click the plus sign next to the Personal folder and click on the Certificates folder. Right-click on the certificate you would like to export and select All Tasks and then Export…

1. In the Certificate Export Wizard click Next.

1. Choose “Yes, export the private key” and click Next.

1. Click the checkbox next to “Include all certificates in the certification path if possible” and click Next.

1. Enter and confirm a password. This password will be needed whenever the certificate is imported to another server.

1. Click Browse and find a location to save the .pfx file to. Type in a name such as “mydomain.pfx” and then click Next.

1. Click Finish. The .pfx file containing the certificates and the private key is now saved to the location you specified.

10.2 Import the certificate in the Windows MMC console (intermediates.root)

Following import is done for new CA root/intermediate certs (or expired).

The steps below are for importing of the private key to another Windows server (when no root cert required)

After you have exported the certificate from the original server you will need to copy the .pfx file that you created to the new server and follow these import instructions.

1. Click on the Start menu and click Run.
2. Type in mmc and click OK.

1. Click on the File menu and click Add/Remove Snap-in…

1. If you are using Windows Server 2003, click on the Add button. Double-click on Certificates.

1. Click on Computer Account and click Next.

1. Leave Local Computer selected and click Finish.

1. If you are using Windows Server 2003, click the Close button. Click OK.

1. Right-click on the Personal folder and select All Tasks and then Import…

1. In the Certificate Import Wizard click Next.

1. Click the Browse button and change the file type from “X.509…” to “Personal Information Exchange (*.pfx, *.p12)”. find the .pfx file that you copied over and click Open and then Next.

1. Enter the password that you set when you exported the .pfx file and click “Mark this key as exportable” so you can export the certificate from this machine as well as the original. Click Next.

1. Click “Automatically select the certificate store based on the type of certificate” and click Next.

1. Click Finish to complete the wizard.

1. You can now click the Refresh button in the toolbar to refresh and find your certificate in the Certificates folder under Personal. You can verify that it was imported correctly by double-clicking it and looking for “You have a private key that corresponds to this certificate” at the bottom of the certificate dialog.

1. Close the MMC console. You do not need to save any changes.

10.3 Importing whole chain (private + intermediates) into a new server

This option is much simpler. Import is done ONCE the renewal of CSR is completed on the original server CRS request is generated.

When Completed the PFX file could be exported and reimported

Import is done in general IIS page (not site pages) at ‘SERVER Certificates’ icon. Then Import. and let it automatically decide the import.

10.4 RENAME the Friendly name of existing SSL

1. Importing of certs via IIS Certificate Icon at the main IIS Dashboard page

Changing the Friendly Name of an SSL Certificate

SSL Certificates are not required to have friendly names and are not part of the SSL Certificate. However, in environments that require multiple SSL Certificates, the lack of friendly names or poorly used friendly names can make managing your SSL Certificate more difficult.

If you are using multiple SSL Certificates in your environment, good friendly names can help you easily identify each certificate at a glance. You can use friendly names to remind you when a certificate expires, to provide information about who issued the certificate, and to distinguish multiple certificates with the same domain name.

On IIS and Exchange servers, when assigning your SSL Certificates to a website or a domain, friendly names are extremely helpful because certificates are displayed by their friendly names.

How to Edit an SSL Certificate’s Friendly Name with the DigiCert Utility

1. On the Windows server where your SSL Certificates are located, download and save the DigiCert® Certificate Utility for Windows executable (DigiCertUtil.exe).
2. Run the DigiCert® Certificate Utility for Windows (double-click DigiCertUtil).
3. In the DigiCert Certificate Utility for Windows©, click SSL (gold lock), right-click on the SSL Certificate whose friendly name you want to change, and then click Edit friendly name.

• In the Friendly Name box, enter a unique friendly name for the certificate to help you distinguish this certificate from the other certificates on your server.

Example Naming Conventions:

Domain Name:	yourDomain-digicert-(expiration.date)
Company Name:	yourCompany-digicert-(expiration.date)
Certificate Type:	wildcard-digicert-(expiration.date)

Note:    If you are using a Wildcard certificate with multiple websites, you may want to begin your friendly name with a wildcard character * (e.g. *your.domain-digicert-(expiration.date)). This naming convention makes it easier to identify the wildcard certificate so that you can assign it to multiple websites.

• When you are finished, click Save.

NOTES:

1. Have to complete the CSR request . Then EXPORT the PFX file with strong password
2. Importing of certs via IIS Certificate Icon at the main IIS Dashboard page
3. IF the Certificate is not using the ‘*.domain.com‘ name – the IIS website will not accept it for specific HOSTNAME and will greyout the area. Use Digicert, or just name it *.whatever it is
   Use Digicert to rename friendly name of installed certificate –  You have a wildcard SSL such as *.ipsum.com and the certificate is installed but you can’t choose a host name for the site in IIS when you try to add an HTTPS binding because the text box is greyed out.

The solution -Your wildcard SSL can be used with any subdomain, you just need to make sure you start the Friendly Name of the certificate with *. I prefer to use the same friendly name as the wildcard domain, e.g. *.ipsum.com but you can call it anything that beings with the asterix: *foo I gave my certificate the wrong Friendly Name, help!

Since Windows 8 or Server 2012, you can type certlm.msc in the start menu to manage certificates for the local machine. On previous versions of windows you will need to do something slightly more convoluted:

1. Run mmc.exe from start
2. Go to File menu and choose Add/Remove Snap-in... or hit (Ctrl-M)
3. Highlight the Certificates snap-in and hit Add > then choose Computer Account followed by Local Computer in the subsequent dialogs then hit Finish followed by OK to close the Snap-ins window

In the main window, expand Certificates (Local Computer) then Personal then Certificates and you will be able to right-click the certificate, hit Properties where you can update the friendly name.

10.5 .Adding SSL to OpnevpnAccess Server

Use the web UI/Webserver tab at vpn.domain.com/admin

5.

TOOLS

SSL checker https://www.sslshopper.com/ssl-checker.html

Decoder,checker, matcher, reader: https://www.sslshopper.com/ssl-certificate-tools.html

SSL Server test – SSL and Cipher Suites: https://www.ssllabs.com/ssltest/

DigiCert check – https://www.digicert.com/help/

CIPHER SUITES – Cipher Suites in Schannel

A cipher suite is a set of cryptographic algorithms. Schannel protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks:

• Key exchange
• Bulk encryption
• Message authentication

Key exchange algorithms protect information required to create shared keys. These algorithms are asymmetric (public key algorithms) and perform well for relatively small amounts of data.

Bulk encryption algorithms encrypt messages exchanged between clients and servers. These algorithms are symmetric and perform well for large amounts of data.

Message authentication algorithms generate message hashes and signatures that ensure the integrity of a message.

Developers specify these elements by using ALG_ID data types. For more information, see Specifying Schannel Ciphers and Cipher Strengths.

Schannel supports the following cipher suites. The suites are listed in the default order in which they are chosen by the Microsoft Schannel Provider.

Cipher suite	FIPS mode enabled	Protocols	Exchange	Encryption	Hash
TLS_RSA_WITH_AES_128_CBC_SHA256	Yes	TLS 1.2	RSA	AES	SHA256
TLS_RSA_WITH_AES_128_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0	RSA	AES	SHA1
TLS_RSA_WITH_AES_256_CBC_SHA256	Yes	TLS 1.2	RSA	AES	SHA256
TLS_RSA_WITH_AES_256_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0	RSA	AES	SHA1
TLS_RSA_WITH_RC4_128_SHA	No	TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0	RSA	RC4	SHA1
TLS_RSA_WITH_3DES_EDE_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0	RSA	3DES	SHA1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256	Yes	TLS 1.2	ECDH_P256	AES	SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384	Yes	TLS 1.2	ECDH_P384	AES	SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P256	AES	SHA1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P384	AES	SHA1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P256	AES	SHA1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P384	AES	SHA1
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256	Yes	TLS 1.2	ECDH_P256	AES	SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384	Yes	TLS 1.2	ECDH_P384	AES	SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256	Yes	TLS 1.2	ECDH_P256	AES	SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P256	AES	SHA1
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P384	AES	SHA1
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P256	AES	SHA1
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384	Yes	TLS 1.2, TLS 1.1, TLS 1.0	ECDH_P384	AES	SHA1
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384	Yes	TLS 1.2	ECDH_P384	AES	SHA384
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256	Yes	TLS 1.2	DH	AES	SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0	DH	AES	SHA1
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256	Yes	TLS 1.2	DH	AES	SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0	DH	AES	SHA1
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA	Yes	TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0	DH	3DES	SHA1
TLS_RSA_WITH_RC4_128_MD5	No	TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0	RSA	RC4	MD5
SSL_CK_RC4_128_WITH_MD5	No	SSL 2.0	RSA	RC4	MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5	No	SSL 2.0	RSA	3DES	MD5
TLS_RSA_WITH_NULL_SHA256	No	TLS 1.2	RSA	NULL	SHA256
TLS_RSA_WITH_NULL_SHA	No	TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0	RSA	NULL	SHA1

The following cipher suites are supported by Schannel; however, they are not present by default. They must be added as necessary. For information about how to add cipher suites to the Schannel provider, see Prioritizing Schannel Cipher Suites.

• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• SSL_CK_RC4_128_EXPORT40_MD5
• SSL_CK_DES_64_CBC_WITH_MD5
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

Windows Server 2008 and Windows Vista:  For information about supported cipher suites in Windows Vista, see Schannel Cipher Suites in Windows Vista.

Windows Server 2003 and Windows XP:  For information about supported cipher suites, see the following topics.

Follow the best practice below:

If you configure a web server’s TLS configuration, you have primarily to take care of three things:

1. disable SSL 2.0 (FUBAR) and SSL 3.0¹ (POODLE),
2. disable TLS 1.0 compression (CRIME),
3. disable weak ciphers (DES, RC4), prefer modern ciphers (AES), modes (GCM), and protocols (TLS 1.2).

You should also put effort into mitigating BREACH. That’s out of scope here though as it’s largely application-dependent.

Software and Versions

On the server side you should update your OpenSSL to 1.0.1c+ so you can support TLS 1.2, GCM, and ECDHE as soon as possible. Fortunately that’s already the case in Ubuntu 12.04 and later.

On the client side the browser vendors are starting to catch up. As of now, Chrome 30, Internet Explorer 11 on Windows 8, Safari 7 on OS X 10.9, and Firefox 26 all support TLS 1.2.

RC4

There used to be a bullet point suggesting to use RC4 to avoid BEAST and Lucky Thirteen. And ironically that used to be the original reason for this article: when Lucky Thirteen came out the word in the streets was: “use RC4 to mitigate” and everyone was like “how!?”.

Unfortunately shortly thereafter RC4 was found broken in a way that makes deploying TLS with it nowadays a risk. While BEAST et al require an active attack on the browser of the victim, passive attacks on RC4 ciphertext are getting stronger every day. In other words: it’s possible that it will become feasible to decrypt intercepted RC4 traffic eventually and the NSA probably already is. Microsoft even issued a security advisory that recommends to disable RC4. As of 2015, there’s even an RFC.

The String

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

You can test it against your OpenSSL installation using

openssl ciphers -v 

to see what’s supported².

You’ll get:

• Best possible encryption in all browsers.
• Perfect forward secrecy; if your web server, your OpenSSL, and their browser support it.
• It doesn’t offer RC4 even as a fallback. Although its inclusion at the end of the cipher string shouldn’t matter, active downgrade attacks on SSL/TLS exist and having RC4 as part of the the cipher string you potentially expose all of your users to it. Even very old browsers do 3DES just fine.
• Using ECDSA for authentication is even as of 2015 still very rare and cumbersome/expensive to deploy. Hence it’s completely ignored by the string. That makes it being sorted after RSA which is probably not what you want if you went the lengths to obtain an EC certificate³. However if you manage to deploy a dual-certificate setup (which you still need nowadays), you probably don’t need this article and it would have made the string twice as long.

---

The string also prefers AES-256 over AES-128 (except for GCM which is preferred over everything else). It does so mostly for liability reasons because customers may insist on it for bogus reasons.

However quoth a cryptographer:

AES-128 isn’t really worse than AES-anythingelse, at least not in ways you care about

The very simplified gist here is that the only reason for having 256 bit keys are quantum computers which are less likely to become a problem than the key scheduling issues in AES-256. But let me stress that both are fine. It’s just that adding AES-256 ciphers doesn’t improve your security in practice.

So if AES-128 is fine for you, feel free to add an ‘:!AES256’ to the end of the cipher string like I do.

Apache

SSLProtocolALL -SSLv2 -SSLv3

SSLHonorCipherOrderOn

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

This works on both Apache 2.2 and 2.4. If your OpenSSL doesn’t support the preferred modern ciphers (like the still common 0.9.8), it will fall back gracefully but your configuration is ready for the future.

Please note: you need Apache 2.4 for ECDHE and ECDSA. You can circumvent that limitation by putting an SSL proxy like stud or even nginx in front of it and let Apache serve only plain HTTP.

TLS compression is a bit more complicated: as of Apache 2.2.23, it’s not possible to switch it off inside of Apache. For Apache 2.2.24+ and 2.4.3+ you can switch it off using:

SSLCompressionOff

Currently the default is On. But that changed from 2.4.4 on.

The good news for Ubuntu admins is that Ubuntu has back ported that option into their 2.2 packages – and set it to off by default – so you should be fine. On RHEL/CentOS you used to have to set an environment variable but that has been fixed too and should be correct by default now.

nginx

ssl_prefer_server_ciphers On;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

TLS compression depends on the version of nginx and the version of OpenSSL. If OpenSSL 1.0.0 or later is installed, anything after nginx 1.0.9 and 1.1.6 is fine. If an older OpenSSL is installed, you’ll need at least nginx 1.2.2 or 1.3.2.

Have a look at this serverfault answer for more details.

TL;DR on TLS compression & nginx: if you’re using Ubuntu 12.04 or later you’re fine (OpenSSL 1.0.1/nginx 1.1.19).

CentOS/Red Hat Enterprise Linux 6

Although CentOS 6.5 is shipping an OpenSSL that is capable of ECDHE key exchange, it doesn’t ship an nginx and the nginx you get from nginx.org is compiled against an older OpenSSL. Therefore openssl ciphers will confusingly show you all the shiny ciphers but nginx just won’t offer it to the clients.

That’s terrible because it costs you PFS for IE browsers.

You’ll have to compile nginx yourself or source it from an alternative package index (EPEL for instance).

HAProxy

For TLS matters HAProxy shouldn’t be older than version 1.5.

global

   ssl-default-bind-options no-sslv3

   ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

   ssl-default-server-options no-sslv3

   ssl-default-server-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

Bonus Points

Qualys updated their requirements on 2014-01-21 and the cipher suites here are still “A”–material. If you want an “A+” though, you’ll need to add HSTS headers too. That’s out of scope for this article but the linked Wikipedia article will get you started.

Finally

Make sure to test your server afterwards!

If you want to learn more about deploying SSL/TLS, Qualys’s SSL/TLS Deployment Best Practices are a decent primer.

For investigating the SSL/TLS behavior of your browser, How’s My SSL? will give you all the details you need.

The (Near) Future

2013 has galvanized the whole industry. This is a good thing. In 2012 barely anyone lost a thought about configuring their TLS ciphers, how many bits their certificates had, or even forward secrecy. That made it way too easy for the bad folks. Nowadays people are questioning their own practices, open source projects work on enhancing their TLS support, and the public started to listen to cryptographers again instead of discounting them as crazy tinfoil crowd.

Good things are shaping on the horizon and Google’s Adam Langley given the power of having control over both servers and the most popular browser is pressing ahead. Their servers widely support TLS 1.2 with AES-GCM. Chrome has the best TLS support already. Additionally, recent releases now have grown support for ChaCha20 which is an extremely fast yet secure stream cipher by Dan Bernstein and Poly1305 a great MAC of the same pedigree. Google uses them if the the client doesn’t have hardware acceleration for AES.

Now if people just stopped using old browsers and we could roll out SNI and mandatory TLS 1.2.

History

Since I’m keeping this up to date, I’m going to document changes for returning visitors:

• 2015-05-20: The new weakdh/Logjam attack doesn’t affect you if you followed these instructions. It might be worthwhile though to create your own DH groups with at least 2048 bits as described in this guide.
• 2015-01-16: Added a note on ECDSA because there seemed to be some confusion about it.
• 2014-11-25: Added HAProxy, courtesy of Sander Klein.
• 2014-10-24: Updated the TLS compression part about Red Hat/CentOS. TL;DR: it’s secure by default now.
• 2014-10-21: Clarified that Internet Explorer 8 on Windows XP works fine with TLSv1-only. The original wrong claim stemmed from the fact that I double-checked using SauceLabs and it turned out that they don’t use Windows XP when you ask for it but Windows Server 2003 R2 instead. Since then I re-tested using actual Windows XP workstations running Internet Explorer 8 and it works fine.
• 2014-10-15: Disabled SSLv3 because of POODLE.
• 2014-04-11: Added note on CentOS/RHEL 6 and nginx+ECDHE.
• 2014-01-17: RSA+AES has been split into RSA+AESGCM:RSA+AES. This is a very minor update that only matters if you have TLS 1.2 but neither ECDHE nor DHE (which is rather rare). It makes sure, that RSA-AES-128-GCM is preferred over RSA-AES-256-CBC in these cases. Since both are just fallbacks and you should use PFS ciphers, this is just minutiae.

CIPHER SUITE NAMES

The following lists give the SSL or TLS cipher suites names from the relevant specification and their OpenSSL equivalents. It should be noted, that several cipher suite names do not include the authentication used, e.g. DES-CBC3-SHA. In these cases, RSA authentication is used.

SSL v3.0 cipher suites

 SSL_RSA_WITH_NULL_MD5                   NULL-MD5

 SSL_RSA_WITH_NULL_SHA                   NULL-SHA

 SSL_RSA_WITH_RC4_128_MD5                RC4-MD5

 SSL_RSA_WITH_RC4_128_SHA                RC4-SHA

 SSL_RSA_WITH_IDEA_CBC_SHA               IDEA-CBC-SHA

 SSL_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA

 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH-DSS-DES-CBC3-SHA

 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH-RSA-DES-CBC3-SHA

 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE-DSS-DES-CBC3-SHA

 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE-RSA-DES-CBC3-SHA

 SSL_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5

 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA       ADH-DES-CBC3-SHA

 SSL_FORTEZZA_KEA_WITH_NULL_SHA          Not implemented.

 SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  Not implemented.

 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA       Not implemented.

TLS v1.0 cipher suites

 TLS_RSA_WITH_NULL_MD5                   NULL-MD5

 TLS_RSA_WITH_NULL_SHA                   NULL-SHA

 TLS_RSA_WITH_RC4_128_MD5                RC4-MD5

 TLS_RSA_WITH_RC4_128_SHA                RC4-SHA

 TLS_RSA_WITH_IDEA_CBC_SHA               IDEA-CBC-SHA

 TLS_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA

 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        Not implemented.

 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        Not implemented.

 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE-DSS-DES-CBC3-SHA

 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE-RSA-DES-CBC3-SHA

 TLS_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5

 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       ADH-DES-CBC3-SHA

AES ciphersuites from RFC3268, extending TLS v1.0

 TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA

 TLS_RSA_WITH_AES_256_CBC_SHA            AES256-SHA

 TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH-DSS-AES128-SHA

 TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH-DSS-AES256-SHA

 TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH-RSA-AES128-SHA

 TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH-RSA-AES256-SHA

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE-DSS-AES128-SHA

 TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE-DSS-AES256-SHA

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE-RSA-AES128-SHA

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE-RSA-AES256-SHA

 TLS_DH_anon_WITH_AES_128_CBC_SHA        ADH-AES128-SHA

 TLS_DH_anon_WITH_AES_256_CBC_SHA        ADH-AES256-SHA

Camellia ciphersuites from RFC4132, extending TLS v1.0

 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA      CAMELLIA128-SHA

 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA      CAMELLIA256-SHA

 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA   DH-DSS-CAMELLIA128-SHA

 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA   DH-DSS-CAMELLIA256-SHA

 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA   DH-RSA-CAMELLIA128-SHA

 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA   DH-RSA-CAMELLIA256-SHA

 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  DHE-DSS-CAMELLIA128-SHA

 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  DHE-DSS-CAMELLIA256-SHA

 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  DHE-RSA-CAMELLIA128-SHA

 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  DHE-RSA-CAMELLIA256-SHA

 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA  ADH-CAMELLIA128-SHA

 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA  ADH-CAMELLIA256-SHA

SEED ciphersuites from RFC4162, extending TLS v1.0

 TLS_RSA_WITH_SEED_CBC_SHA              SEED-SHA

 TLS_DH_DSS_WITH_SEED_CBC_SHA           DH-DSS-SEED-SHA

 TLS_DH_RSA_WITH_SEED_CBC_SHA           DH-RSA-SEED-SHA

 TLS_DHE_DSS_WITH_SEED_CBC_SHA          DHE-DSS-SEED-SHA

 TLS_DHE_RSA_WITH_SEED_CBC_SHA          DHE-RSA-SEED-SHA

 TLS_DH_anon_WITH_SEED_CBC_SHA          ADH-SEED-SHA

GOST ciphersuites from draft-chudov-cryptopro-cptls, extending TLS v1.0

Note: these ciphers require an engine which including GOST cryptographic algorithms, such as the ccgost engine, included in the OpenSSL distribution.

 TLS_GOSTR341094_WITH_28147_CNT_IMIT GOST94-GOST89-GOST89

 TLS_GOSTR341001_WITH_28147_CNT_IMIT GOST2001-GOST89-GOST89

 TLS_GOSTR341094_WITH_NULL_GOSTR3411 GOST94-NULL-GOST94

 TLS_GOSTR341001_WITH_NULL_GOSTR3411 GOST2001-NULL-GOST94

Additional Export 1024 and other cipher suites

Note: these ciphers can also be used in SSL v3.

 TLS_DHE_DSS_WITH_RC4_128_SHA            DHE-DSS-RC4-SHA

Elliptic curve cipher suites.

 TLS_ECDHE_RSA_WITH_NULL_SHA             ECDHE-RSA-NULL-SHA

 TLS_ECDHE_RSA_WITH_RC4_128_SHA          ECDHE-RSA-RC4-SHA

 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA     ECDHE-RSA-DES-CBC3-SHA

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA      ECDHE-RSA-AES128-SHA

 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA      ECDHE-RSA-AES256-SHA

 TLS_ECDHE_ECDSA_WITH_NULL_SHA           ECDHE-ECDSA-NULL-SHA

 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA        ECDHE-ECDSA-RC4-SHA

 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDHE-ECDSA-DES-CBC3-SHA

 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA    ECDHE-ECDSA-AES128-SHA

 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA    ECDHE-ECDSA-AES256-SHA

 TLS_ECDH_anon_WITH_NULL_SHA             AECDH-NULL-SHA

 TLS_ECDH_anon_WITH_RC4_128_SHA          AECDH-RC4-SHA

 TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA     AECDH-DES-CBC3-SHA

 TLS_ECDH_anon_WITH_AES_128_CBC_SHA      AECDH-AES128-SHA

 TLS_ECDH_anon_WITH_AES_256_CBC_SHA      AECDH-AES256-SHA

TLS v1.2 cipher suites

 TLS_RSA_WITH_NULL_SHA256                  NULL-SHA256

 TLS_RSA_WITH_AES_128_CBC_SHA256           AES128-SHA256

 TLS_RSA_WITH_AES_256_CBC_SHA256           AES256-SHA256

 TLS_RSA_WITH_AES_128_GCM_SHA256           AES128-GCM-SHA256

 TLS_RSA_WITH_AES_256_GCM_SHA384           AES256-GCM-SHA384

 TLS_DH_RSA_WITH_AES_128_CBC_SHA256        DH-RSA-AES128-SHA256

 TLS_DH_RSA_WITH_AES_256_CBC_SHA256        DH-RSA-AES256-SHA256

 TLS_DH_RSA_WITH_AES_128_GCM_SHA256        DH-RSA-AES128-GCM-SHA256

 TLS_DH_RSA_WITH_AES_256_GCM_SHA384        DH-RSA-AES256-GCM-SHA384

 TLS_DH_DSS_WITH_AES_128_CBC_SHA256        DH-DSS-AES128-SHA256

 TLS_DH_DSS_WITH_AES_256_CBC_SHA256        DH-DSS-AES256-SHA256

 TLS_DH_DSS_WITH_AES_128_GCM_SHA256        DH-DSS-AES128-GCM-SHA256

 TLS_DH_DSS_WITH_AES_256_GCM_SHA384        DH-DSS-AES256-GCM-SHA384

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256       DHE-RSA-AES128-SHA256

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       DHE-RSA-AES256-SHA256

 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256       DHE-RSA-AES128-GCM-SHA256

 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       DHE-RSA-AES256-GCM-SHA384

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256       DHE-DSS-AES128-SHA256

 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       DHE-DSS-AES256-SHA256

 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256       DHE-DSS-AES128-GCM-SHA256

 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384       DHE-DSS-AES256-GCM-SHA384

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256

 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384     ECDHE-RSA-AES256-SHA384

 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256

 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     ECDHE-RSA-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   ECDHE-ECDSA-AES128-SHA256

 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   ECDHE-ECDSA-AES256-SHA384

 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDHE-ECDSA-AES128-GCM-SHA256

 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDHE-ECDSA-AES256-GCM-SHA384

 TLS_DH_anon_WITH_AES_128_CBC_SHA256       ADH-AES128-SHA256

 TLS_DH_anon_WITH_AES_256_CBC_SHA256       ADH-AES256-SHA256

 TLS_DH_anon_WITH_AES_128_GCM_SHA256       ADH-AES128-GCM-SHA256

 TLS_DH_anon_WITH_AES_256_GCM_SHA384       ADH-AES256-GCM-SHA384

 RSA_WITH_AES_128_CCM                      AES128-CCM

 RSA_WITH_AES_256_CCM                      AES256-CCM

 DHE_RSA_WITH_AES_128_CCM                  DHE-RSA-AES128-CCM

 DHE_RSA_WITH_AES_256_CCM                  DHE-RSA-AES256-CCM

 RSA_WITH_AES_128_CCM_8                    AES128-CCM8

 RSA_WITH_AES_256_CCM_8                    AES256-CCM8

 DHE_RSA_WITH_AES_128_CCM_8                DHE-RSA-AES128-CCM8

 DHE_RSA_WITH_AES_256_CCM_8                DHE-RSA-AES256-CCM8

 ECDHE_ECDSA_WITH_AES_128_CCM              ECDHE-ECDSA-AES128-CCM

 ECDHE_ECDSA_WITH_AES_256_CCM              ECDHE-ECDSA-AES256-CCM

 ECDHE_ECDSA_WITH_AES_128_CCM_8            ECDHE-ECDSA-AES128-CCM8

 ECDHE_ECDSA_WITH_AES_256_CCM_8            ECDHE-ECDSA-AES256-CCM8

Camellia HMAC-Based ciphersuites from RFC6367, extending TLS v1.2

 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 ECDHE-ECDSA-CAMELLIA128-SHA256

 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384

 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256   ECDHE-RSA-CAMELLIA128-SHA256

 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384   ECDHE-RSA-CAMELLIA256-SHA384

Pre-shared keying (PSK) ciphersuites

 PSK_WITH_NULL_SHA                         PSK-NULL-SHA

 DHE_PSK_WITH_NULL_SHA                     DHE-PSK-NULL-SHA

 RSA_PSK_WITH_NULL_SHA                     RSA-PSK-NULL-SHA

 PSK_WITH_RC4_128_SHA                      PSK-RC4-SHA

 PSK_WITH_3DES_EDE_CBC_SHA                 PSK-3DES-EDE-CBC-SHA

 PSK_WITH_AES_128_CBC_SHA                  PSK-AES128-CBC-SHA

 PSK_WITH_AES_256_CBC_SHA                  PSK-AES256-CBC-SHA

 DHE_PSK_WITH_RC4_128_SHA                  DHE-PSK-RC4-SHA

 DHE_PSK_WITH_3DES_EDE_CBC_SHA             DHE-PSK-3DES-EDE-CBC-SHA

 DHE_PSK_WITH_AES_128_CBC_SHA              DHE-PSK-AES128-CBC-SHA

 DHE_PSK_WITH_AES_256_CBC_SHA              DHE-PSK-AES256-CBC-SHA

 RSA_PSK_WITH_RC4_128_SHA                  RSA-PSK-RC4-SHA

 RSA_PSK_WITH_3DES_EDE_CBC_SHA             RSA-PSK-3DES-EDE-CBC-SHA

 RSA_PSK_WITH_AES_128_CBC_SHA              RSA-PSK-AES128-CBC-SHA

 RSA_PSK_WITH_AES_256_CBC_SHA              RSA-PSK-AES256-CBC-SHA

 PSK_WITH_AES_128_GCM_SHA256               PSK-AES128-GCM-SHA256

 PSK_WITH_AES_256_GCM_SHA384               PSK-AES256-GCM-SHA384

 DHE_PSK_WITH_AES_128_GCM_SHA256           DHE-PSK-AES128-GCM-SHA256

 DHE_PSK_WITH_AES_256_GCM_SHA384           DHE-PSK-AES256-GCM-SHA384

 RSA_PSK_WITH_AES_128_GCM_SHA256           RSA-PSK-AES128-GCM-SHA256

 RSA_PSK_WITH_AES_256_GCM_SHA384           RSA-PSK-AES256-GCM-SHA384

 PSK_WITH_AES_128_CBC_SHA256               PSK-AES128-CBC-SHA256

 PSK_WITH_AES_256_CBC_SHA384               PSK-AES256-CBC-SHA384

 PSK_WITH_NULL_SHA256                      PSK-NULL-SHA256

 PSK_WITH_NULL_SHA384                      PSK-NULL-SHA384

 DHE_PSK_WITH_AES_128_CBC_SHA256           DHE-PSK-AES128-CBC-SHA256

 DHE_PSK_WITH_AES_256_CBC_SHA384           DHE-PSK-AES256-CBC-SHA384

 DHE_PSK_WITH_NULL_SHA256                  DHE-PSK-NULL-SHA256

 DHE_PSK_WITH_NULL_SHA384                  DHE-PSK-NULL-SHA384

 RSA_PSK_WITH_AES_128_CBC_SHA256           RSA-PSK-AES128-CBC-SHA256

 RSA_PSK_WITH_AES_256_CBC_SHA384           RSA-PSK-AES256-CBC-SHA384

 RSA_PSK_WITH_NULL_SHA256                  RSA-PSK-NULL-SHA256

 RSA_PSK_WITH_NULL_SHA384                  RSA-PSK-NULL-SHA384

 PSK_WITH_AES_128_GCM_SHA256               PSK-AES128-GCM-SHA256

 PSK_WITH_AES_256_GCM_SHA384               PSK-AES256-GCM-SHA384

 ECDHE_PSK_WITH_RC4_128_SHA                ECDHE-PSK-RC4-SHA

 ECDHE_PSK_WITH_3DES_EDE_CBC_SHA           ECDHE-PSK-3DES-EDE-CBC-SHA

 ECDHE_PSK_WITH_AES_128_CBC_SHA            ECDHE-PSK-AES128-CBC-SHA

 ECDHE_PSK_WITH_AES_256_CBC_SHA            ECDHE-PSK-AES256-CBC-SHA

 ECDHE_PSK_WITH_AES_128_CBC_SHA256         ECDHE-PSK-AES128-CBC-SHA256

 ECDHE_PSK_WITH_AES_256_CBC_SHA384         ECDHE-PSK-AES256-CBC-SHA384

 ECDHE_PSK_WITH_NULL_SHA                   ECDHE-PSK-NULL-SHA

 ECDHE_PSK_WITH_NULL_SHA256                ECDHE-PSK-NULL-SHA256

 ECDHE_PSK_WITH_NULL_SHA384                ECDHE-PSK-NULL-SHA384

 PSK_WITH_CAMELLIA_128_CBC_SHA256          PSK-CAMELLIA128-SHA256

 PSK_WITH_CAMELLIA_256_CBC_SHA384          PSK-CAMELLIA256-SHA384

 DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256      DHE-PSK-CAMELLIA128-SHA256

 DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384      DHE-PSK-CAMELLIA256-SHA384

 RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256      RSA-PSK-CAMELLIA128-SHA256

 RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384      RSA-PSK-CAMELLIA256-SHA384

 ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256    ECDHE-PSK-CAMELLIA128-SHA256

 ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384    ECDHE-PSK-CAMELLIA256-SHA384

 PSK_WITH_AES_128_CCM                      PSK-AES128-CCM

 PSK_WITH_AES_256_CCM                      PSK-AES256-CCM

 DHE_PSK_WITH_AES_128_CCM                  DHE-PSK-AES128-CCM

 DHE_PSK_WITH_AES_256_CCM                  DHE-PSK-AES256-CCM

 PSK_WITH_AES_128_CCM_8                    PSK-AES128-CCM8

 PSK_WITH_AES_256_CCM_8                    PSK-AES256-CCM8

 DHE_PSK_WITH_AES_128_CCM_8                DHE-PSK-AES128-CCM8

 DHE_PSK_WITH_AES_256_CCM_8                DHE-PSK-AES256-CCM8

ChaCha20-Poly1305 cipher suites, extending TLS v1.2

 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256      ECDHE-RSA-CHACHA20-POLY1305

 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256    ECDHE-ECDSA-CHACHA20-POLY1305

 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256        DHE-RSA-CHACHA20-POLY1305

 TLS_PSK_WITH_CHACHA20_POLY1305_SHA256            PSK-CHACHA20-POLY1305

 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256      ECDHE-PSK-CHACHA20-POLY1305

 TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256        DHE-PSK-CHACHA20-POLY1305

 TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256        RSA-PSK-CHACHA20-POLY1305

Older names used by OpenSSL

The following names are accepted by older releases:

 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA    EDH-RSA-DES-CBC3-SHA (DHE-RSA-DES-CBC3-SHA)

 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA    EDH-DSS-DES-CBC3-SHA (DHE-DSS-DES-CBC3-SHA)

NOTES

Some compiled versions of OpenSSL may not include all the ciphers listed here because some ciphers were excluded at compile time.

EXAMPLES

Verbose listing of all OpenSSL ciphers including NULL ciphers:

 openssl ciphers -v 'ALL:eNULL'

Include all ciphers except NULL and anonymous DH then sort by strength:

 openssl ciphers -v 'ALL:!ADH:@STRENGTH'

Include all ciphers except ones with no encryption (eNULL) or no authentication (aNULL):

 openssl ciphers -v 'ALL:!aNULL'

Include only 3DES ciphers and then place RSA ciphers last:

 openssl ciphers -v '3DES:+RSA'

Include all RC4 ciphers but leave out those without authentication:

 openssl ciphers -v 'RC4:!COMPLEMENTOFDEFAULT'

Include all ciphers with RSA authentication but leave out ciphers without encryption.

 openssl ciphers -v 'RSA:!COMPLEMENTOFALL'

Set security level to 2 and display all ciphers consistent with level 2:

 openssl ciphers -s -v 'ALL:@SECLEVEL=2'

Even Further Details on Certificates:

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—– MIIERDCCAywCAQAwZDELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMQswCQYDVQQKEwJNUzEMMAoG —–END 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:

—–BEGIN CERTIFICATE—– MIIB0TCCATqgAwIBAgIQUq+2SdEkLr5K6xqjSEvRsDANBgkqhkiG9w0BAQUFADAU MRIwEAYDVQQDEwlsb2NhbGhvc3QwHhcNMTIwODA0MDA0OTEyWhcNMTcwODA0MDAw MDAwWjAUMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAKjGuGT8NN5chlGSHIqEgjgceLQOX41f46MvYZMbGecoaF —–END CERTIFICATE—–

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: http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules#DER_encoding

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: http://msdn.microsoft.com/en-us/library/dd921035(v=office.12).aspx

---

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:

• RFC 1421: Part I: Message Encryption and Authentication Procedures
• RFC 1422: Part II: Certificate-Based Key Management
• RFC 1423: Part III: Algorithms, Modes, and Identifiers
• RFC 1424: Part IV: Key Certification and Related Services

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

Bag Attributes     localKeyID: 01 00 00 00     friendlyName: le-cd130455-259a-4b96-a900-94cc74670020     Microsoft CSP Name: Microsoft Enhanced Cryptographic Provider v1.0 Key Attributes     X509v3 Key Usage: 10 —–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,4F53AB2E5701A52B 5XAtCElFXut0HuvYcKefoc+a++xm7tNXgzLGvIQiBgJbBipPLrnqxLr37xofX21u G5lnnPHyPSDTdna9fFryIM5sZQuZsvy1JjFyV4yOu1nl2wdzVRJyW/LSdN964lZV gj3CLaxMce5KL319i3t2A3SeFhMc6KnqxW8XEkkG7MpEhsL3Kz6bf5LJmuVeTfKx 0Ad3lr6t8ct6N8yPIFpqpMR/lHRevHvNilyAeU8dyxg7tzIFQOoapz+s/LjhbZWI XCdz2a/pH2ERFTKzCRg57dmmQ4znyHpiIxn92WOKQChQiDaIysGYBj4hbSZqaB8p 8H4x4t+TDjWcnIKLp5JxUJt3DN3qlzwP2Vdo/KTlFNvnmmEMmoTd931jALuk0+xC PaAz7KM1nDwe7zRwpIXCHkTTPp519icQrXj52tEO7sWhFVkjBaoaBVMeYPnpjb88 == —–END RSA PRIVATE KEY—–

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—– MIICXQIBAAKBgQDedH/Kb8d0oqAu2+huQTHhQbqP1gx2Ae6LOtVejTt1Tg54f/iF 79E8wD/EUKNJ9omWCj4rFsPF6aiN+QNjmJc5zJqH4uCuIS7NeB2DCIeZxtS6f5oS … … qIco7Hxh0B71QnL/22lxAkAXcqs0Ah0yw3+3yBFDJgu1Wj/8gzMMRTrw8B07v13k gFlJxAuPc2ckMXsegTJf+mMaoS59KXMqcNh3B8P4V2ko —–END 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.

Private Key(.key)

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—– MIICXQIBAAKBgQDedH/Kb8d0oqAu2+huQTHhQbqP1gx2Ae6LOtVejTt1Tg54f/iF 79E8wD/EUKNJ9omWCj4rFsPF6aiN+QNjmJc5zJqH4uCuIS7NeB2DCIeZxtS6f5oS BWyoQ/eAjmFE0T/6P/aupsjrrB9qI7mELQnJEikzWCwsiBzSlM+bjdTDeQIDAQAB AoGBAItNyPisJusTK9wsOdFRYjr9Pib0k7kSXJ8zqIodRy6eQtGS0b6N/ylb+pKl LJwUlvQuVeAF0XMOb074sPadh5Suyos/Sa8OuHDDRmhxTQjk03EUhXrpGkA7WCU6 VdIf7xyCZFOc4RXy222xHfweZohEZ6qEdqyn7Cy6yQrHJKkBAkEA/15+gomP9rt4 M3Pyp+r2GsCm6aq1lHzF+/Req1Tzj/h4DlBN9dCNH2NnRFJ3S1GbrSsPR9YTpitu U+eah7+JXQJBAN8BMFa6bye1gc7Y/4McOfeNzUXzQc1TCCwdRxlF7VBxJkOcD3FD 53Ur/TSQL++TaE+ihsuQLUBnO31aJXOSlM0CQQCd83yckSmSmvIGITl90z7V3UNg VE5rwaFT7hqALtNXwX/AmrsdyBkBySIeiENxOtDnkzKoZClTJpnfG+ng/P+hAkA7 aWGreXfrqFuw8/b+wyJeZZTuseQyA5EFz7cFcK/M4phDIuyqTGD5woJu4osi1K7R qIco7Hxh0B71QnL/22lxAkAXcqs0Ah0yw3+3yBFDJgu1Wj/8gzMMRTrw8B07v13k gFlJxAuPc2ckMXsegTJf+mMaoS59KXMqcNh3B8P4V2ko —–END 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:
http://technet.microsoft.com/en-us/library/cc772898%28WS.10%29.aspx

Scenarios:

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.

1. Right click and select Properties-> Directory Security-> View Certificate.
2. Now go to the details tab and click on “Copy to File…”
3. 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
4. If the private key was not marked as exportable, earlier when the certificate was created the first time, then the first option would be grayed out.
5. Select the first option “Yes, export the private key” and click on Next.
6. In the next window the “Personal Information Exchange – PKCS#12 (.PFX)” will be selected provided with three checkboxes. Select the first and third option and then click on Next.
7. Type in the password if required and then click on Next.
8. Browse to the location where you want to save the file (in .pfx format) and then click on Next.
9. Click on Finish, you would get a small prompt saying “The export was successful”
10. Click on OK and it’s done.

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.