This post was flagged by the community and is temporarily hidden.
1 Like
Please describe your desired validation method and enunciate your current grievances with dns-01.
2 Likes
Hi @IHateYouAll, welcome to the forum!
I'm sorry that getting a wildcard certificate has been difficult. It's a bit unclear to me where exactly you're running into a problem, so more details would be helpful.
Let's Encrypt does offer wildcard certificates. Different clients have different ways of requesting them, and I'm not sure which client you're using, so I can't quite offer help on that front until you provide more information.
But it does seem like you're at least able to request a wildcard certificate, but then unable to complete the domain control validation to get the certificate issued. Wildcard certificates are special, because to issue them we need to be sure not just that you control the base domain, but that you control all possible subdomains as well. Because of this, showing you control a single webserver on the base domain -- which is what the HTTP-01 and TLS-ALPN-01 methods do -- simply isn't sufficient. Using those methods to validate control for issuance of a wildcard certificate is forbidden for all CAs by the Baseline Requirements, and rightly so.
In order to get a wildcard certificate, you're going to need to prove control over the entire domain namespace by showing that you control its DNS. That means using the ACME DNS-01 validation method, and using an ACME client that has the ability to automatically update your DNS records.
If you can provide more information about the client you're using and the environment you're using it in, people here would be happy to help you get DNS-01 validation working correctly.
9 Likes
I'm using the acme.sh client, but I have modified the nsupdate script to match my setting.
I have made a number of cnames to point to my main dynamic dns domain, to make it "simpler", but there must be something that has changed in that client.
I don't get why I just can't post a permanent record in my dns, and as such prove ownership.
The need for real-time checks part are killing me slowly, and is not making any sense.
Anyone could point to such a record as their own proof of owning your domain.
If LE was a domain registrar, then you might see other methods of obtaining certs.
But they are not a domain registrar.
They must abide by the CA/B forum rules.
Plenty of people [much smarter than I] have tried to simplify the ways one can prove ownership and obtain a cert and they have all agreed that the current methods are the ones everyone should follow.
Also, I'm pretty sure no one is forcing you to use LE certs.
There are other free CAs you can choose from.
2 Likes
How can anyone point to a record proving that they own my domain?
I am the only one that can make records in my domain, and pointing to a record should not prove ownership.
The existence of a record should.
The owners of root domains may be able to fake them, but that is a whole new can of worms.
Your logic is flawed.
The existence of the record is the proof.
So... who own's that record? The owner of the domain.
Who proves ownership? Anyone who asks for it; As the proof of it being owned is already there [and not required to be provided by the one asking for a cert].
2 Likes
This is explicitly required by the CA/B forum rules, which govern how Certificate Authorities and Browsers work.
No Trusted Certificate Authority in the world would, or could, comply with your request.
Please reference: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.1.pdf
Note the following sections, which clearly prohibit using "normal" domain validation.
3.2.2.4.19 AgreedāUpon Change to Website ā ACME
This method is NOT suitable for validating Wildcard Domain Names.
3.2.2.4.20 TLS Using ALPN
This method is NOT suitable for validating Wildcard Domain Names.
CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard
certificates or with Authorization Domain Names other than the FQDN.
As to why Authorizations are ephemeral, this is also set by the Baseline Requirements:
3.2.2.4.7 DNS Change
Confirming the Applicantās control over the FQDN by confirming the presence of a Random Value
or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization
Domain Name; or 2) an Authorization Domain Name that is prefixed with a Domain Label that
begins with an underscore character.
If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate
request and SHALL not use the Random Value after
i. 30 days or
ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of
validated information relevant to the Certificate (such as in Section 4.2.1 of these Guidelines
or Section 11.14.3 of the EV Guidelines).
Similar temporal limitations apply to all methods. Request Tokens are centrally defined as:
A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the
time of creation.
A Request Token that includes a timestamp SHALL be treated as invalid if its timestamp is in the
future.
A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT
reāuse it for a subsequent validation.
Again, "Real Time Checks" is something required by ALL Certificate Authorities and cover ALL validation methods. This is not something unique to LetsEncrypt or even the ACME protocol. This is something required by the entire ecosystem of Browsers/Operating System Vendors and Certificate Authorities to ensure general security on the internet.
6 Likes