There is a conceptual work around on wildcard certs, which is to provision on demand essentially, since the process is automated and free.

Issues with this approach, complexity of implementation, throttling (only so many certs per I think week are allowed per ip address)

It's actually worse. The current rate limits are:

> The current rate limits are 20 certificate issuances per domain per 7 days, 5 certificates per unique set of FQDNs per 7 days, 500 registrations per IP per 3 hours, 300 pending authorizations per account per week and 100 subject alternative names per certificate. See https://community.letsencrypt.org/t/rate-limits-for-lets-enc... for more.

Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.

> Which means that you can add at most 20 subdomains a week. Any more than that, and you are SOL.

Though the use cases for needing 21+ new subdomains in a week are few and far between I expect, and probably all cases where a wildcard cert would be a better choice (which LE doesn't yet support).

Note that it is 20 certificates though, not 20 sub-domains, and LE lets you include more then sub-domain per certificate. So if you can group the sub-domains together you can get many more then 20 in the period.

You're right, I glossed over that distinction. My use case is provisioning domain names for servers/containers the moment they come up, and it's not really feasable to batch that.

And if other people have control over the resulting containers in that circumstance a wildcard wouldn't be suitable either, unless it is only used for HTTPS (and the local LAN/VLAN can be trusted) in which case you can put a proxy in front of the containers to handle it to avoid each container needing a copy of the private key.

I can see why limits are in place though, it protects them from abuse by badly written integration code and actions that are less accidental. Perhaps they'll lift the the limits a bit as the service grows and stabilises. Or introduce a cheap-but-not-free service for people requiring something beyond the standard submission rate limits.

Yes, I know, I've followed IETF ACME WG mailing list on the subject, as well as ACME GitHub account issue tracker.

It's being worked on and is probably coming someday, but not here yet. Which makes LE infeasible for some use cases. For now.

OV certificates are literally useless (or, rather, they have zero added value over DV certs) and EV certs are only valuable for the UI that browsers use when they're in use.

> EV certs are only valuable for the UI that browsers use when they're in use

Not exactly, you can pin your CA's EV root cert in your mobile app (or website using HPKP). This allows you to roll your cert at will while presenting a very high bar to an attacker to get a cert that will verify.

Or you pin your own CA root cert and keep the keys off the net.

I feel it's important to point out that no one "needs" an EV certificate.

Of course there is the "increased conversion" argument from which some users find it worthwhile. But groups certain groups have long pushed a myth that certain types of websites "need" EV, which only serves to help their profits.

More than one consultant has argued you won't pass PCI compliance without an EV cert (false).

I feel a lot more comfortable logging on to a bank when they have an EV certificate. So for things like finincial institutions, I think there is a huge value in the extra feeling of trustworthiness.

For a random online store or something I don't care and I think there is almost no value...

Hijacking...

BTW I'm trying to get in touch about ct_advisor but don't see an email listed...

Well it would appear you've identified a valid bug.

This has been fixed, and I've placed my email address on the site.

Thanks. Ideally, I would like to be able to update the email address used. I put the wrong email address in and there's no mechanism for correcting to the desired one.