6

I have a wildcard domain certificate from StartSSL for a site (https://later.webblocks.nl/).

When I check it in any browser on my home PC, it's all good. (Green lock in Chrome.) When I check it in Chrome on my work PC, it's not good:

later.webblocks.nl SSL error on Chrome

The page loads like no problem. There are no other requests, so nothing over HTTP. It uses safe protocols etc. I checked the connection on SSL Labs and Global Sign and they agree it's perfectly safe.

On the same computer, other browsers are fine with it. On other computers, Chrome is fine with it too. I tried restarting, flushing caches, incognito mode, etc. Nothing changes.

It's no real problem for me, because I know it's safe, but it's still annoying.

Any ideas?

PS. Chrome did something like this a while ago with Windows XP: suddenly websites were 'unsafe' because Windows protocols were unsafe. Both PC's are Windows 7 and the same version of Chrome, so that's probably not it...

More info:

For some reason the 2 computers have different certificate chains. The domain certificate and root certificate are the same, but the intermediary is different. On my home PC it uses sha2, on my work PC it uses sha1. The intermediary is included in the server cert (which has sha2), so that's weird. All the SSL checkers only detect the sha2 intermediary cert. What's going on!?

Rudie
  • 335
  • 1
  • 2
  • 13
  • Are you sending all the intermediate certificates to the clients? Or are you relying on the clients having cached the intermediate certificates previously? If you are relying on cached intermediate certificates and if more than one possible path from a trusted CA to your certificate exists, then depending on which certificates clients have cached, they may reach different results. – kasperd Apr 22 '15 at 21:54
  • @kasperd All relevant certificates are included (domain and intermediary). – Rudie Apr 23 '15 at 12:01
  • Look at the certificate details. Which are the certificates in the chain on each of the two machines? Do you see exactly the same chain? What does "Certificate Signature Algorithm" say for each certificate in the chain? It should say something along the lines of "PKCS #1 SHA-384 With RSA Encryption". – kasperd Apr 23 '15 at 12:08
  • 1
    @kasperd Huh!? They have a different chain! On one computer the intermediary crt uses sha1 and on the other sha2. If the intermediary is included, why doesn't it always use that one? How do I control which it uses? – Rudie Apr 23 '15 at 12:11
  • @Rudie I can't answer that question, but you should definitely update the question with that new information. – kasperd Apr 23 '15 at 12:14

3 Answers3

12

The reason is explained on StartCOM's forum:

https://forum.startcom.org/viewtopic.php?f=15&t=15929&p=21716

And on Chrome's:

https://code.google.com/p/chromium/issues/detail?id=473105

It is indeed SHA1.

It's due to Windows' or Chrome's certificate cache. Because they (old and new intermediary cert) have the same name, the client will use the cached variant, which might be old and SHA1. The naming is StartCOM's fault. The bad caching is Windows' or Chrome's fault. They're not working very hard to fix it.

SSL checkers don't have the same problem, because they don't use cached anything.

Different computers have different results, because the cache is local.

The (very specific, local) solution on the StartCom forum works for me: clear cert from local cache, to trigger redownload of new cert, but it's not really a solution for all other users. (In my case only a few, so no problem.)

Rudie
  • 335
  • 1
  • 2
  • 13
4

I believe this might have to do with the deprecation of SHA-1. Early this year, Google made a change on its Chrome 41 browser.Accordingly, 'sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA1-based signature as part of the certificate chain, will be treated as “affirmatively insecure” '. Trusted root certificates using SHA1 are not affected. Clients trust them for identity purposes and not for the strength of their signature algorithm'. This was a direct quote from the above link.

I checked your certificate - it expires after 01/2017 and although the certificate for your domain was signed using SHA-2, the intermediate chain certificate for 'StartCom Class 2 Primary Intermediate Server CA' that you are using uses SHA-1 signature algorithm. The intermediate also expires after 01/2017.

Daniel t.
  • 9,061
  • 1
  • 32
  • 36
  • Sounds reasonable, but https://shaaaaaaaaaaaaa.com/check/webblocks.nl doesn't mention SHA-1. Or does it only check the domain certificate? If I check both certificates (domain and intermediary) with Windows, it says "sha256" for both certificates... _Thumbprint algorithm_ is "sha1" for both. – Rudie Apr 23 '15 at 12:06
  • https://www.ssllabs.com/ssltest/analyze.html?d=webblocks.nl also says "sha256" for _Signature algorithm_. – Rudie Apr 23 '15 at 12:08
  • The 2 computers have a diffrent crt chain. Computer A has a sha1 intermediary and B has sha2. I don't get it... If it's included in the server crt, why doesn't it always use that one? – Rudie Apr 23 '15 at 12:12
  • @Rudie, I wrote a long update to my answer yesterday, somehow it vanished, might it was not approved. The gist of it was to check the certificate store on your Chrome browser. 'Settings-->Show Advanced Settings-->HTTPS/SSL-->--> Intermediate Certification Authorities'. Click on 'StartCom Class 2 Primary Intermediate Server CA' and i expect it to be the SHA-1 signed. You can delete it, and import the one with SHA-2 from the official site. That worked on my end. I am not sure why, but the browser appears to give preference to the intermediate cert on its keystore than the cert from web server. – Daniel t. Apr 24 '15 at 21:18
  • I did that and it worked. I think Chrome doesn't complain anymore though, because another site (and [youtube.com](https://shaaaaaaaaaaaaa.com/check/youtube.com)!) still have sha1 and Chrome is quiet. Weird. – Rudie Apr 24 '15 at 22:25
  • Chrome complains only if the certificate expires after 01/2017 and is SHA-1 signed. youtube.com's certificate expires on 07/06/2015. – Daniel t. Apr 24 '15 at 22:43
  • Interestingly Google's intermediate cert for youtube.com expires on 12/31/2016, just right before the cut off! – Daniel t. Apr 24 '15 at 22:59
0

Sorry, would have added as a comment but not enough rep. See here: https://security.stackexchange.com/questions/52834/what-exactly-does-it-mean-when-chrome-reports-a-certificate-does-not-have-publi

Community
  • 1
DuplicateMe
  • 11
  • According to SSL Labs and Global Sign, the certificate uses SHA-2... The certificate itself says "sha1" for _Thumbprint algorithm_, but so does Twitter's and that's fine. I don't think this is it... – Rudie Apr 22 '15 at 18:21