Google Chrome doing something very weird with StartSSL certs

jonnybarnes commented 9 years ago

It's giving my site and sha{13}.com an orange icon on the padlock.

In both cases Chrome is telling me the intermediate cert is signed with SHA-1.

In both cases Firefox tells me the intermediate cert is signed with SHA-256.

Anyone any ideas?

EDIT: This is on mt Linux desktop, and Chromium works as expected, green padlock and telling me the intermediate cert is signed with SHA-256

konklone commented 9 years ago

I suspect it's this issue, or one like it:

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

Though that particular issue affects only Windows computers, I've seen other cert-chain-selection bugs that end up preferring to draw from a local cache of SHA-1 intermediates than from the certificate presented by the server, thus causing the warning.

I'm going to close the issue here because there's nothing this project can do to simulate the condition, unless I were able to perform the entire process from inside the browser instead of on the server (which I don't think I can do).

In any case, I've been moving away from StartCom and towards SSLMate, which draws from upstream CAs that do not use the same cross-signing approach that StartCom does, and generally recommend it as a high quality certificate provider.

jonnybarnes commented 9 years ago

I’m getting a warning message on SSLLabs regarding the intermediate certificate actually: https://www.ssllabs.com/ssltest/analyze.html?d=jonnybarnes.uk

CRL ERROR: Processing failed: Read timed out [http://www.startssl.com/sfsca.crl]

jonnybarnes commented 9 years ago

Dunno if that has anything to do with it.

konklone commented 9 years ago

That's very strange, but looks like a fluke. I don't get that error for sha{13}. And when I re-run it for your site, the error disappears. Likely evidence of StartCom's CRL endpoint being flakey.

jonnybarnes commented 9 years ago

Right, got very confused about this, digging around I was linking to Mapbox’s JS and CSS. They were using a SHA-1 signed certificate. Serving the relevant files myself got me the green padlock back :)

Seems the CRL error was a red herring.

pierky commented 9 years ago

Just to add my experience about StartSSL SHA1 intermediate CA: http://blog.pierky.com/sha-1-sunset-valid-sha-2-chains-treated-as-insecure/

TL;DR: same intermediate CA with both SHA1 and SHA2, if SHA1 is in the Windows trust store it's the preferred one by Chrome.

konklone commented 9 years ago

@jonnybarnes For the record, now shaaaaaaaaaaaaa.com is getting hit with the same thing, since it's under StartSSL:

screenshot from 2015-04-19 03 24 08

Seems like a good reminder to reissue under SSLMate!

konklone commented 9 years ago

Bing! Done:

screenshot from 2015-04-19 03 30 41

selecadm commented 9 years ago

This issue can be solved server-side by replacing an intermediate.

@konklone, please try to use StartCom again, but with an intermediate provided below, not from StartCom official repository. AFAIR, you were using Class 2 cert, but I will post both 1 and 2.

Class 1

Class 2

konklone commented 9 years ago

@selecadm, I appreciate you helping us out on the thread with the correct intermediate certificates. But this isn't a very scalable way to fix the problem for people -- will StartSSL update its documentation to point to these at a canonical URL? In any case, I've moved on myself, for the time being anyway.

pRiVi commented 9 years ago

@selecadm: WTF, why does this shit work?

selecadm commented 9 years ago

@pRiVi some magic happens to Windows CryptoAPI making it prefer the server chain regardless of cache.

selecadm commented 9 years ago

@konklone, the service should probably give a red warning for sites with StartCom certificates, regardless of the server chain sent.

konklone commented 9 years ago

@selecadm There are a bunch of rough SHA-1 chain construction bugs, and it varies by OS too (Debian has it especially bad. It would be very challenging to simulate all the possibilities, and keep them up to date. It would also need to depend on the use of particular intermediate certificates, not a root CA broadly (even if in StartCom's case they may not have a viable solution for some people).

I don't like SHAAAAA being a less authoritative source than it could be, though I note that even SSL Labs doesn't seem to be simulating client-specific chain construction behavior. I'm open to proposals, but don't have a strong appetite for chasing user-client-specific behavior here.

jonnybarnes commented 9 years ago

Would sending the full certificate chain help prevent clients construct bad chains? Or is it better to save on bytes sent and omitting the root cert?

selecadm commented 9 years ago

@jonnybarnes sending the root is the proposed fix for Network Solutions SHA1 issue, since this CA is so dumb, even the roots trusted by Mozilla and Microsoft are two different roots.

StartCom SHA1 issue can be fixed by sending an intermediate published by me.

After I had successfully abused an unfortunate Chinese CA by obtaining a certificate for already known phishing domain (as per Netcraft), which root is also signed by StartCom as per cross-signing agreement, StartCom mistakenly revoked my certificates used for improving the state of HTTPS. Had to spend $100 on Comodo certs to mitigate this. 7 years ago this CA was abused by StartCom CEO by obtaining a certificate for the domain he didn't even own, but at least Comodo doesn't have SHA1 cache issue. I also got completely banned in the StartCom system (client authentication certificate revoked). Better switch certificates on other domains too.

You have been warned!

pRiVi commented 9 years ago

I still don't know what exaclty fixed my domains... Its your Intermediate, yes, but WHY?

selecadm commented 9 years ago

@pRiVi, the issue is probably a byproduct of creating new intermediates with longer validity (valid until 2022 instead of 2017). This took place in February 2015, sites configured after this are treated as weak/insecure by Chrome, depending on a server certificate notAfter value. Sites configured before February 2015 (those with an intermediate valid until 2017) are fine.

WIndows is a proprietary OS, and its CryptoAPI behaviour is incomprehensible to simple people like me, so no technical details, just stating the fact.

konklone commented 9 years ago

@selecadm I removed your comment, as its tone was unconstructively hostile (even if not to the individuals on this thread) and detracted from your technical comments. Feel free to re-post it with edits or otherwise continue the dialogue here, but please keep it civil and focused on solutions.

selecadm commented 9 years ago

@konklone thanks! You have done this for good actually. I have created a new account in StartCom system and got my previous Class 2 validation and certificates accessible again.

There are still security and trust problems with their current infrastructure and practices, though. Hope to encourage them fixing.

Anyway, will the software for fixing the issue client-side be useful? So that affected sites can provide it to their visitors. I've got a code signing certificate from Thawte, but I think it would be better to register a company with recognized name first. Also am not sure about SHA2 code signing compatibility.

konklone / shaaaaaaaaaaaaa

Google Chrome doing something very weird with StartSSL certs #77