Are Your SSL Certificates Secure?

If you review your network environment, you'll probably find that your company has several commercially issued SSL certificates and some self-signed SSL certificates. SSL certificates are used to secure things such as Microsoft Exchange Server's Outlook Web Access (OWA), SharePoint, SSL VPN appliances, and, of course, other websites. The National Institute of Standards and Technology (NIST) has issued a statement that says SSL certificates with a key length of 1,024 bits or fewer will be insufficient for security after December 31, 2010, because NIST estimates that computers will be powerful enough to perform a brute-force crack of keys of that size. For more information about this recommendation, refer to "Recommendation for Key Management." Surprisingly, there are quite a few large companies doing business on the web that still use SSL certificates with 1,024-bit keys.

You might be asking yourself, Should I care? Of course, only you can answer that question. But if you went through the hassle of installing an SSL certificate on a site in the first place, you probably do care about the security of your data on that site. So let's look at how you determine what the key length of your current certificates is and investigate some considerations you might need to address when updating 1,024-bit keys to 2,048-bit keys in your environment.

Determining SSL Key Length

You might be unsure of what key lengths your current keys have. One easy way to determine the key length of any SSL certificate is through Internet Explorer (IE) by following these steps:

In this example, the SSL certificate was issued with a 2,048-bit key, so it complies with the NIST recommendation. In case you were wondering, NIST estimates that an SSL certificate with a 2,048-bit key will be viable until 2030. Of course, you can use this method to check not only your company's SSL certificates but also the SSL certificates of any company that has a secure website (i.e., a website that uses HTTPS). If you or your end users frequently visit secure websites (e.g., a 401k site), you might want to check the certificates for those sites to see if they comply with NIST's recommendations. If you find any that don't, you might consider contacting the companies to see when they plan to upgrade their SSL certificates.

Don't wait to reissue any 1,024-bit SSL certificates you find in your network because you could run into unforeseen problems that will delay the process. SSL certificates with a 1,024-bit key will probably be more common for certificates that were renewed for a period of two years or more. For commercial SSL certificates, some vendors, such as Go Daddy, let you re-key an existing SSL certificate so that you don't have to purchase a new certificate if you just want to increase the key length of the certificate.

Load and Hardware Considerations

If your site has heavy SSL traffic, you might need a hardware upgrade before you increase the key length of the SSL certificate. Changing the key length from 1,024 bits to 2,048 bits places additional CPU load on the server or SSL appliance. In most cases, you'll probably be fine, but if your current hardware is barely keeping up with the existing SSL traffic, you might finally be able to justify the cost of the SSL accelerator appliance that's been shot down in your company's IT budget for the past two years. High CPU utilization on a web server might indicate a high SSL load—or it could possibly indicate something such as an errant script running on the web server. You can use Performance Monitor (perfmon.exe) with the Web Service counter to get an idea of the SSL load on the server.

A quick and dirty way to determine if your Microsoft IIS Server is experiencing high CPU load related specifically to SSL traffic is to download the Web Capacity Analysis Tools (WCAT) available from Microsoft at support.microsoft.com/kb/231282 and technet.microsoft.com/magazine/2008.04.utilityspotlight.aspx. Run the stress tools with secure and nonsecure sites with Performance Monitor active and measure the CPU load on the web server. If the CPU load stays close to 100 percent with HTTPS access and is significantly lower with the equivalent HTTP access, your load problems are probably related to your SSL traffic on the server. You can even run the stress tools with a 1,024-bit versus a 2,048-bit SSL certificate to see how the 2,048-bit SSL certificate will potentially impact a web server's performance.

In addition to the increased load to manage SSL sessions, you might discover that your current hardware doesn't support an SSL certificate with a key length longer than 1,024 bits. This limitation is completely independent of the current SSL traffic load on the device. For instance, one device that won't support a certificate with a key length of 2,048 bits is the SonicWALL SSL-VPN 200. According to SonicWALL, the problem is with the hardware, not the firmware, so there's no upgrade path for this appliance—you must purchase a new appliance that supports certificates that have key lengths of 2,048 bits. For more information about this problem, refer to www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=7354. There are probably other appliances that fall into this category. It's not too early to start reviewing your SSL certificates and hardware so that you have time to budget, make purchases, and upgrade any hardware before the end of the year.

Generating the CSR.

Most SSL vendors have stopped issuing SSL certificates with 1,024-bit keys and now require a certificate signing request (CSR) with a 2,048-bit key or longer. There are some SSL vendors (e.g., Thawte and VeriSign) that will still accept a CSR for a 1,024-bit key, but the 1,024-bit certificates such vendors issue will have an expiration date of December 31, 2010. When renewing your SSL certificates, it doesn't really make sense to generate a CSR with a 1,024-bit key length because the SSL Certificate will be good only until the end of the year. If you need more information about SSL vendors, check out WhichSSL for good comparative information about different SSL vendors, which can help with your evaluation and selection.

If you have an existing SSL certificate on IIS that must be renewed, you typically generate a CSR renewal request and submit it to your SSL vendor. After the vendor validates your domain, the SSL vendor issues the SSL certificate. Different vendors have different processes for performing this validation. Most vendors send a message to the email address listed in the WHOIS field of the domain registration information for quick-issued SSL certificates; enterprise SSL certificates often have a much more stringent validation process. However, if you generate a renewal request for an existing SSL certificate that has a 1,024-bit key in IIS, the renewal CSR will also have a 1,024-bit key. The workaround is to export the existing SSL certificate, then generate a new CSR, which lets you select the key length.

Of course, your site will be down while the CSR is processed by your SSL vendor. For sites such as OWA, being down usually isn't a problem as long as the CSR is generated after business hours. Even for sites with heavy traffic, I still suggest generating a new CSR because I've found that it works reliably. If it's not possible to take down the site for any reason, you might need to configure a mirrored website, generate the new CSR, install the SSL certificate, test it, and then perform a cut over to the mirrored site to reduce the amount of downtime on the site.

For more information about this issue, check out the Microsoft article "How To Renew or Create New Certificate Signing Request While Another Certificate Is Currently Installed." For sites that can't be down for any length of time, it's especially important to be familiar with your SSL vendor's domain and company validation procedures. Make sure you have all the necessary email addresses and other validation mechanisms in place before you generate the CSR so the new SSL certificate can be issued on a timely basis.

Upgrading Root Certificates

Updates for root certificates can be downloaded from Microsoft Support. Of course, you can also download root certificates directly from your SSL vendor. As you know, root certificates are used in the chain of trust to verify that your SSL certificate is valid. Because of this chain, you want to verify that the root certificate from your SSL vendor also has a key length of 2,048 bits or more. To check the key length of a root certificate, complete the following steps:

In the case I checked, the Go Daddy root certificate had a key length of 2,048 bits, so the computer had the upgraded root certificate installed.

Get Ahead of the Curve for Security

It's not too early to start reviewing your SSL certificates to determine how many certificates you need to upgrade to the longer key length. What seems like a relatively simple process can get complicated if you have several SSL sites with heavy traffic that require hardware upgrades in order to be compliant with the NIST recommendations. However, I hope you're ahead of the curve in the process of upgrading your SSL certificates. Happy SSL upgrading!