Hacker News Reader

Comment by eropple | Hacker News Reader

And that is a without-exception good thing. Wildcard certificates are dangerous and encourage bad practices around SSL. You shouldn't use them. Instead, you should fix your workflow to know exactly what domains you have and have active and use automated tooling to provision them correctly.

View on HN

I don't think so.

I have an industrial VPN with ~300 embedded devices behind them. For some reason the user wants to access to each one of it via https.

I thus set up an Apache proxy which proxies https://device_n.vpn.cust.tld to the VPN device (and some auth)

LE cant issue 300 certificates and it would be very ugly.

I don't believe LE has an upper limit on its number of SANs.

For systems not explicitly public, whitelists are almost always better than blacklists.

> I don't believe LE has an upper limit on its number of SANs.

The limit is 100, unless they removed that when I wasn't looking. Back in the beta I tried one domain, a handful and then, because I couldn't find a technical reason why SAN should be limited, I tried 500. It fails. I have many certs with up to 100 and would be happy if this changed.

The highest I've seen in the wild is 60 or so, so I'll bow to your superior getting-bitten-in-the-ass-by-it. =)

(And if so, in the prior commenter's situation--okay, create three certs. LE might not support 300 certs, but 3 with 100 SANs should work just fine.)

Currently security sandboxing happens basically per Origin. Since schema and port is fix, and I don't want to force every user/potential-user/demo-user/anon to register a domain (so the LE rate limit doesn't apply, and nobody want's bloated 100 SAN certs).

I know the names, but rerolling a cert takes time, takes up resources, etc.

Reply on news.ycombinator.com