Hacker News Reader

Comment by thinkloop | Hacker News Reader

On the face of it wildcard certs seem easy to implement - just match anything in place of the * - but clearly that's not the case as it took years to complete, anyone mind sharing some of the subtle challenges and complexities involved

View on HN

It didn't take us years to implement. We didn't internally decide to support wildcards until around May 2017 - it wasn't a foregone conclusion that we would ever support them. We didn't start technical work on wildcards until late 2017.

Specifying and implementing ACMEv2 took a while, that was a lot of work. Adding wildcard support on top of that wasn't trivial but it wasn't nearly as much work.

Dynamic DNS providers is one -- I probably shouldn't be able to get a wildcard cert for any of these [1] domains, but permitting *.mysubdomain.hostname.com is probably OK

[1] https://www.dtdns.com/dtsite/faq#hostdomains

Let's Encrypt uses the Public Suffix List (https://publicsuffix.org/) in their issuance process to handle those sorts of cases.

LE requires setting DNS TXT records to get wildcard certs - do dynamic DNS providers ever let you do that? My assumption is they don't.

Yeah that's a fair assumption. So no wildcards for subdomains at dynamic dns providers -- probably not an important use-case anyhow.

Also a large majority of them will be on the public suffix list, which LE uses in their rate limiting checks.

https://en.m.wikipedia.org/wiki/Public_Suffix_List

From the CA's perspective or the subscriber's perspective?

I was wondering from let's encrypt's perspective, it has taken years to develop, and I know there is good reason for that, I just can't put my finger on what exactly those reasons are.

Reply on news.ycombinator.com