

Your OpenSSL CSR command is out of date - nailer
https://certsimple.com/blog/openssl-csr-command

======
pilif
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.

~~~
arenaninja
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

~~~
acveilleux
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.

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

------
nailer
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.

~~~
discreditable
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?

~~~
nailer
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

------
brians
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.

------
zdw
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?

~~~
garrettr_
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...

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

------
ryan-c
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.

~~~
nailer
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.

