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/

I’ve covered how to convert an SSL cert to a .pem with a private key for a Netscaler before here but sometimes you might be required to install a full SSL cert chain (read my article here on how SSL certificate chains work). I actually install the full SSL chain (root and intermediate certs) on any Netscaler I deploy as a best practice.

I’m going to use Network Solutions again in this example but this will work for Verisign, GeoTrust, Thawte, Comodo, or any other CA (certificate authority).

Here is how you do it on the Netscaler:

1. I’m going to assume you have already generated a CSR (either through the appliance or IIS, whatever your preference), had your cert validated, and have downloaded your site cert and intermediate/root certs from Network Solutions since I have covered this before in the articles I mentioned above.

2. Now just login to your Netscaler, install your website cert that was issued to you first under SSL > Certificates on the Netscaler.

3. At this point, if your website is publicly available, let’s examine the cert chain. Go to http://www.sslshopper.com/ssl-checker.html and type in your website (if it’s not publicly available, use OpenSSL which I have written about here). Since you have not installed intermediate certs on your Netscaler yet, it should report your SSL cert is good but your SSL cert chain is broken like below:

4. Now go back to your Netscaler and install the two intermediate certs and one root cert that Network Solutions has give you. You really only need the intermediate cert but I like to install them all just in case. They are in .crt format when you get them from Network Solutions and that is fine, no need to convert. Just go to SSL > Certificates on the Netscaler and click Add in the bottom toolbar. Give it a name and use Browse (Local) to find your certs and install all 3 one by one. Here is what it should look like when you are done:

5. Now here comes the most important part. You need to link the intermediate cert (NetworkSolutions_CA) to your site’s SSL cert. Right click on your site’s SSL cert and hit “Link”. Now choose the NetworkSolutions_CA cert in the drop down box and press OK. It will confirm the cert is now linked. The Netscaler actually supports up to a 10 cert chain so you can have your website cert + 9 more intermediate certs linked to it if you want. So feel free to link more if you need to at this point. You can also click on the “Cert Links” button in the bottom toolbar and it will show you all your links. For example, here is a Netscaler with 3 certs from Network Solutions that have been linked to the “NetworkSolutions_CA” cert:

6. Now go back to http://www.sslshopper.com/ssl-checker.html and try your domain again. This time it will say your SSL chain is good:

Here’s an example where I linked each intermediate cert chain all the way down to the root certificate. I would recommend you link all your certs down to the root as a best practice:

Also, Citrix put together this really good guide on SSL cert chains I am hosting here for you. It’s a great read with plenty of screenshots so take a look:

Citrix_Verisign_NetScaler_SSL_Cert_Deployment_Guide

Cisco WLC (Wireless LAN Controllers) require the entire SSL cert chain to be installed on the appliance. I like to do this via IIS since it is very quick and efficient and all my intermediate and root certs are already on there typically (double check your servers please).

1. Create a temporary site in IIS and generate a CSR. Make sure the domain matches whatever appliance you are trying to generate it for exmp: wireless.yourcompany.com.

If you are exporting a wildcard cert that might already be on your IIS server, just export it as a PFX and skip to step 5.

2. Send the CSR to your registrar and wait for them to validate.

3. Get the .crt and convert it to .cer (just open the .crt and save it as .cer). Do the same for the intermediate and root certs you received.

4. Install the .cert in IIS as well as all intermediate and root certs they send you.

5. “View” the cert in IIS (Site properties > Directory Security > View Certificate > Details Tab > Copy to File) and export it with the private key in pkcs12 (.pfx) format. Also make sure to check “Include all certificates in the certification path is possible”. Just set the password as “password” so it’s easy to remember.

6. Now you have a .pfx with your whole SSL cert chain but you need to convert it to .pem for the WLC.

7. Use this command with OpenSSL:

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

8. Type the “password” when prompted

9. TFTP the new .pem containing the whole SSL cert chain and private key over to the WLC and reboot. You will have to specify the “password” when you type in your TFTP info and Save and Reboot the WLC after the download is successful. Test it out and it should work.

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.