Can anyone help me out in understanding how the HTTP challenge and validation works. I gone through many articles and documentation but somehow I couldn't understand the validation part. I understood DNS validation and it was a straight forward that CA expects the token as txt record in domain. But how is this working in case of http validation?
Let's say I don't own a domain "example.com", but lets assume that port 80 and all firewalls are opened for subdomain "test.example.com". Now if I request SSL certificate for "test.example.com" how does CA/let'sencrypt know that I actually don't own that domain?
The CA will tell your ACME client "put a file with this name and content in .well-known/acme-challenge on the fqdn you want to verify."
That might succeed or not. You do not need to own the domain name to get a certificate, you just need to control the webserver. This way I can use my domain name with github pages, for example.
6 Likes
Let's Encrypt doesn't verify whether you own a particular domain name, it checks whether you control a domain name. I believe this distiction is important, because the latter can be proven using a HTTP challenge, while the former cannot.
When you want to have a certificate for test.example.com, the HTTP-01 challenge requires your ACME client to place a challenge file at the location http://test.example.com/.well-known/acme-challenge/<challenge-token>. The ACME server (Let's Encrypt) then retrieves that file using HTTP. The assumption here is that only someone controlling the webserver (or its content) at test.example.com is able to complete this challenge.
This doesn't say anything about who owns or controls example.com - it may be the same or a different entity, but that doesn't matter for domain validation. The certificate is valid only for test.example.com. It is not valid for the apex domain example.com. Validating the apex domain requires performing the exact same challenge, but for the URL http://example.com/.well-known/acme-challenge/<challenge-token>.
3 Likes
I understood the token part .well-known/acme-challenge. But if this is the case then anyone can request SSL certificate for the domains that they don't own. Isn't this is a security risk. In DNS validation case, I literally need to prove that I own the domain by the txt record, which is not possible for the domains that I dont own.
The public DNS for that subdomain points to a specific IP. Let's Encrypt servers use that IP to make the connection. If you control the webservice for that IP then you control the domain for HTTP Challenge purposes.
The root domain can point to different IP than the subdomains.
4 Likes
Request, yes. Actually get, no.
Only a webserver that's been configured as A/AAAA for the given domain can pass validation. Also, every A/AAAA needs to respond identically.
4 Likes
As others are saying, it isn't about ownership, it's entirely about control.
Really, the only thing a CA does for an end-user, is ensuring that the DNS and IP routing from the CA's locations is going to the same entity as the user's browser checking DNS and going to that IP. It's mitigating the risk that there's a attacker-in-the-middle at the time the user is visiting that isn't there at the time the CA is validating. (And good CAs, like Let's Encrypt, validate from multiple network perspectives to help make it even harder for an attacker-in-the-middle to get a certificate they shouldn't.) A domain owner can restrict things further with CAA parameters and use Certificate Transparency to help detect cases where a certificate was issued that the owner wasn't expecting. But the core of the CA is just helping users get to the same server that the CA saw (or at least a server controlled by the same entity).
There's a lot of confusion out there, with people thinking CAs do a lot more than that, and are somehow "vouching" for a server or owner or something. But it's really just much more core infrastructure, basically just trying to help mitigate the risk of DNS and BGP and such being tampered with from the user's end of things.
5 Likes
So can I say that, though certificate request can go from any server, the certificate still gets issued to the server specified in the SSL request (assuming that subdomain has valid dns entry and port 80 is opened on that server). It is just that the actual owner of that domain/server would get that certificate and I have no access?
No, the certificate goes to whoever asked for it. You need the private key to be able to use it, and Let's Encrypt never touches the private key.
If whoever asked for it cannot successfully validate, no certificate is issued.
5 Likes
Then I guess you didn't understand the token part correctly or not completely at least.
One of the two parts of the token consists of a random string with at least 112 bits of entropy. If you DON'T have access to the webserver of example.com, how would you, as an "attacker", make sure the validation server could download the required token from http://example.com/well-known/acme-challenge/randomtoken? You can't. The request would result in a "HTTP 404 File Not Found" error.
4 Likes
The HTTP-01 challenge works like this:
- You are assigned a unique string to place on a unique file/url of the domain
- LetsEncrypt then tries to retrieve that file/url and ensure the contents are a match
With DNS-01 validation, the authentication pattern is essentially the same - except a DNS record is used.
HTTP-01 is considered acceptable and secure by CA/B Forum (made up of all Certificate Authorities, major Browsers and OS vendors) because Port 80 is considered a privileged / well-known / system port. Being able to place the file on port 80 means a Subscriber is privileged enough to manage the HTTP connection of the machine configured to serve that domain at the IP address the DNS points to – which the CA/B forum and entire industry has agreed is a perfectly suitable mechanism of proving control of the domain name in question.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.