Your OpenSSL CSR command is out of date | Hacker News Reader

Your OpenSSL CSR command is out of date

certsimple.com

39 pointsnailer24 comments

Correct me if I'm wrong, but -sha256 during CSR creation is meaningless in regards to the Chrome issue as Chrome will never see the hash that was used then creating the CSR.

All Chrome cares about is the signature used by the CA.

Now of course a CA could (and should) complain about sha-1 signed CSR, but this has nothing to do with the Chrome sha-1 deprecation.

Is that correct? I setup a certificate for www.healthlabs.com last week, and we found that we don't get the EV (browser green bar) on Chrome browser in ChromeOS. No other browser is complaining, and I've been scratching my head why. It would make sense if Chrome is complaining about the CA and not us, unfortunately it's not a point that I can argue with customers

my chrome is happy with your domain and is showing a green bar.

SSL Labs agrees with that assessment, though you could enable PFS for a better rank:

https://www.ssllabs.com/ssltest/analyze.html?d=healthlabs.co...

I don't have a Chrome OS to test with, but I'd say this is not your fault. Now of course, going to the customer and saying that a random stranger on the internet told you that it's ok is probably not going to impress anybody :-)

It's correct. The signature on the CSR is not used in the actual certificate.

Your DHE key is 1024 bits. I'm not sure if that's what's causing it, but I would recommend to upgrade it to 2048 bits.

One of the 2 intermediate CA on your cert path is signed with SHA-1:

    VeriSign Class 3 Public Primary Certification Authority - G5

In addition, in my Chrome for Linux browser (Version 41.0.2272.101 (64-bit)), that cert's parent cert is:

    Class 3 Public Primary Certification Authority

And that's a 1024 bit RSA key.

So my chrome's validation path includes a signature by a 1024 bits RSA key using SHA-1 as a trust step. No EV for you. Had the G5 cert been in my trust store (might be on your platform) then all the signatures would have been from 2048-bits RSA keys with SHA-256 and all A-OK.

I think this is because of a bug in older versions of NSS.

So what is -sha256 doing?

It's telling openssl to sign the CSR with sha256, making it much harder for somebody to modify your CSR in transit to the CA.

That's ok, but that's not relevant at all what the resulting certificate is concerned.

Thanks Pilif, you're correct - I've fixed that section and credited you and brians.

Author here. This is a long but, but here's the gist:

- sha256 is required for Chrome 42+ (mid April 2015) not to show warnings.

- 2048 bit RSA is the new OpenSSL default and is required for EV certificates.

- The 'subject' (the thing being attested to by the CA) you actually get in your certificate may have a lot more detail than the subject line in your CSR.

- If you're using EV, and have at least www and non-www, the CN will never be used - your CA will put all the server names inside the SAN fields. Anything else won't work with current browsers.

Trying it out on my Windows machine, it gives me the PowerShell command to create a certificate. Is there some way to specify that I want an OpenSSL command?

Currently it assumes Windows servers for Windows browsers. I'll add an override for switching to Unix shell shortly and let you know here when fixed.

Hi there - just a quick update to say you can now click 'Windows | Unix and Linux' underneath the command to flip between powershell & certreq / bash & openssl

Are there really CAs that copy the hash used for the CSR to the hash used for the cert? If not, the hash used in the CSR has nothing to do with Chrome warnings (as the browser will never see it).

StartSSL at least a while ago picked up the hash algorithm from the CSR.

I'm confused by the blurring of sha-2 on the CSR with the hash function used for the cert. The hash used in the CSR signature has nothing to do with the hash used to sign the certificate. I don't know of any CA that requires a sha-2 CSR to emit a sha-2 cert; does CertSimple?

I agree it would be cryptographically correct, and I bet there's a nasty vulnerability in there that'll be exposed the day SHA-1 is broken---but that day isn't today.

In the '-nodes' section, it mentions not having a password on the private key.

Can someone suggest a "secure, automated mechanism of providing the private key passphrase" as they recommend, if you wanted to use a password on it?

Best practice would be to use an HSM to store the key. It provides the usability benefits of an unencrypted private key with strong guarantees about the security of that key.

It's worth noting that the security benefits of encrypting the private key are limited in most cases. Whenever the server restarts, the private key is decrypted and stored in memory, so an attacker who can exploit your web server would be able to access it anyway. Some attackers might not be able to access memory (e.g. exploits in a web application), but in that case you should be able to use standard file permissions to protect the key.

Encrypting the key would have more benefit if you are planning to store it in places other than the server it is used on, and/or transfer it across a network. In that case, it's probably best to carefully consider your threat model and security requirements, rather than solely relying on the default encryption provided by OpenSSL. For example - do you have the discipline do use a strong, unique passphrase on that key? If not, encrypting the key doesn't provide much protection against a determined attacker. Is stretching performed to slow down a brute force attacker? And so on...

+1. I believe HSMs may even be required for CAs.

For common 'developers making cloud apps' scenario, the best thing you should do is stay passwordless, but use an embedded appliance separate from your server layer. Eg, if you currently do HTTPD all the way to your server, you have n copies of your private key on full Linux instances - you can reduce that substantially by using an HTTPS gateway.

If you switch to, say, a load balancing HTTPS proxy appliance (like Amazon's ELB or Modulus' Go-based load balancer) you store your private key in one place, and that one place has far fewer points of attack than a traditional full OS.

In practice, some CAs do require certain things in the CSR subject even though they create their own subject when they sign. I've seen the country required, for example.

Correct. This all comes down to what the CAs order processing allows. Sometimes they can change things. Sometimes they cant. Somethings they say they cant because its a pain for them to change it.

That's correct - the point of the article was to illustrate that the CA is likely to add things, not that you can omit the basics - hence the minimal example including Country, Location, etc.

Reply on news.ycombinator.com