3

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?

6

Try this:

openssl req -in file.csr -noout -text
3

For future reference, you don't even need the original CSR.

You can create a new request from the existing x509 certificate.

openssl x509 -x509toreq -in file.crt -signkey file.key -out file.csr

As a general rule nearly all of the OpenSSL commands support the flags correctly answered by others.

-noout -text

Which simply prevent PEM output and display human readable content instead.

3

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.

  • 1
    I think he just wants reminded of what values he put in the CSR. God knows I can never remember what I put in the last time I requested a certificate. It's possible to be completely accurate each time, and still be completely different. – Matt Simmons Jun 24 '09 at 12:05
  • Other answers have answered that. The question sounded like he was going to use the old key, which would have still left him vunerable. – David Pashley Jun 24 '09 at 12:48
  • Good to know. I didn't know the key was vulnerable. – David Mackintosh Jun 24 '09 at 15:35
1

openssl req -text -noout -in FILENAME.csr

should do the trick.

1

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:

0

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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.