I too haven't read any arguments why that would be the case.
Well yes, I had a problem, but I noticed, that Im not alone.
And I agree, that with stock server or server build from scratches all is just fine, but not with complete solutions.
And you should agree, that verification method could be more flexible or less dependent on specific Apache settings.
http-01 challenge is webserver agnostic. It can be performed by anything that can "speak" HTTP and output some ASCII chars. It might even be a human operator behind a simple TCP socket! No webserver required!
In what way do you understand this validation method to depend on "specific Apache settings"?
Edit: Perhaps it's unclear what this method involves, so just to clarify... When using the HTTP challenge, Let's Encrypt will query
http://$FQDN/.well-known/acme-challenge/foo. In order to successfully complete the challenge, your server must either:
- Respond with the expected validation token, or
- Redirect to some other FQDN-based URL (not an IP address)--using HTTP on port 80 or HTTPS on port 443--that will respond with the expected validation token.
The latter would naturally some specific Apache configuration (assuming you're using Apache as your web server), to do the redirect. But the former is something it does out of the box--literally, with an out-of-the-box installation on Ubuntu, Apache will serve that URL.
If the solution doesn't account for obtaining and renewing required certificates, then it is NOT yet a complete solution.
If the so-called "complete solution" breaks HTTP validation, that's a bug in that "complete solution." Why is this Let's Encrypt's problem, such that Let's Encrypt should change their validation methods (and the relevant RFCs) to accommodate broken package solutions?
I'd like to add that Let's Encrypt has three different validation methods
which were extensively negotiated over time with the industry as a whole. None of them is perfect for every environment, but the point of having three different options is to increase flexibility for different situations and use cases.
Let's Encrypt has also had other methods in the past (HTTPS-01 and TLS-SNI-01) that turned out to have more significant problems with shared hosting users being able to obtain certificates for one another's domain names. These problems were concerning enough that these methods were totally eliminated, even though they could be viewed as the fault of some of the hosting providers' configurations.
Let's Encrypt has been thinking about these options for many years, and is also facing a very strong requirement from the industry (represented mainly by browsers, which see themselves as representing mainly the web end-users' security interests) to make it very unlikely that anyone could get a certificate for anyone else's domain name without permission. That priority is very strong and very strictly enforced—as seen with the removal of HTTPS-01 and TLS-SNI-01 methods even without evidence that they were being abused in the wild—and means that introducing any new methods or changes to the existing methods faces a very high level of scrutiny to show that it is going to be as secure as the existing methods are.
That's not impossible, but it normally should start over on the ACME WG
with a detailed technical proposal that other people can critique. Alternatively, it could start with a discussion in the CA/B Forum
about the extent to which the certificate authority and browser community think that the new method is useful and credible (and then details would still likely be worked out at the ACME working group).
This is a lot of cumbersome bureaucracy to go through in order to merely propose changes, but Let's Encrypt has a huge position of trust which it doesn't want to squander, and domain control validation methods turn out to be one of the most historically sensitive topics.
How do you verify via DNS?
If the application gets absolute control over
.well-known then the application should provide its own method to get a certificate. Or use another challenge.
There are a lot of different applications that work in different ways. There cannot possibly be a solution that works for all of them.
Posts like this make me feel like I've hit the experience and age that make tech people seem ornery when they're trying to be helpful yet stick to facts. While I'm sorry for your troubles, and support your right to disagree with actual facts, that doesn't make your position valid.
The only thing your initial post, and follow up comments, have clearly demonstrated is that you don't have a functional understanding of container systems and how they route traffic. There are only two fixes for that: (i) you can either become educated and experienced in the technology stack you are using, or (ii) switch to another technology stack.
No one would agree that, because as @schoen has noted, the existing verification methods have been developed to ensure security and trust through both the IETF (internet engineering task force, an open standards organization), and CA/B Forum (Certificate Authority/Browser consortium). The goal of Certificate Authorities, like LetsEncrypt, is not to provide the easiest way to issue SSL Certificates, but to provide the easiest way to SECURELY issue TRUSTED SSL Certificates. Because "security" and "trust" are mandates, verification systems need to be wary of multi-tenant servers like @webprofusion, @BenSjoberg, and @MikeMcQ have noted.
As multiple people above have noted, there are many workarounds for complex systems, such as leveraging redirects or segmenting traffic (on certain directories) at the gateway. There is also DNS-01 validation. While these things will help you obtain a certificate, they will not address the underlying issue you encountered, which is leveraging of a container technology that you do not fully understand. There is no need to "PUNCH" a security hole to obtain a certificate from an ACME server, and if you find yourself doing that - you absolutely do not have a well configured system.
I'm sorry for sounding curt and terse in my response, but I honestly can't read your comments as any narrative other than, "I do not fully understand how container systems work, so LetsEncrypt should offer less secure methods of validation instead of me focusing on improving my own education".
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.