One of the most popular commands in SSL to create, convert, manage the SSL Certificates is OpenSSL. There are many cases nowadays where OpenSSL have to be used in various ways. Below are the most common commnads used for managing Certficates, ciphers, encryption, et all. OpenSSL includes tonnes of features covering a broad range of use cases, and it’s difficult to remember its syntax for all of them and quite easy to get lost. Helppages are not so helpful here, so often we just Google “openssl how to [use case here]” or look for openssl cheatsheet to recall the usage of a command and see examples.
For indept review and usercases of OpenSSL see

Some of the abbreviations related to certificates.

  • SSL – Secure Socket Layer
  • CSR – Certificate Signing Request
  • TLS – Transport Layer Security
  • PEM – Privacy Enhanced Mail
  • DER – Distinguished Encoding Rules
  • SHA – Secure Hash Algorithm
  • PKCS – Public-Key Cryptography Standards

Create new Private Key and Certificate Signing Request

openssl req -out domain.csr -newkey rsa:2048 -nodes -keyout domain.key

Above command will generate CSR and 2048-bit RSA key file. If you intend to use this certificate in Apache or Nginx, then you need to send this CSR file to certificate issuer authority, and they will give you signed certificate mostly in der or pem format which you need to configure in Apache or Nginx web server.

Create a Self-Signed Certificate (default is 30 days)

openssl req -x509 -sha256 -nodes -newkey rsa:2048 -keyout domain_selfsigned.key -out domain_cert.pem

Above command will generate a self-signed certificate and key file with 2048-bit RSA. I have also included sha256 as it’s considered most secure at the moment.

Create a Self-Signed Certificate (custom, 2 years)

Tip: by default, it will generate self-signed certificate valid for only one month so you may consider defining –days parameter to extend the validity.

openssl req -x509 -sha256 -nodes -days 750 -newkey rsa:2048 -keyout  domain_selfsigned.key  -out domain_cert.pem

Verify CSR file

openssl req -noout -text -in domain.csr

Verification is essential to ensure you are sending CSR to issuer authority with required details.

Create RSA Private Key

openssl genrsa -out private.key 2048

If you just need to generate RSA private key, you can use the above command. I have included 2048 for stronger encryption.

Remove Passphrase from Key

openssl rsa -in certkey.key -out nopassphrase.key

If you are using passphrase in key file and using Apache then every time you start, you have to enter the password. If you are annoyed with entering a password, then you can use above openssl rsa -in domain.key -check to remove the passphrase key from an existing key.

Verify Private Key

openssl rsa -in certkey.key –check

If you doubt on your key file, you can use the above command to check.

Verify Certificate File

openssl x509 -in certfile.pem -text –noout

If you would like to validate certificate data like CN, OU, etc. then you can use an above command which will give you certificate details.

Verify the Certificate Signer Authority

openssl x509 -in certfile.pem -noout -issuer -issuer_hash

Certificate issuer authority signs every certificate and in case you need to check them.

Check Hash Value of A Certificate

openssl x509 -noout -hash -in domain.pem

Convert DER to PEM format

openssl x509 –inform der –in sslcert.der –out sslcert.pem

Usually, certificate authority will give you SSL cert in .der format, and if you need to use them in apache or .pem format then the above command will help you.

Convert PEM to DER format

openssl x509 –outform der –in sslcert.pem –out sslcert.der

In case you need to change .pem format to .der

Convert Certificate and Private Key to PKCS#12 format

openssl pkcs12 –export –out sslcert.pfx –inkey key.pem –in sslcert.pem

If you need to use a cert with the java application or with any other who accept only PKCS#12 format, you can use the above command, which will generate single pfx containing certificate & key file. You can also include chain certificate by passing –chain as below.

openssl pkcs12 –export –out sslcert.pfx –inkey key.pem –in sslcert.pem -chain cacert.pem

Create CSR using an existing private key

openssl req –out certificate.csr –key existing.key –new

If you don’t want to create a new private key instead using an existing one, you can go with the above command.

Check contents of PKCS12 format cert

openssl pkcs12 –info –nodes –in cert.p12

PKCS12 is binary format so you won’t be able to view the content in notepad or another editor. The above command will help you to see the contents of PKCS12 file.

Convert PKCS12 format to PEM certificate

openssl pkcs12 –in cert.p12 –out cert.pem

If you wish to use existing pkcs12 format with Apache or just in pem format, this will be useful.

Test SSL certificate of particular URL

openssl s_client -connect –showcerts

I use this quite often to validate the SSL certificate of particular URL from the server. This is very handy to validate the protocol, cipher, and cert details.

Find out OpenSSL version

openssl version

If you are responsible for ensuring OpenSSL is secure then probably one of the first things you got to do is to verify the version.

18Check PEM File Certificate Expiration Date

openssl x509 -noout -in certificate.pem -dates

Useful if you are planning to put some monitoring to check the validity. It will show you date in notBefore and notAfter syntax. notAfter is one you will have to verify to confirm if a certificate is expired or still valid.


[root@Chandan opt]# openssl x509 -noout -in bestflare.pem -dates
notBefore=Jul 4 14:02:45 2015 GMT
notAfter=Aug 4 09:46:42 2015 GMT

Check Certificate Expiration Date of SSL URL

openssl s_client -connect 2>/dev/null | openssl x509 -noout –enddate

Another useful if you are planning to monitor SSL cert expiration date remotely or particular URL.


[root@Chandan opt]# openssl s_client -connect 2>/dev/null | openssl x509 -noout -enddate

notAfter=Dec 8 00:00:00 2020 GMT

Check if SSL V2 or V3 is accepted on URL

To check SSL V2

openssl s_client -connect -ssl2

To Check SSL V3

openssl s_client -connect –ssl3

To Check TLS 1.0

openssl s_client -connect –tls1

To Check TLS 1.1

openssl s_client -connect –tls1_1

To Check TLS 1.2

openssl s_client -connect –tls1_2

If you are securing web server and need to validate if SSL V2/V3 is enabled or not, you can use the above command. If activated, you will get “CONNECTED” else “handshake failure.” For all risks associated with SSL vulnerabilities please visit

Verify if the particular cipher is accepted on URL

openssl s_client -cipher 'ECDHE-ECDSA-AES256-SHA' -connect

If you are working on security findings and pen test results show some of the weak ciphers is accepted then to validate, you can use the above command.

Of course, you will have to change the cipher and URL, which you want to test against. If the mentioned cipher is accepted, then you will get “CONNECTED” else “handshake failure.”



There are two types of vulnerabilities:

  • SSL Certificate Vulnerabilities
  • SSL Endpoint Vulnerabilities

SSL Certificate Vulnerabilities

Certificate Name Mismatch

If the exact domain name (FQDN) in the SSL Certificate does not match the domain name displayed in the address bar of the browser

Internal names

After November 1, 2015, CAs will no longer issue certificates to internal names. Internal names cannot be implicitly validated because they cannot be externally verified.

Missing or Misconfigured Fields and Values in Certificates

Certificates that do not contain the necessary fields and values may cause browsers to display warnings.

SHA-1 Hashing Algorithm

The current acceptable key strength for an RSA (Rivest-Shamir-Adleman) key is 2048 bits. Certificates must be generated with an RSA key of 2048 bits or higher.

Weak Hashing Algorithm

Algorithms once thought of as secure and unbreakable have become either weak or breakable. For example, MD5, RC4, etc

Weak Keys

Exhaustive key searches/brute force attacks are a danger to any secure network. As computational power increases, so does the need for stronger keys.

SSL Endpoint Vulnerabilities

How to do SSL protocol check

For general SSL checking of a website protocols in use: or:
The easiest way to amend (enable/disable) protocols in use is achieved by a tool called ”IISCripto” at

These are the IISCripto tool Features supported:

  • Single click to secure your site using best practices
  • Stop FREAK, BEAST and POODLE attacks
  • Easily disable SSL 2.0 and SSL 3.0
  • Enable TLS 1.1 and 1.2
  • Disable other weak protocols and ciphers
  • Enable forward secrecy
  • Reorder cipher suites
  • Templates for compliance with government and industry regulations – FIPS 140-2 and PCI


We’ve been seeing a lot of requests to implement TLS_FALLBACK_SCSV. Unfortunately, it only works if you already have clients that understand it. This article will give some background, discuss TLS downgrades and finally have some suggestions for what you can do now.

Over the years, cryptographers have worked with Internet engineers to improve the Transport Layer Security (TLS) protocol. Each revision of the protocol provides improvements to defend against the latest attacks devised by the cryptographers.
In 2011, Thai Duong and Juliano Rizzo demonstrated a proof-of-concept for attacks against the way SSL/TLS use the Cipher Block Chaining (CBC) mode of encryption. Their paper introduced the Browser Exploit Against SSL/TLS (BEAST) and used it to demonstrate how a “man-in-the-middle” (MITM) with the ability to run Javascript on the victim client could generate many thousands of TLS sessions and eventually recover a session cookie.
The defense against the BEAST attack was included in TLS 1.1, but few web servers or clients migrated right away.

POODLE is a similar attack to BEAST, but works against SSLv3 due to the special structure of the padding in SSLv3. Part of the POODLE attack is a downgrade to SSLv3.

TLS Downgrades
TLS agents should negotiate the highest version of the protocol supported by client and server. Clients advertise the highest version of the protocol they support. The server selects the highest version it supports, and sends the negotiated version number in the ServerHello message.

Many broken TLS implementations in widespread use were unable to cope with versions they did not understand. This caused large numbers of TLS sessions to break during the TLS 1.1 rollout.

The browser vendors implemented a downgrade mechanism. Immediately after a session fails during the initial handshake, the browser will retry, but attempt a max version one lower than before. After attempting to connect to a server with the max version set to TLS1.1, the client would retry with the max version set to TLS1.0.

Security researchers love automatic downgrades because they get to attack older protocols instead of newer, more secure protocols. A MITM attacker can break client connections during the initial TLS handshake, triggering a downgrade all the way to SSLv3.

Bodo Möller and Adam Langley devised Signaling Cipher Suite Value (SCSV) ,TLS_FALLBACK_SCSV, so the client can inform the server of a downgraded connection. It indicates to the server that the client had previously attempted to connect using a higher max protocol version, but the session was broken off before the initial handshake could be completed.

If the server sees the SCSV, and if it could have negotiated a protocol version higher than what the client is currently announcing as its maximum, the server must break the connection.

On October 21, Möller and Langley presented to members of the IETF TLS Working Group to lay out their rationale and argue for inclusion of the TLS_FALLBACK_SCSV draft in the upcoming revision to TLS.

The key points to their argument are presented on page 3:

Ideally, stop doing downgrade retries
If that’s not practical, clients should add TLS_FALLBACK_SCSV to ClientHello.cipher_suites in fallback retries
Servers that detect TLS_FALLBACK_SCSV will reject the connection if ClientHello.client_version is a downgrade

Möller and Langley implemented TLS_FALLBACK_SCSV in Chrome, Firefox, and Google servers earlier in 2014. During the past several months, they’ve had an opportunity to confirm that it allows SSLv3 connections only in cases where that is truly the highest common protocol version.

On October 15, OpenSSL for the first time integrated TLS_FALLBACK_SCSV code.

Upgrade your clients
The best protection against POODLE is to disable SSLv3. That is not always possible because of legacy clients. Unfortunately, TLS_FALLBACK_SCSV requires both clients and servers to implement it. Legacy clients will not send TLS_FALLBACK_SCSV. You must update the clients to newer code to get all the advantages of TLS_FALLBACK_SCSV.
If you can update all your clients to code that supports TLS1.x, then you can successfully disable SSLv3 from your BIG-IPs using either method described earlier.
If you can’t upgrade your clients, you can avoid POODLE by using SSL3’s RC4 stream cipher instead of a block cipher with CBC. Be aware that there are known weaknesses in RC4.

RC4 usage


  • SSLv2: Released in 1995. Most modern clients do not support SSLv2, but the DROWN attack demonstrated that merely serving SSLv2 enables the inspection of traffic encrypted with more modern TLS versions.
  • SSLv3: Released in 1996. Considered to be insecure after the POODLE attack was published in 2014. Turning off SSLv3 effectively removes support for Internet Explorer 6.


SSLv3 POODLE mitigation recommendations

In our previous post, we discussed POODLE and legacy SSLv3 clients.
The best solution to POODLE is to disable SSLv3.
However, SSLv3 often can’t be disabled because legacy clients only speak SSLv3.
F5’s security teams have done some investigation, and we believe that using the RC4 can be used as POODLE mitigation for those legacy clients. RC4 is a stream cipher and is not vulnerable to the POODLE attack.
RC4 does have a known weakness. After hundreds of millions of messages, an attacker could recover the plaintext.
POODLE can recover information after only tens of thousands of attacks.
So even though RC4 is not recommended as a cipher, it remains more secure to use in SSLv3 sessions than AES-CBC.
If you cannot disable SSLv3, you may enable RC4-SHA only for use in SSLv3 sessions until you are able to replace all the legacy clients.
To configure your virtual server to only allow SSLv3 RC4-SHA, use a cipher string like the following:
“Default” sets the default ciphers, “-RC4″ removes any ciphers that contain RC4 (this is optional). “-SSLv3” removes any SSLv3 ciphers, but “SSLv3+RC4-SHA” re-enables only the RC4-SHA cipher from SSLv3. Any client connecting via SSL3 will be forced to use RC4 rather than a CBC cipher that is vulnerable to POODLE.
See SOL 13171 for information on setting your cipher string.
There are known attacks against RC4 that are better than brute-force. But given POODLE, RC4 is the most secure SSLv3 cipher.
It is still recommended to disable SSLv3 and RC4 once you are able to remove all legacy clients.

Who still needs RC4

At the time we had an internal debate about turning off RC4 altogether, but statistics showed that we couldn’t. Although only a tiny percentage of web browsers hitting CloudFlare’s network needed RC4 that’s still thousands of people contacting web sites that use our service.
To understand who needs RC4 I delved into our live logging system and extracted the User-Agent and country the visitor was coming from. In total, roughly 0.000002% of requests to CloudFlare use the RC4 protocol. It’s a small number, but it’s significant enough we believe we need to continue to support it for our customers.
Requests to CloudFlare sites that are still using RC4 fall into four main categories: people passing through proxies, older phones (often candy bar), other (more on that below) and a bucket of miscellaneous (like software checking for updates, old email programs and ancient operating systems).


Examining data for a 59 hour period last week showed that 34.4% of RC4-based requests used RC4-SHA and 63.6% used ECDHE-RSA-RC4-SHA. RC4-SHA is the oldest of those; ECDHE-RSA-RC4-SHA uses a newer elliptic curve based method of establishing an SSL connection. Either way, they both use the RC4 encryption algorithm to secure data sent across the SSL connection. We’d like to stop supporting RC4 altogether, because it is no longer believed to be secure, but continue to offer it for the small number of clients who can’t connect more securely.

If you ever need to know the details of an SSL cipher you can use the openssl ciphers command:

$ openssl ciphers -tls1 -v RC4-SHA
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1

which shows that RC4-SHA uses RSA for key exchange, RSA for authentication, RC4 (128-bit) for encryption and SHA1 for message authentication.


$ openssl ciphers -tls1 -v ECDHE-RSA-RC4-SHA

shows that the same encryption, authentication and message authenitication are used as RC4-SHA but the key exchange is made using Elliptic Curve Diffie Hellman.

Inside RC4

One of the reasons RC4 is used for encryption is its speed. RC4 is a very fast encryption algorithm and it can be easily implemented on a wide variety of hardware (including phones with slow processors and even on 8-bit systems like the Arduino). After all, RC4 dates back to 1987.

The core of RC4 is the following algorithm:

i := 0
j := 0 
while GeneratingOutput:
    i := (i + 1) mod 256
    j := (j + S[i]) mod 256
    swap values of S[i] and S[j]
    K := S[(S[i] + S[j]) mod 256]
    output K

It generates a pseudo-random stream of numbers (all 8-bit numbers in the range 0 to 255) by doing simple lookups in a table, swapping of values and addition modulo 256 (which is very, very fast). The output of that algorithm is usually combined with the message to be encrypted byte-by-byte using some fast scheme like an XOR.

The following short video shows the RC4 algorithm in action. It’s been restricted to 32 values rather than 256 to fit it nicely on the screen but the algorithm is identical. The red stream of numbers at the bottom shows the pseudo-random stream output by the algorithm. (The code for this animation is available here; thanks to @AntoineGrondin for making the animated GIF).

So, RC4 is fast, but who’s still using it? To answer that I looked at the HTTP User-Agent reported by the device connecting to CloudFlare. There were 292 unique User-Agents.

Who still uses RC4?

Firstly, lots of people using older “candy bar” style phones. Phones like the Nokia 6120 classic which was released in 2007 (and is the phone with the greatest number of RC4 requests to CloudFlare sites: 4% of the RC4-based requests in the measurement period), the Lemon T109 or the Sony Ericcson K310 which was released in 2006.

And, of course, it’s not all older telephones being used to visit CloudFlare-powered web sites. There are old browsers too. For example, we’ve seen the now ancient iCab 2.9.9 web browser (it was released in 2006) and we’ve seen it being used running on a 68k based Macintosh (last sold by Apple in 1996).

Another source of RC4-only connections is older versions of Adobe AIR. AIR is often used for games and if users don’t update the AIR runtime they can end up using the older RC4 cipher.

Yet another source is stand-alone software that makes its own SSL connection. We’ve seen some software checking update servers using RC4-secured connections. The software makes a connection to its own update server using HTTPS but the available ciphers are limited and RC4 is chosen. The command-line program curl was used to generate 1.9% of RC4-based requests to CloudFlare sites (all done with versions dating to 2009).

There’s also quite a bit of older Microsoft Internet Explorer around including Internet Explorer 5.01 (which dates back to 1999!). Here’s a breakdown of Internet Explorer versions connecting using RC4:

Looking at Windows tells a similar story of older version of the operating system (except for the presence of Windows 7 which is explained below) with lots of Windows XP out there:

I sampled connections using RC4 to see which countries they came from. The following mapping shows the distribution of RC4-based connections across the world (the darker the more RC4 was used).

From the map you can see that in Brazil, India, and across central Africa RC4 is still being used quite widely. But you’ll also notice that the coloring of the US indicates that a lot of RC4 is in use there. That seems like a surprise, and there’s an extra surprise.

Transparent SSL Proxies

Digging into the User-Agent data for the US we see the following web browser being used to access CloudFlare-powered sites using RC4:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/34.0.1847.137 Safari/537.36

That’s the most recent version of Google Chrome running on Windows 7 (you can see the presence in Windows 7 in the chart above). That should not be using RC4. In fact, most of the connections from Windows machines that we see using RC4 should not be (since we prioritize 3DES over RC4 for older machines).

It was initially unclear why this was happening until we looked at where the connections were coming from. They were concentrated in the US and Brazil and most seemed to be coming from IP addresses used by schools, hospitals and other large institutions.

Although the desktop machines in these locations have recent Windows and up to date browsers (which will not use RC4) the networks they are on are using SSL-based VPNs or firewalls that are performing man-in-the-middle monitoring of SSL connections.

This enables them to filter out undesirable sites, even those that are accessed using HTTPS, but it appears that the VPN/firewall software is using older cipher suites. That software likely needs updating to stop it using RC4 for secure connections.

What you can do

You can check the strength of your browser’s SSL configuration by visiting How’s My SSL. If you get a rating of “Probably Okay” then you’re good. If not make sure you have the latest browser version.

BEAST – (Browser Exploit Against SSL/TLS)

Block-based cipher suites are vulnerable to the BEAST attack. Older versions of the TLS protocol (1.0) and the SSL protocol (2.0 and 3.0) are vulnerable to the BEAST attack. To fix it you need to:
– Enable TLS 1.1 and/or TLS 1.2 on servers that support TLS 1.1 and 1.2.
– Enable TLS 1.1 and/or TLS 1.2 in Web browsers that support TLS 1.1 and 1.2.

BREACH (Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext)

BREACH attacks are similar to the CRIME attack. Known as CVE-2013-3587, or Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) is an instance of CRIME against HTTP Compression. That is to say that CRIME attacked TLS SPDY whereas BREACH targets HTTP gzip/DEFLATE. Therefore turning off the TLS compression has no affect on BREACH as it exploits the underlying HTTP compression. The attack follows the basic steps of the CRIME attack and there are several methods to remediate the issue, such as disabling HTTP compression, protecting the application from CSRF attacks, randomising CSRF tokens per request to prevent them being captured, obfuscating the length of page responses by adding random amounts of arbitrary bytes to the response.
Web Server: Turn off compression for pages that include PII (Personally Identifiable Information).
Web Browser: Force browser not to invite HTTP compression use.
Web Applications:
– Consider moving to Cipher AES128.
– Remove compression support on dynamic content.
– Reduce secrets in response buddies.
– Use rate-limiting requests.

CRIME (Compression Ratio Info-leak Made Easy)

The Transport Layer Security (TLS) protocol contains a feature that allows you to compress the data passed between the server and the Web browser. TLS data compression is susceptible to the CRIME exploit. CRIME targets cookies over connections that use HTTPS protocol (Hyper Text Transfer Protocol with Secure Sockets Layer) and SPDY protocol (Web protocol from Google), which employ TLS data compression.
In a CRIME attack, the attacker recovers the content of secret authentication cookies and uses this information to hijack an authenticated web session. The attacker uses a combination of plaintext injection and TLS compression data leakage to exploit the vulnerability. The attacker lures the Web browser to make several connections to the website. The attacker than compares the size of the ciphertexts sent by the browser during each exchange to determine parts of the encrypted communication and hijack the session.
If you are vulnerable to the CRIME attack, the highest grade you can receive is a C. To resolve it:
– Disable server (website) TLS data compression and Web browser TLS data compression.
– Modify gzip to allow for explicit separation of compression contexts in SPDY.

FREAK (Factoring Attack on RSA-EXPORT Keys)

A team of researchers revealed that the old export-grade cryptographic suites are still being used today. Servers that support RSA export cipher suites could allow a man-in-the-middle (MITM) to trick clients, who support the weak cipher suites, into using these weak 40- and/or 56-bit export cipher suites to downgrade their connection. The MITM can then use today’s computing power to crack those keys in just a few hours.

To fall into this attack:
Server: The server must support RSA export cipher suites.
Client: The client must do one of the following: (1) must offer an RSA export suite, or (2) must be using Apple SecureTransport, or (3) must be using a vulnerable version of OpenSSL, or (4) must be using Secure Channel (Schannel).

To fix it:
Server-Side: Disable support for all export-grade cipher suites on your servers. We also recommend that you disable support for all known insecure ciphers (not just RSA export ciphers), disable support for ciphers with 40- and 56-bit encryption, and enable forward secrecy.
Client-Side: Vulnerable clients include software that rely on OpenSSL or Apple’s Secure Transport (i.e., Chrome, Safari, Opera, the Android and the BlackBerry stock browsers), or Windows Secure Channel/Schannel (i.e. Internet Explorer). FREAK vulnerability patched in latest OpenSSL Release.

Heartbleed Bug

The cryptographic libraries in OpenSSL versions 1.0.1 through 1.0.1f and 1.0.2-beta1 are vulnerable to the Heartbleed Bug attack.
Solution is to Patch your software. Upgrade to the latest version of OpenSSL (version 1.0.1g or later).

Insecure TLS Renegotiation

The Secure Socket Layer (SSL)/Transport Layer Security (TLS) protocol contains a session renegotiation feature that permits a server and client to use their connection to establish new parameters and generate new keys during the session.
To fix it: Make sure your servers support secure negotiations by running current versions of the SSL/TLS protocol. Servers should not be running SSL 2.0, an outdated version of SSL that has known vulnerabilities.

Logjam Attack

Researchers found that old DHE export-grade cryptographic suites are still being used. They also discovered that servers with support for these DHE_EXPORT cipher suites enabled could allow a man-in-the-middle (MITM) to trick clients that support the weak DHE_EXPORT cipher suites into downgrading their connection to a 512-bit key exchange.

To fix it:
– Disable support for all DHE_EXPORT cipher suites on your servers.
– Generate a strong Diffie-Hellman Parameter, minimum 2048-bits.

BlueKeep (then BlueKeep II, III, IV, V aka DejaBlue)

BlueKeep (CVE-2019-0708) is a security vulnerability that was discovered in Microsoft’s Remote Desktop Protocol, which allows for the possibility of remote code execution. Identified May2019
Then few weeks later further flaws in RDP were found – (CVE-2019-1181 and CVE-2019-1182)
The RDP protocol uses “virtual channels”, configured pre-authentication, as a data path between the client and server for providing extensions. RDP 5.1 defines 32 “static” virtual channels, and “dynamic” virtual channels are contained within one of these static channels. If a server binds the virtual channel “MS_T120” (a channel for which there is no legitimate reason for a client to connect to) with a static channel other than 31, heap corruption occurs that allows for arbitrary code execution at the system level

How to Prevent and Fix BlueKeep

  • First and foremost action is to patch all of your Windows machines (user workstations, servers etc) with the patches released by Microsoft. Even non-supported versions (XP, Vista, 2003) have patches available here.
  • Block RDP port 3389 if not needed (using a network firewall or even the Windows firewall). Especially if port 3389 is accessible from the Internet, this is a huge mistake and you must either block it immediately or patch the system. Currently there are around 1 million unpatched windows machines on the Internet with exposed RDP port.
  • Enable Network Level Authentication (NLA) for RDP connections. NLA requires authentication therefore a possible worm will not be able to propagate to machines having NLA.
  • Similar to point 2 above, disabling Remote Desktop service (if it’s not required) will help to mitigate the issue.

To fix it: KEEP CALM AND START PATCHING – DO NOT RUSH but plan for it!
Permit me to remind you that BlueKeep itself hasn’t been reliably exploited. The threat is real, but it’s not viral or immediate.
Microsoft released patches for the vulnerability on 14 May 2019m valid up to WS2012
First, focus on patching externally facing RDP servers, then move on to critical servers such as domain controllers and management servers. Finally patch non-critical servers that have RDP enabled, along with the rest of the desktop estate. You can find more information on applying the patch from Microsoft’s support pages

RC4 Cipher Enabled

The BEAST attack was discovered in 2011. The solution to mitigating the attack is to enable TLS 1.1 and TLS 1.2 on servers and in browsers. Because RC4 is easy to implement and because of the BEAST attack workaround, the RC4 stream cipher’s use is widespread. One estimate says that RC4 may account for up to 50% of all TLS traffic. (back in 2014)
To fix it:
– Enable TLS 1.2 on servers that support TLS 1.2 and switch to AEAD cipher suites (i.e. AES-GCM).
– Enable TLS 1.2 in browsers that support TLS 1.2.

SSL 2.0 Protocol Enabled

“SSL 2.0 is an outdated protocol version with known vulnerabilities.”
SSL 2.0 protocol was disavowed in 1996 due to known security flaws, some servers are still using it. Servers still using the SSL 2.0 protocol should disable it.

SSL 3.0 Protocol Enabled

While the SSL 3.0 protocol is enabled, a MITM (man-in-middle-attack) can intercept encrypted connections and calculate the plaintext of the intercepted connections.
The most effective way to counter the POODLE attack is to disable the SSL 3.0 protocol.
Disable the SSL 3.0 protocol on the server and enable TLS1.1, and TLS1.2.

TLS 1.0 and TLS 1.1 Protocol Enabled

It’s Time to Disable TLS 1.0 (2019 onwards). Unless you need to support legacy browsers, you should also disable TLS 1.0 and TLS 1.1
Microsoft recommends customers get ahead of this issue by removing TLS 1.0 dependencies in their environments and disabling TLS 1.0 at the operating system level where possible (More details at
If you disable TLS 1.0 and TLS 1.1, the following user agents and their older versions will likely be affected (specific user agent versions on different operating systems may vary).

  • Android 4.3
  • Chrome 29
  • Firefox 26
  • Internet Explorer 10
  • Java 6u45, 7u25
  • OpenSSL 0.9.8y
  • Safari 6.0

SSL/TLS Best Practices (2019+)

Use Secure Protocols – TLS 1.1/1.2/1.3
Use at least 2048-Bit Private Keys
Protect Private Keys
Ensure Sufficient Hostname Coverage
Obtain Certificates from a Reliable CA
Use Strong Certificate Signature Algorithms – SHA256
Use Complete Certificate Chains
Use Secure Cipher Suites:

  • Anonymous Diffie-Hellman (ADH) suites do not provide authentication.
  • Cipher suites with a “NULL” only offer integrity check. They do not offer data encryption and are not secure for most usages.
  • Export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack).
  • Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken.
  • RC4 is insecure.
  • 3DES is slow and weak.

Select Best Cipher Suites
Use Forward Secrecy
Use Strong Key Exchange
Mitigate Known Problems
Use Session Resumption – a performance-optimization technique
Avoid Too Much Security
Use WAN Optimization and HTTP/2
Cache Public Content
Use OCSP Stapling
Use Fast Cryptographic Primitives
HTTP and Application Security
Encrypt Everything
Eliminate Mixed Content
Understand and Acknowledge Third-Party Trust
Use Secure Cookies – Secure Cookie responce header
Secure HTTP Compression
Deploy HTTP Strict Transport Security – HSTS responce header
Deploy Content Security Policy – CSP header
Do Not Cache Sensitive Content
Consider Other Threats
Public Key Pinning (advanced)
DNSSEC and DANE (advanced)

Security Protocol Support by OS Version


Mobile IE version 10 and below
Desktop IE versions 7 and below
Desktop IE versions: 8, 9, and 10PartialPartial
Desktop and mobile IE version 11
Microsoft Edge
Mozilla Firefox 22 and below
Mozilla Firefox 23 to 26PartialPartial
Mozilla Firefox 27 and higher
Google Chrome 21 and below
Google Chrome 22 to 37PartialPartial
Google Chrome 38 and higher
Android 4.3 (Jelly Bean) and below
Android 4.4 (Kitkat) to 4.4.4PartialPartial
Android 5.0 (Lollipop) and higher
Mobile Safari for iOS 4 and below
Mobile Safari versions 5 and higher for iOS 5 and higher
Desktop Safari versions 6 for OS X 10.8 (Mountain Lion)
Desktop Safari versions 7+ for OS X 10.9 (Mavericks)+

Desktop clients

Desktop ClientsTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Windows XP
Windows XP SP3
Windows Vista
Windows 7 SP1
Windows 8PartialPartial
Windows 8.1
Windows 10
MAC OS X 10.2 and 10.3
MAC OS X 10.4 and 10.5
MAC OS X 10.6 and 10.7
MAC OS X 10.8
MAC OS X 10.9
MAC OS X 10.10
MAC OS X 10.11
MAC OS X 10.12
MAC OS X 10.13

Mobile Clients

Mobile ClientsTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Android versions: 1.0 to 4.4.4
Android versions: 5.0 to 8.1 and Android P
iPhone OS versions: 1, 2, 3, and 4
iPhone OS versions: 5, 6, 7, 8, 9, 10, and 11
MobileIron Core versions 9.4 and below
MobileIron Core versions 9.5 and higher
MobileIron Cloud
Windows Phone versions: 7, 7.5, 7.8 and 8
Windows Phone version 8.1
Windows 10 Mobile versions: v1511, v1607, v1703, and v1709


ServersTLS 1.0TLS 1.1TLS 1.2TLS 1.3
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012PartialPartial
Windows Server 2012 R2
Windows Server 2016


LibrariesTLS 1.0TLS 1.1TLS 1.2TLS 1.3
.NET 4.6 and higher
.NET 4.5 to 4.5.2PartialPartial
.NET 4.0Partial
.NET 3.5 and below
OpenSSL versions: 1.0.0 and below
OpenSSL versions: 1.0.1 and higher
Mozilla – NSS versions: 3.13.6 and below
Mozilla – NSS versions: 3.14 to 3.15
Mozilla – NSS versions: 3.15.1 and higher

Even more links


SSL Basic HowTo

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

Table Of Contents

 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
    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—–)

    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 as helping tools to confirm matching


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

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.


  • 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.



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. 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
    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:


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 this .crt

openssl x509 -in somesystemcert.pem >> 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.


  • 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


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.


  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 “” 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:; 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:

subject=/C=AU/ST=New South Wales/L=Sydney/O=Gilbert & Tobin/OU=Law/
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
subject=/C=US/O=DigiCert Inc/ Global Root CA
issuer=/C=US/O=DigiCert Inc/ Global Root CA
subject=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
issuer=/C=US/O=DigiCert Inc/ Global Root CA

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

                b. Or in the case of:

Use in the strict order:



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 (

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

      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/ 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/
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Extended Validation Secure Server CA

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

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

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

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.


# 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 ‘’.

Command Line

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

Windows or DOS:
— copy EssentialSSLCA_2.crt + ComodoUTNSGCCA.crt + UTNAddTrustSGCCA.crt + AddTrustExternalCARoot.crt

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

3.5 Adding GlobalSign Intermediates to ELB

Use DomanSSL with if exact domain is ordered

Use OrganisationSSL with if an Organisation is ordered

NOTE: See what the actual SSL says:

Check the link 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 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. *

  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 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

Certificate Not Trusted Error in Internet Explorer 6
Certificate Not Trusted Error in Firefox 2
Certificate Not Trusted Error in in Firefox 3
Certificate Not Trusted Error in Google Chrome

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. *
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
Email address An email address used to contact your organization.
Public Key The public key that will go into the certificate. The public key is created automatically

FInally verify SSL details at 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.1

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
Certificate chain
 0 s:/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*
   i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
 1 s:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
   i:/C=US/ incorp. by ref. (limits liab.)/OU=(c) 1999 Limited/ Secure Server Certification Authority
Server certificate
subject=/C=US/ST=Texas/L=Carrollton/O=Woot Inc/CN=*
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

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 ( 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

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.2

openssl s_client -showcerts -ssl2 -connect

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

openssl s_client -showcerts -cert cert.cer -key cert.key -connect

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

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


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


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 
  • Upload your certificate:
$ aws iam upload-server-certificate --server-certificate-name file:// --private-key file:// --certificate-chain file:// {"ServerCertificateMetadata":{"Path":"/","Arn":"arn:aws:iam::5xxxxxxxxxxx:server-certificate/","ServerCertificateId":"AXXXXXXXXXXXXXXXXXXXX","ServerCertificateName":"","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/ 443

8. Errors

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


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.


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


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.


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>”


    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

User-added image

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.
User-added image

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.
User-added image
  • Activate the Details tab.
  1. Click Copy to File as shown in the following screen shot.
User-added image
  1. Click Next in the Certificate Export Wizard as shown in the following screen shot.
User-added image
  1. Select the Base-64 encoded X.509 (.CER) option and then click Next as shown in the following screen shot.
User-added image
  1. Click Browse and specify the file name to which you want to export the certificate as shown in the following screen shot.
User-added image
  1. Click Next.
  2. Click Finish as shown in the following screen shot.
User-added image
  1. Click OK as shown in the following screen shot.
User-added image
  1. Transfer the exported certificate to the /nsconfig/ssl directory of the NetScaler appliance as shown in the following screen shot.
User-added image
  1. Install the certificate.

9.View deatails of SSL and exact expiry date:

C:\OpenSSL\bin>openssl x509 -in -text

        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale,, Inc., OU=, CN=Go Daddy Secure Certificate Authority –
            Not Before: Jun 13 08:58:38 2016 GMT
            Not After : Jun 14 17:09:21 2017 GMT
        Subject: OU=Domain Control Validated, CN=*
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points:

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114413.

            Authority Information Access:
                OCSP – URI:
                CA Issuers – URI:

            X509v3 Authority Key Identifier:

            X509v3 Subject Alternative Name:
                DNS:*, DNS:
            X509v3 Subject Key Identifier:
    Signature Algorithm: sha256WithRSAEncryption

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.
DigiCert Utility
  • 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-(
Company Name: yourCompany-digicert-(
Certificate Type: wildcard-digicert-(

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-( This naming convention makes it easier to identify the wildcard certificate so that you can assign it to multiple websites.

DigiCert Utility - Right-Click Menu
  • When you are finished, click Save.


  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 ‘*‘ 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 * 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. * 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



SSL checker

Decoder,checker, matcher, reader:

SSL Server test – SSL and Cipher Suites:

DigiCert check –

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_RC4_128_SHA No TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0 RSA RC4 SHA1
TLS_RSA_WITH_RC4_128_MD5 No TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0 RSA RC4 MD5

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.

  • SSL_CK_RC4_128_EXPORT40_MD5

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.01 (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.


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


You can test it against your OpenSSL installation using

openssl ciphers -v 

to see what’s supported2.

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 certificate3. 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.


SSLProtocolALL -SSLv2 -SSLv3

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:


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.


ssl_prefer_server_ciphers On;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

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 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).


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

   ssl-default-bind-options no-sslv3
   ssl-default-server-options no-sslv3

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.


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.


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.


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_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5
 SSL_FORTEZZA_KEA_WITH_NULL_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_DH_DSS_WITH_3DES_EDE_CBC_SHA        Not implemented.
 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        Not implemented.
 TLS_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5

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_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


SEED ciphersuites from RFC4162, extending TLS v1.0


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.


Additional Export 1024 and other cipher suites

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


Elliptic curve cipher suites.

 TLS_ECDH_anon_WITH_RC4_128_SHA          AECDH-RC4-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_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

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


Pre-shared keying (PSK) ciphersuites

 PSK_WITH_NULL_SHA                         PSK-NULL-SHA
 PSK_WITH_RC4_128_SHA                      PSK-RC4-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
 RSA_PSK_WITH_RC4_128_SHA                  RSA-PSK-RC4-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
 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


Older names used by OpenSSL

The following names are accepted by older releases:



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


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—–“.


 Base64-encoded X.509 Certificate (.cer or .crt)

The Base64 format supports storage of a single certificate. This format does not support storage of the private key or certification path. They are Base64 encoded ASCII files. The encoded string is enclosed between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“. Right click and open a certificate (exported in the base 64 format) in a notepad:

Base-64 encoded Certificate

This file type is used more often for exporting certificates.

DER-encoded binary X.509 Certificate (.cer, .der or .crt)

The Distinguished Encoding Rules (DER) format supports storage of a single certificate. This format does not support storage of the private key or certification path.

DER is on of the encoding formats defined by ASN.1 in X.690. It is a variant or a subset of BER. You can refer the following Wiki article for further read:

Cryptographic Message Syntax Standard (PKCS#7) Certificate (.p7b, .p7r or .spc)

The PKCS #7 format supports storage of certificates and all certificates in the certification path. A PKCS #7 file typically has a .p7b file name extension, but this is not always the case. This again doesn’t support storage of private keys. It is generally used by the CA to provide certificate chain to clients.

However as in the case of any other data file, the creator has the authority to use the existing .p7b extension or change it as desired.

Personal Information Exchange Format (PKCS#12) Certificate (.pfx or .p12)

The Personal Information Exchange format (PFX, also called PKCS #12) defines a file format that can be used for secure storage of certificates (containing both private and public keys), and all certificates in a certification path, protected with a password-based symmetric key. PFX is a predecessor to PKCS#12.

The PKCS #12 formats is the only file format that can be used to export a certificate and its private key. A PKCS#12 certificate containing a private key is shown below:


Certificate containing a private key

Certificate Revocation List (.crl extension)

The Certificate Revocation List or CRL is a file type that identifies whether a certificate has been revocated or not. These files are provided by CA’s. The client browser while accessing a site on HTTPS will use the CRL Distribution Points field in the certificate to download the CRL. Here is one example:


Certificate from depicting the CRL Distribution Points

NOTE: Not all certificates may have CRL distribution points. One good example is a Self-Signed certificate.

Now, once the client (browser) gets the CRL information from the server certificate, it downloads the CRL file and checks the list to ensure that the current certificate is not part of that list. The CA can make the CRL available for download to the client, via HTTP, FTP or any other protocol. Here is the downloaded CRL from the CA:


CRL file downloaded from the CA

Microsoft serialized certificate store (.sst)

This is one of the most rarely used file types. This format allows storage of multiple certificates in one single file. Typically it contains the ROOT CA certificates. It is the only file type which allows to save the certificate store. It preserves the properties of the certificate stores. There is another extension viz. “.STO”. However, I have rarely seen the usage of either of these file types.

Not much documentation is available except this:

Certificate Trust List (.stl)

Certificate Trust List is generally used during SSL/TLS handshake when Client Certificate Authentication comes in to picture. During SSL Handshake the server sends the client the list of the distinguished CA names that it supports as a part of Server Hello message. The Client uses this list to draw up a list of client certificates that is issued by any of the CA’s in the list i.e., only those client certificates which are issued by any of the CA’s in the CTL will be populated. Below is an example of how a CTL looks like


Privacy-enhanced Electronic Mail (.pem)

PEM format is a refinement of base64 encoding. It has been documented in the following RFC’s:

This file format is typically used by OpenSSL to make Private Key available from a .pfx/.p12 file. So this is more widely used in the UNIX/LINUX world and not much in Windows. Once extracted to PEM format, this is how it looks:

Command used to convert PFX to PEM: openssl.exe pkcs12 -in Certificate.pfx -nocerts -out Certificate.pem
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
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4F53AB2E5701A52B 5XAtCElFXut0HuvYcKefoc+a++xm7tNXgzLGvIQiBgJbBipPLrnqxLr37xofX21u
PaAz7KM1nDwe7zRwpIXCHkTTPp519icQrXj52tEO7sWhFVkjBaoaBVMeYPnpjb88 ==

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:, 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—–“.



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

This is more widely used in JAVA & UNIX world.

More on Certificates:

When a certificate request is created for a website in IIS 6, corresponding private key is also created. The requests are stored under the Certificate Enrollment Requests store under Computer account. This contains the private key information corresponding to the request raised.

Once you have submitted the request to the CA. It will process the request and provide a certificate in .cer, crt or .der extension (DER or Base64 encoded). Now the pending request can be processed in the IIS Manager by installing the certificate which was provided by the CA.

Consider, if somehow the request for the certificate was lost i.e., the request under the Certificate Enrollment Requests was removed. Now if you install the certificate on the website you are bound to see some issues due to the missing key information. The SSL handshake will not complete and you will see a “Page cannot be displayed error message” on the browser.

By default a .cer file doesn’t contain a private key. The notion of such file is that the private key already exists on the server and during installation the binds to the certificate. Now since the request (private key) no longer exists the server doesn’t know how to decrypt the information received from client (encrypted using the public key). However, we are not totally helpless. We can try to retrieve the private key for the certificate. Here are the steps to do it:

1. Import the certificate to the personal store of computer account.

2. Now double click the certificate and go to the Details tab. Select the Thumbprint section and copy the value as shown below:


3. We will use certutil tool to map the private key to the certificate. Open a command prompt and execute the following:

Certutil -repairstore my “73 14 b2 20 1c 57 f9 fe 19 36 cf ff 9f cb c9 1e 8c 0f 1a 02

If the command is successful then you will see a confirmation message as shown below:


More information on certutil tool can be found here:


Sometimes the web-administrator has to install the same certificate across various servers in a load balanced server. So, continuing from the above scenario let’s assume the web-admin has to install the cert on other 12 servers. Manually copying the .cer file to every server and running the above command is quite tedious.

Why can’t we export the certificate along with the private key to the other servers and then install it? Well, it can be done, provided the private key has been marked as exportable. Generally, you would see this if the certificate was renewed again with the private key not being exported earlier.

Go to the websites on which the certificate has been installed.

  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.