At one of my new customer sites, I have a SSL certificate which is about to expire. I've been notified by my provider of expiry. The previous admin was pretty detailed and I've located the .CSR which was used to request the about-to-expire certificate.
However, this host is a debian host, and I've confirmed that the .CSR was generated when Debian was suffering from the OpenSSL random number generation issue.
So. Now that I've updated OpenSSL on my debian host, I presume I have to regenerate the .CSR for the renewal. Is there a way to find out what values were used in the .CSR I have, to ensure that the new .CSR is consistant?
Try this:
For future reference, you don't even need the original CSR.
You can create a new request from the existing x509 certificate.
As a general rule nearly all of the OpenSSL commands support the flags correctly answered by others.
Which simply prevent PEM output and display human readable content instead.
If the key was generated on a Debian or Ubuntu server while openssl had a broken random number generator, you must regenerate the key. Do not just generate a new CSR from the old key. You are still vunerable. Once you have a new key, you can create a new CSR with the right values.
openssl req -text -noout -in FILENAME.csr
should do the trick.
I completely agree with David Pashley (but i have something to add...).
The keys itself are vulnerable not the csr! There is no point in regenerating the csr you have to regenerate you keys!
Most CA will not even accept signing requests associated with these "compromised" keys.
And here are some useful links:
Depending on EXACTLY what you're trying to do here but if we're talking a regular SSL certificate used with web servers sometimes the simple solution is to just pull up the site (https://www.mywebsite.com) and look at the properties of the certificate there.
Right click the "lock" in the browser while its in HTTPS/SSL mode and you should be able to see pretty much all the values entered.
Hope this helps.
You can also probably work out what info was put into the original CSR by examining the current cert:
openssl x509 -in <certfile> -text -noout