Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

7 Answers 7

up vote 6 down vote accepted

Try this:

openssl req -in file.csr -noout -text
share|improve this answer
    
Works as advertised, thank you. –  David Mackintosh Jun 30 '09 at 17:06

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.

share|improve this answer

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.

share|improve this answer
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

openssl req -text -noout -in FILENAME.csr

should do the trick.

share|improve this answer

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:

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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