Dear Valued GlobalSign Customer,
As most of you are aware, we are experiencing an internal process issue (details below) that is impacting your business. While we have identified the root-cause, we deeply apologize for the problems this is causing you and wanted to ensure you that we are actively resolving the issue.
GlobalSign manages several root certificates and for compatibility and browser ubiquity reasons provides several cross-certificates between those roots to maximize the effectiveness across a variety of platforms. As part of a planned exercise to remove some of those links, a cross-certificate linking two roots together was revoked. CRL responses had been operational for 1 week, however an unexpected consequence of providing OCSP responses became apparent this morning, in that some browsers incorrectly inferred that the cross-signed root had revoked intermediates, which was not the case.
GlobalSign has since removed the cross-certificate from the OCSP database and cleared all caches. However, the global nature of CDNs and effectiveness of caching continued to push some of those responses out as far as end users. End users cannot always easily clear their caches, either through lack of knowledge or lack of permission. New users (visitors) are not affected as they will now receive good responses.
The problem will correct itself in 4 days as the cached responses expire, which we know is not ideal. However, in the meantime, GlobalSign will be providing an alternative issuing CA for customers to use instead, issued by a different root which was not affected by the cross that was revoked, but offering the same ubiquity and does not require to reissue the certificate itself.
We are currently working on the detailed instructions to help you resolve the issue and will communicate those instruction to you shortly.
Thank you for your patience.
Lila Kee Chief Product Officer GMO GlobalSign
US +1 603-570-7060 | UK +44 1622 766 766 | EU +32 16 89 1900 www.globalsign.com/en
Safari on the other hand silently failed the https auth and served the page regardless. Concerning behavior for a revoked cert.
sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 'DELETE FROM ocsp WHERE hex(serialNum) IN ("040000000001444EF03E20", "040000000001444EF04247");'
sudo rm /var/db/crls/*cache.db
but if it works.
Ouch that sucks.
Let's Encrypt is one way, although the lifetime with 3 months is a bit too long. One month or even less would be better. Additional verification and checks via DANE/DNSSEC help to shorten the impact of a compromised key. Constant checking for revocations do not. Again: IMHO.
I wonder if Let's Encrypt is thinking ahead to a federated future where instead of issuing leaf certs, they also issue intermediate certs to domain owners, who can use those to mint very short-term leaf certificates (like 1-4h) in an automated fashion.
Right now there's barely support for limiting a root CA to a single TLD...
Sadly, lots of phones and computers have incorrect time settings, off by one hour to work around incorrect DST settings is pretty common, off by several days isn't super rare either.
I have run into some SSL client libraries that check notBefore against the current time, in the current timezone, and therefore those in the western hemisphere would fail to work for several hours after a certificate was issued. I imagine they're using the same for notAfter, so those in the eastern hemisphere would stop working early.
My rule of thumb is a certificate that is less than 30 days old or has less than 30 days of validity left is going to cause problems for a subset of your users, and shouldn't be used unless you have a good reason (old certificate compromised would be a good reason).
Before this, the Technical Solutions Director tweeted solutions that did not work for end users, but highlighted a typical IT centric approach to problem resolution ("Works, What's the problem?") [1]
For anyone not already aware, check out Let's Encrypt. I am evaluating it for about 200 domains now in earnest after having it on my horizon for some time. At least to have it ready as a fallback. [2]
Getting 200 EV certificates in a hurry from a different CA has been costly this morning.
[1] - https://twitter.com/vanbroup/status/786548172864626690 [2] - https://letsencrypt.org/
We're 18 months old and the main reason we exist is to make the identity verification EV adds not a pain in the arse.
Here's a list of ways we do EV differently from other providers: https://certsimple.com/about
I've been on HN for nearly as long as pg has so feel free to give me a shout here if you have any questions. It's past midnight in the UK right now so I'll answer them tomorrow morning. If you prefer email: mike@certsimple.
Landscape seems to work fine though.
EV certificates do not add additional security as far as I am aware, it's simply a measure of extended validation of the customer, which in my experience is only fluff.
So going with Let's Encrypt may as well do the full cycle and sell this free solution to non-technical people who believe EV provides additional value.
Hard sell... I know.
Correct.
> ...which in my experience is only fluff.
Depends on what you want to accomplish. If you just care about getting to SOME website with a secure connection than a DV certificate is all you need.
But take my employer: Capital One. We're a bank. When people go to https://www.capitalone.com it is important that they get our website. ALSO, though, it is important that when people go to https://www.capitalοne.com that they do NOT get some malicious website. (Can't see the difference? What glyph did I use for the letter "o"?) This is just one example of how an EV certificates can be useful for certain purposes, although it may not apply to your business.
"3.3 Intentional or accidental errors This Warranty Policy warrants against intentional or accidental errors introduced into a Certificate by any personnel of a GlobalSign RA or a GlobalSign LRA due to failure to use reasonable care as required under the CPS."
Not a lawyer, but will push this with our legal team for sure.
This could destroy GlobalSign, so there must be a clause to exempt them from liability ... ah, here it is:
"8.1 Total amount for warranty exhausted When the maximum limit allocated for warranty payments is exhausted, GlobalSign shall have no further obligation to refund any Beneficiary, unless required otherwise by applicable law."
They didn't introduce any errors _into_ a certificate. They affected the certificate chain, but not the certificate directly. I'm certain this is how their own lawyers view this.
I'm gonna go out on a limb and guess they allocated $0.
So it's not their failure but browsers'? Which ones then and what versions?
chrome --ignore-certificate-errors
I must say though, I'm increasingly frustrated by software vendors trying to strip away control over our own machines. There is no option at all from the standard error message, even under advanced, to indicate that you know about this problem and wish to proceed. And I'm sure it's only a matter of time before they remove this command-line option as well.
I get that novices probably need some protection, but I really wish there were a way to say that, "yes, I really do know what I'm doing, please stop treating me like a toddler." So instead, I'm forced to use a much less safe, hidden command-line option or be locked out of various sites for four whole days.
I get the sentiment, but if you look at how common malware is on Windows versus (walled-garden) platforms like iOS, it becomes pretty clear that it's the most effective way to keep users safe. Inconveniencing tech-savvy folk is a small price to pay for that, IMO.
> I get that novices probably need some protection, but I really wish there were a way to say that, "yes, I really do know what I'm doing, please stop treating me like a toddler."
Typing "badidea" when faced with the interstitial should do the trick.
This command-line switch works, but it requires accepting a larger risk with respect to secure cookies and MitM attacks.
https://groups.google.com/forum/#!topic/mozilla.dev.security...
https://cabforum.org/pipermail/public/2016-January/006519.ht...
https://groups.google.com/d/msg/mozilla.dev.security.policy/...
https://security.googleblog.com/2015/12/proactive-measures-i...
https://sslmate.com/blog/post/ct_redaction_in_chrome_53
https://www.agwa.name/blog/post/domain_validation_vulnerabil...
And all of this is just from the last year.
Symantec is one of the worst CAs there is. Avoid them like the plague.
This is a real mess.
anyone else use globalsign via google load balancer who can confirm?
FYI the google load balancer issue seems to be real, but not related.
Man, do they suck at communication. We're now 14 hours into the incident. 6-7 hours ago they posted a trouble shooting guid, promising new intermediate certificates for AlphaSSL and I've just been informed by their support that it'll be another hour before they're ready.
It's now 02:00 in dk, so I can expect the new certs at 3 and be done by 4.
Fun night.
Thanks GlobalSign.
P.S. Also thanks to the guy who made their marketing department stop tweeting iot crap while this is going on. That pissed me off.
Today's weirdness and communication around it has made me trust Globalsign a lot less now.
They are in the process of fixing certificates. I know of many that are now ok. Too bad I already bought new ones, won't be going back,.
So, I guess, thank you Global Sign for forcing me to finally make the switch!
What do you mean, X.509 doesn't support that? :P