1

I recently setup my own CA, and imported the CA cert into devices across the company. I then deployed certificates to our various servers, etc.. All using SHA-1 signatures (the default in the tool I was using: XCA).

Today I discovered the SHA-1 warning in chrome when browsing any of our servers. Oops. Can I just issue SHA-2 certs to our servers and chrome will be happy? Or will any cert in the chain (including the root CA) using SHA-1 cause the warning to appear?

If so, I assume I have to create a new root certificate and distribute that too?

The next question is what's the the best signature algorithm to use? Should I go right up to SHA-512 to avoid encountering a similar problem in the next year? or use SHA-256 for compatibility? (I don't know if some browsers have trouble with the larger hash values).

TSG
  • 159
  • 1
  • 7

2 Answers2

3

With regards to Chrome browser:

  1. Self-signed certificate that is inside your trust store is OK with SHA-1.
  2. Root cert is OK with SHA-1. (This is just repeating point 1 in other words.)
  3. All the other certificates in the chain need to be SHA-2. SHA-1 generates a warning.

The cause for the special treatment of self-signed trusted certificates (aka root certificates) is that they are umm... self-signed, therefore what shows in their "signature" field is rather cryptographical kind of nop, than a real security device. Verifying their signature provides next to zero additional security.

kubanczyk
  • 1,182
  • 6
  • 11
  • You're wrong, see my answer – Alexey Vesnin Mar 02 '16 at 15:12
  • @AlexeyVesnin No, this answer is not wrong. It is in fact correct. – Xander Mar 02 '16 at 15:18
  • @Xander IMHO making an *unneccessery* crypto-set zoo **is** incorrect – Alexey Vesnin Mar 02 '16 at 15:23
  • 1
    @AlexeyVesnin Regardless of your opinion on the matter (which is fine to enumerate in your own answer, I agree) it does not make this answer incorrect, and in fact, this answer is more correct than yours in that it addresses the question of need to issue new roots, which in fact are not required. – Xander Mar 02 '16 at 15:44
  • But would a root CA with SHA-1 still cause the Chrome warnings? If so my internal users are going to be concerned. (We tought them not to proceed if they get a security warning). If only the leaf cert needs SHA-256 then great, no need for a new root CA cert – TSG Mar 02 '16 at 15:59
  • 1
    As stated in answer - Chrome is ok with SHA-1 roots. But beware that Chrome also checks another mechanism: Certificate Transparency (CT). – kubanczyk Mar 02 '16 at 17:04
  • @Telium the Chrome itself can issue no warning, but security add-ons will do, and not in just chrome : try Firefox with Calomel SSL validation – Alexey Vesnin Mar 02 '16 at 17:17
-2
  1. There's no difference in scope of security about a self-signed or brand-signed certificate : you must use a solid bricks to build a durable walls. I'm using SHA-512, and it seems to be fine
  2. There's a good practice to use same security/encryption schemas everywhere, it makes things secure by eliminating a "zoo" of different schemas
  3. All the modern browsers and SSL tools are well-compatible with secure algo's and hashes for years, so it's not just safe, but it's certainly secure to drop any weak compatibilities : only 256+ bit ciphers, no insecure hashes(including md5)
  4. Inspect your software's configs to disable weak SSL and ciphers/hashes, i.e. recompile OpenSSL, OpenSSH, Bind and webservers explicitly disabling faulty pieces
Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • 1
    I'd suggest that point 4 is actually dangerous for most users - it doesn't take much of a mistake to miss out something that should be disabled, or include something that shouldn't be. For 95% of users, sticking with the distro provided binaries is going to be more secure overall, as long as they are updated in the event of flaws being found (e.g. DROWN). Point 1 is very true though - the differences between CA signed and self-signed certs come from the trust levels in browsers, not the encryption levels provided – Matthew Mar 02 '16 at 17:13
  • @Matthew agreed, point 4 is dangerous, but it is more dangerous - IMHO - just use an insecure software that can be exploited. Of course, if they haven't compiled all the software stack - it is a LOAD of work to do. If they did - it usually takes to fix/add some configure options and re-run the script. – Alexey Vesnin Mar 02 '16 at 17:20
  • 1
    @Matthew There is, in fact, a very big difference between self-signed certs and certs signed by a CA. I believe that what's actually being described is the lack of difference between a cert signed by a public CA vs a cert signed by a private CA. – Xander Mar 02 '16 at 17:20
  • @Xander take a good look at [this video](http://www.youtube.com/watch?v=Z7Wl2FW2TcA) - your opinion about CA's will change... – Alexey Vesnin Mar 02 '16 at 17:22
  • @AlexeyVesnin I'm well aware of Moxie's thoughts on the CA trust model. – Xander Mar 02 '16 at 17:23
  • @AlexeyVesnin I've seen more issues in the wild from self-compiled software than from using regularly updated distribution provided binaries, unfortunately. Self-compiling also doesn't help where the software itself is faulty, such as with recent OpenSSL issues. – Matthew Mar 02 '16 at 17:26
  • I don't quite like your suggestion about using SHA-512, as it's really unnecessarily right now and has compatibility issues with crypto APIs in Windows. Also, 256 bit AES with a ephemeral key is also an overkill right now unless your data is so valueable for some 265-bit quantum computer's CPU time (hint they don't exist yet). – billc.cn Mar 02 '16 at 18:17
  • @billc.cn in Windows 7+ I saw no problems with sha-512, can you please tell me more? Aes is well-accelerated by hardware nowadays, so it makes no problems to just utilize it – Alexey Vesnin Mar 02 '16 at 18:22