Nothing related to the article or your response but I wanted to take a moment to say that as someone who is just getting started with learning Linux administration Certbot and Let's Encrypt made it stunningly easy to get SSL enabled for my site, your work and dedication is immensely appreciated!
Thanks a lot, and keep up your fantastic work!
Interestingly, many CAs are charging lot for certs. And lot of them don't know how to validate user's info. Many business guys just burn cash on certs told by CA's support team for 'security'.
Other than that, it seems like this documentation mainly exists within client documentation, like
https://certbot.eff.org/docs/challenges.html
for Certbot. When people have more specific questions about validation, they normally bring them up on the forum.
It could be as simple as adding something explicit to the how-it-works page:
Let's Encrypt currently supports the following ACME mechanisms to validate your domain:
- HTTP-01: the Let's Encrypt client receives a challenge from Let's Encrypt and serves its response to the challenge at /.well-known/whatever on HTTP port 80 on each of the domains to be listed on the certificate. Let's Encrypt will load that URL to validate the request. This mechanism does not support wildcard certificates.
- TLS-ALPN-01: etc.
Something like this would have saved me about 45 minutes of fiddling around trying to figure out what I needed to do. I can't be the only person whose setup is more complicated than just a simple web server instance that I can blindly run certbot on. I had to make changes to my network, and I needed to know what changes to make.
https://stackoverflow.com/questions/1612177/are-http-cookies...
I just tested this and I was able to confirm your suggestion with Firefox, watching with a packet sniffer while connecting to my own site with http://example.com:443/ after previously setting a cookie over https://example.com/. The cookie was clearly visible in the packet log.
So this is what that email was about.
I can't find the relevant discussion thread at the moment, but I believe this was because the default configuration in some shared hosting environments would have allowed users to receive certificates to others' websites.
Edit: https://mailarchive.ietf.org/arch/msg/acme/B9vhPSMm9tcNoPrTE...
[edit] This also means I should probably make a PR for automating DNS-01 with my DNS provider (he.net).
However, plugins need not live in the main Certbot repository. Maintaining a plugin yourself may be the lowest-friction way to build one right now (or may have its own challenges; I haven't tried that approach).
Lexicon supports he.net[1] and Certbot provides a class for building Lexicon-based providers[2] with very little effort (although perhaps more effort and duplication than would be ideal[3][4]).
0: https://github.com/certbot/certbot/issues/6504
1: https://github.com/AnalogJ/lexicon/blob/master/lexicon/provi...
2: https://github.com/certbot/certbot/blob/master/certbot/plugi...
TLS-SNI-01 is one of several validation methods for getting a Let's Encrypt certificate. It was originally the only method that worked on port 443 (other methods use port 80 or ask you to create DNS records).
In January 2018, Frans Rosén (the author of the article linked here) discovered that, on some shared hosting environments, one shared hosting customer could pass TLS-SNI-01 challenges for a different customer's domain. This problem only affects users of particular shared hosting services, but there was no apparent way that Let's Encrypt could get every shared hosting provider to fix this. (Let's Encrypt already knew about a related problem in a proposed-but-never-implemented validation method called HTTPS-01, but had missed the issue that Rosén discovered.)
Let's Encrypt then temporarily disabled TLS-SNI-01 entirely, and later allowed it for certificate renewals but not for initial issuance, as well as for specific hosting providers that had specifically confirmed that they were not affected by the vulnerability.
At the same time, the eventual deprecation of TLS-SNI-01 was announced.
In preparation for the deprecation, the Certbot client improved its support for HTTP-01 (the challenge that uses port 80), and, in recent releases, switched to preferring HTTP-01 over TLS-SNI-01 even if the certificate authority offers both. (Certbot originally preferred TLS-SNI-01 over HTTP-01.) This change means that recent renewals for people who have moderately up-to-date versions of Certbot will default to HTTP-01 and simulate what will happen after TLS-SNI-01 isn't available at all.
Recently, Let's Encrypt has also been e-mailing people who performed recent renewals using TLS-SNI-01 and warning them that this option is going to be eliminated permanently in March.
There is a newer validation method that works on port 443 called TLS-ALPN-01; this is supported by Let's Encrypt but not in Certbot. Some other clients do support it, although they may require that you shut down your web server temporarily.
https://community.letsencrypt.org/t/which-client-support-tls...
Some people have been frustrated by this change because they have blocked port 80 entirely. Let's Encrypt has published a document noting that this isn't a good idea; in particular, it doesn't protect against active SSL stripping attacks.
https://letsencrypt.org/docs/allow-port-80/