Once again we’re in SSL territory but I don’t want to give the impression that I devote much of my time to thinking about SSLs or that it relates to a large part of what I do for a living.  I’m just responding to the analytics and trying to deliver to that large audience what they search most often for.

So, you purchased an SSL last year for your site, www.acemwidgets.something, and you just received a notification that your SSL certificate is going to expire in 90 days.  What’s going on?

Well, first and foremost, you should know that if you have 90 days left on your certificate before expiration and you purchase an additional 365 days you do not lose your 90 days.  Those 90 days get added to the 365 days you just bought.  I generally renew at the 90 or 60 day mark, depending on what the customer wants and always at the 90 day mark for infrastructure SSLs which would include mail, crm, etc.

You should also know that the .csr, which the certificate authority (CA) uses to generate your certificate file (.crt), can sometimes be resubmitted directly to the CA.  For your standard apache/openSSL implementation you can just go to the directory that houses your .csr and paste the contents directly into the certificate request form of your registrar.  This is a time saver and I haven’t seen this exploited in any way but I think it is in your best interest to generate a new .csr every time.  Be aware that for IIS (Microsoft Windows) and tomcat, which is a java implementation that works with apache (though it was intended to be a helper process not a server, itself), require that each time you request a certificate renewal you also generate a new .csr.

Allow me to reiterate that you should generate a new csr every time you renew.

This really begs the question “why wouldn’t you just create a new .csr everytime and cater to the avenue of greatest compatibility?” – you can certainly generate a new .csr every time from your .key file and submit that to the CA for your .crt, but you will inevitably find yourself in a position where the “standard” procedure is to do something decidedly non-standard so I encourage you to be aware of when it’s safe to do this and when it’s not.

Assuming you’ve never done this before and have an apache/openSSL implementation, you can create your key using the command:

openssl genrsa -out www.site.com.key 1024

the syntax goes:

openssl genrsa -out filename bits

if you intend to use a 512 bit value, which I do not recommend, you don’t need to specify it in the command because 512 is the default.  I recommend a minimum of 1024 bits as well.  You can see the modulus string by using the command:

openssl rsa -noout -modulus -in www.site.com.key | openssl md5

this command will spit it out string which, will be useful in verifying that the .csr and .crt your CA returns to you are valid and compatible.

Now that you have your .key you can create a certificate signing request, or csr, using the command:

openssl req -new -key www.site.com.key -out www.site.com.csr

you can use the following command to view the modulus string:

openssl req -noout -modulus -in www.site.com.csr | openssl md5

the string returned should be identical to the string returned when you viewed the modulus data from the .key file.

When you need to renew an existing SSL certificate you can, if the criteria fit, simply resubmit the content of your existing .csr to your CA, or you can use the command above to generate a new .csr to submit.  Either way you will shortly receive a confirmation via email indicating your .crt file contents and you should verify that using:

openssl x509 -noout -modulus -in www.site.com.crt | openssl md5

if all the strings match for .key, .csr, and .crt then you can be certain that they are all correct.