JasonSamuel.com

There are 4 easy ways to check that SSLv2 and weak ciphers are disabled on your web servers and appliances. SSLv2 is deprecated and should never be used. You will definitely need to verify these are disabled for PCI compliance and SOX compliance. The instructions below apply to check SSLv2 on any web server (IIS, Apache, iPlanet, etc.) or any traffic or load balancing appliance (Citrix Netscaler, F5 BigIP, etc.).

1. SSLDigger - Download it here http://www.foundstone.com/us/resources/proddesc/ssldigger.htm. It’s a great little tool that first tests for SSLv2, then gives you the option to test for weak ciphers one by one, then spits our a nice little HTML report of the findings. You can even create a .txt file with all your URLs to test and perform testing in bulk. This is wonderful when you have many domains to test and need to give a report to management quickly.

Checking the Google.com SSL cert (click to enlarge):

Checking for weak ciphers systematically (click to enlarge):

HTML report (click to enlarge):

2. OpenSSL – The old favorite. Type the following to connect to your web server or appliance over SSLv2:

openssl s_client -connect www.yourdomain.com:443 -ssl2

It should connect giving you a CONNECTED(000007C0) message but then immediately fail and display an error message like one of the following:

419:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:
420:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher list:s2_clnt.c:450:
10076:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:. \ssl\s2_pkt.c:428:
write:errno=548965:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:
write:errno=10054

SSL handshake failures and connection resets (errno=10054) are completely normal if SSLv2 is disabled. The specific error message you get will depend on exactly what behavior your web server or appliance is configured to do when a client connects using it.

Example of SSLv2 disabled:

Example of SSLv2 enabled (VERY VERY BAD!):

3. Nessus – Download it here http://www.nessus.org and use the Home Feed and setup a new scan using the SSL Anonymous Cipher Suites Supported and SSL Version 2 (v2) Protocol Detection plugins. Please make sure to disable all the other plugins, you don’t want all that hitting your server. Just these 2 are sufficient. Then check the Reports and see if it is reporting SSLv2 as a vulnerability.

4. External SSL checkers – Running nice little tools like the above three is nice to check your servers when you are internal but if you want to see what 3rd parties are seeing externally, use one of these online SSL checkers to test:

http://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm
http://www.dnsstuff.com/tools/

Often times you might have to add an SSL cert to a Cisco or Citrix appliance but it only accepts the SSL cert and private key in a certain format.  Your CA (certificate authority) will issue the SSL cert to you as a .crt.  From there, you need to package the cert with the private key and in the format your appliance requires.  There are different ways to do this and one easy way I like is using IIS and OpenSSL which is a free open source tool and can be downloaded here:  http://www.openssl.org

1. Create a temporary site in IIS and generate a CSR.  Make sure the CN (common name) you enter matches whatever appliance you are trying to generate it for exmp:  wireless.mycompany.com

2.  Submit the CSR to your CA such as Verisign, GoDaddy, Network Solutions, etc. and wait for them to validate and issue your cert.

3. Get the .crt from the CA once they issue it and convert it to .cer.  Just open the .crt by double clicking on it and and save it as .cer using the export wizard.  This is necessary since IIS does not accept .crt.

4. Install the .cer in IIS using the Web Server Certificate Wizard where you originally generated the CSR.  Just process the pending request to install it.

5. View the cert in IIS and export it with the private key in pkcs12 (.pfx) format.  Just set the password as “password” since you will be deleting it after conversion is complete later.

6. Go to the directory where OpenSSL.exe is and type in the following to convert the .pfx to a .pem

openssl pkcs12 -in nameofcert.pfx -out nameofcert.pem

7. Type the “password” when prompted for the pass phrase.

8. Install the .pem on the appliance and it should work

IMPORTANT NOTE:

If you are doing it for some appliances like a Cisco IronPort, you need to add the nodes switch when creating the .pem:

openssl pkcs12 -in nameofcert.pfx -out nameofcert.pem –nodes

The –nodes switch ensures that the key inside the .pem is left unencrypted.  If you attempt to install a .pem created without the -nodes switch, the appliance will take the cert but will not accept the private key since it cannot read it in an encrypted state.

Today I would like to clear up some confusion about SSL Chained Certificates. For this example, I will use Network Solutions as the Certificate Authority (CA) you are buying the cert from. This is information you will have to know when you purchase a new SSL cert or renew an existing SSL cert for your Exchange server, IIS web server, or any other external facing server or appliance.

Network Solutions does not issue you a single cert. They issue you an SSL chained cert. So for example, if you are buying a cert for:

widgets.com

They will validate and issue you the cert, but when you download and open the zip file from their website, you will see the following certificate bundle:

AddTrustExternalCARoot.crt
NetworkSolutions_CA.crt
WIDGETS.COM.crt
UTNAddTrustServer_CA.crt

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 WIDGETS.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 (widgets.com).

In most cases, any sever or appliance out there will already have the trusted root cert for Network Solutions installed. You can just install your SSL cert and not have to worry about anything else in most cases. Depending on where you buy your cert from and what you are trying to install your cert to, you may have to go through the steps of installing the Trusted Root cert and Intermediate cert first before installing your SSL cert. With some web browsers like Internet Explorer 7 for example, you can get away with not having to install any Intermediate Certificate because IE7 will automatically go out automatically download the intermediate cert the first time a user visits your website. This makes things easy for the lazy admin but it’s always best practice to go a head and add the Intermediate cert on your end instead of depending on the client and their browser’s ability to do this. There is no point in risking a certificate error for the end user when the fix is so easy.

To verify the chain, go to any site you know that uses SSL (https://) and then click on the lock in Internet Explorer, it will let you view the SSL cert info. Click the “Certificate Path” tab and you can see the chain we described above:

Trusted Root —> Intermediate —> SSL Certificate

You can then click on each one of these certs and hit the “View Cert” button to view each cert in the chain individually. Good luck and post a comment if you have any questions.