Sorry, I stated the wrong one. I was thinking about RFC 6125, section 6.4.3. Since it’s only “wildcarding” one segment, I think that limits the certificate to *.domain.foo or *.svr.domain.foo. Unless they can both be bundled into one certificate using SAN entries. I’ve added specific SAN entries to a base wildcard certificate, but never attempted wildcard SAN entries in a wildcard certificate.
Ah, I see what you’re saying now. Yes, wildcards only match one subdomain deep.
This works fine, see https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/#certificates.
Would it be possible to update that post to link to one of the versions of the specs? I did read that post first and I still found it difficult to reliably convince myself that the link I provided or the one you mentioned actually were the same thing as “ACME v2”.
Sounds good, thanks for the suggestion.
Why is HTTP validation not to be allowed for wildcard?
The way I’ve seen wildcard validated via HTTP is to demonstrate control over the base domain. Is there a reason why that doesn’t suffice for LE’s wildcard? It’s much more reliable for shared hosting setups where DNS might or might not be hosted locally.
HTTP validation establishes control of a host, while DNS validation, broadly speaking, establishes control of DNS. It’s possible somebody legitimately controls the webserver on
example.com, but doesn’t control
mail.example.com. That person would be able to pass HTTP validation, but not DNS validation.
HTTP validation for wildcard certificates
HTTP-based verification for wildcards
Wildcard certificates via http-01
It could work if both DNS and HTTP server were configured to respond to an arbitrary subdomain request, of course. Alternatively, since ACME/2 can create the authz in response to a cert order, could it not work thus:
authz asks to verify
Certificate requestor then demonstrates control of the zone by responding to an HTTP request to that subdomain.
This would still be error-prone for shared hosting environments, but at least there would potentially only be a single DNS zone change needed (i.e., to add a wildcard to the zone that points to the HTTP server).
Yep, something like that approach (with multiple random subdomains) was discussed as an option, and as we said in the blog post, we may consider it again in the future, but for now we’re planning to stick with the simple option of just DNS.
What is the relative usage of DCV patterns that LE sees now? i.e., how many HTTP, how many DNS, how many TLS/SNI?
In our setup we use two domains in one app, and need a wildcard for both.
Is support for
*.domainB.com in the same certificate on the roadmap?
Will the staging server be updated so people can test wildcard certificates and the validation required?
My questions are:
if there are new limits per account, per domain etc. in mind for the wildcard support.
Is it possible to use up to 100 // 50 domains (both * and root)?
Do you embed SCT into those certificates? The issue on github is still open and with the new v2 api is this now possible.
I think they do it as always. The boulder team develops the v2 api endpoint and everyone test’s it against the staging servers. But this is mainly to validate the implementation, find bugs, check if they are conform to the RFC’s, etc. pp.
Also it takes time for the client developers to update there software to match the new shiny v2 api endpoint. There are so many new things in it
Presently, one can monitor Certificate Transparency (CT) logs and watch for newly-logged (implying newly-issued) certs and examine them to see if they are of interest. E.g., one might check for the existence of a given substring (eg a brand name) in the subject field or SAN dnsNames. And then one is able to check to see if the site is up, and if so examine it more fully and assess “content intent and safety” – e.g., in order to detect “rogue” sites (phishing, malware, etc).
How might one accomplish the above in the case of wildcard certs? Examining https://tools.ietf.org/html/rfc6962 and https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis indicates that the hostname from which a TLS client received a given cert is not logged in the CT logs, and TLS clients are not encouraged to log the certs they encounter.
So how might one track down registered subdomains of a “base domain” in a wildcard cert? E.g., given a cert for “*.example.com”, how might one determine the publicly-accessible-presently-registered-and-delegated subdomains of “example.com”?
There is no mechanism for this in CT, or really anywhere else, unless you’re thinking of internet-wide scans which might stumble across a web servers serving that particular subdomain (i.e. stuff like Censys or Shodan).
CT was mostly designed as a way for domain owners to detect certificate misissuance or compromise of infrastructure that allows unauthorized issuance. The ability to search for other terms is a nice side-effect and still works for the DNS labels after the wildcard symbol, but there’s no way to do that for the label covered by the wildcard.
Will the wildcard cert cover:
*.*.*.domain.tld (where wildcard portion can also contain periods)
*.domain.tld (where wildcard portion can NOT contain any periods)
I don’t believe that the first form is an option in the X.509 system today.
Still a great step forward - for Internet encryption.
But it will have it’s own new challenges [literally].
That’s awesome news!
One question: when do you expect a staging endpoint for ACMEv2 with wildcard support to be up so that we can start integrating with the new features?
yes, that is one approach.