Also, a backup domain should be created and hosted on a different registrar and pointing to diferent servers as a failover service, so if the client fails to reach the .org domain it should try with the backup one.
client* flags are generally a registrar issue rather than a registry issue.
If the clientHold flag was added by the registry itself without prior notice, the issue is bit more disturbing...
Anyway, I agree with the OP that let's encrypt should have 2 domains managed by 2 different registrars. And these domains should be on 2 different TLDs managed by 2 diffrerent registries.
And these domains should be locked at registry level (server* flags).
I’m not sure a fallback domain is worth the extra effort and expense to protect against such a rare circumstance. If the outage was due to a registrar error, it might have helped, but if the outage was due to e.g. a malicious abuse report to ICANN, both domains could have easily been affected at the same time and it would have been a total waste of effort.
An outage of several hours shouldn’t affect anyone using Let’s Encrypt properly, anyway.
The points about registrar locks and other measures to increase the security of the existing domain are definitely valid (though I find it unlikely that CloudFlare is the only registrar that provides such features) and I’m certain the Let’s Encrypt staff already started considering implementing them before you even raised the thread.
An outage of several hours shouldn’t affect anyone using Let’s Encrypt properly, anyway.
It does affect OCSP (if you're not stapling, at least, or if your staple cache is only updated too close to expiry). But a backup domain won't help for that either. (Or can a certificate can contain several different OCSP URIs?)
In fairness, it also affects new issuance, which may be problematic for large integrators in particular. That being said, I don't believe a backup domain, and all that entails, are worth the effort, to be honest.
It will definitely affect all current users and certificate holders... (It won't affect chrome users though... Since chrome doesn't actively check OCSP...)
Imagining if Comodo or other CA has the same issue.....
OCSP is fail-open precisely for this reason. And there's hardly anything that fails faster than a domain not existing, so this was the best possible kind of outage to ask for from an OCSP POV.
I think you can repeat AIA fields but browsers probably won't bother checking more than one.
Dear Customer,
We're sorry, but due to delays at Let's Encrypt, SSL certificate issuance for our customers and many others around the globe has been delayed. Your site was made available with a self-signed certificate so you can test it, but your browser will display security warnings. Also note that your site may not be accessible at all yet due to DNS propagation delays, which could take up to a day.
We will notify you when a certificate is issued and you can access your website without any security warnings. We're sorry for any inconvenience this delay has caused. Have a nice day!
If you had a deadline yesterday you should have made sure it worked three days ago. If it's not important enough to plan ahead or give GoDaddy or Comodo $10 for you can spend that money on a beer instead and wait a few hours... It's not like S3 is down and all your files are gone, you have plenty of other options for certificates or you can just chill.
They go down too, they just get bought out and change status pages all the time so you can't see the history:
Not if you are using the Must Staple flag in your cert (which you SHOULD use).
A failsafe is not a good idea. If an attacker can MITM you with a compromised certificate, they can block OCSP queries to prevent the revocation to works.
The ICANN don't have any direct control over registeries. And if a registry receive instructions for shutting down a well-known domain, be sure they will-double check that (with ICANN or the authority who emitted this instruction) before effectively disabling that domain.
Let's Encrypt's OCSP responses are valid for 6-7 days from the moment you request them. OCSP stapling implementations will cache the old response while a new one is unavailable, if they even bothered retrieving one at all during the outage window.
I think I had the ICANN UDRP in mind when I wrote that, even though that really can't be involved here. Nonetheless, there are many ways to get your domain shut down that there is little to nothing the people you pay for your domain can do about: https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.pdf
Until we have more information I cannot assume it's all their registrar's fault, sorry. It's a complicated Internet we're all connected to.
Only good ones -- AFAIK most web servers don't do the caching by default (or do stapling very well/correctly) -- I know Caddy does but that's the only server I can speak of. Caddy can survive OCSP responder outages for about 3-4 days because of its cached stapling implementation.
Yes, we all agree. This is why a robust server-side implementation of stapling is important. See this GitHub Gist and its comments: ocsp-stapling.md · GitHub
.
This is why a robust server-side implementation of stapling is important. See this GitHub Gist and its comments: