Hacker News Reader

Comment by leeoniya | Hacker News Reader

> Symantec will vigorously defend the safe and productive use of the Internet, including minimizing any potential disruption caused by the proposal in Google’s blog post.

What they will vigorously defend is disruption to their reputation and their bottom line. What benefit does a business get from Symantec that they do not get from Let's Encrypt? EV?

View on HN

Well, you can't do wildcard certs, which is fine for most businesses, but for some it's a non-starter. That doesn't make LE bad, of course, it just means it's not the appropriate tool for all use cases.

but certs dont cost anything. you can easily automate the renewal of as many subdomain certs as needed.

If you are a big company and need say 100k wildcard certs (say one per client).. I am pretty sure I can justify spending $50 for a wildcard cert vs a fleet of servers and engineers and monitors to enforce let's encrypt work.

Let's encrypt is great but let's not pretend it's the right solution for all websites.

LE should charge a small fee for wildcard certs and extended validity periods (up to some reasonable limit). They'd likely cover their operating budget very quickly.

What's their stance on wildcard certs with SANs? Is it simply too risky / ripe for abuse?

Absolutely no knowledge here, but my /guess/ has been that they don't do more because it would either require more effort or would have soured the cross-signing deal so that they'd be validated by a CA that's already in older operating systems/devices.

I suspect they will never allow longer validity certs because they want renewal to be automated.

I will a LOT if LE can issue wildcard certificates to me with a 3 year validity. And send me reminder emails when im nearing expiry.

There is some time, scripting, etc, cost to integrating lots of certs into a single instance of Apache, nginx, etc.

Wildcards certs have value in some settings.

Not always possible in all scenarios. For a setup like github.io and github pages it'd be difficult for LE to handle so many domains. Or any scenario where you serve a subdomain up without knowing ahead of time what it'll be (say a tor relay service) it's just not feasible.

What's the turnaround time for LE? Could you possibly deneract an LE certificate on the fly as needed when the request is sent (just block until it's present to be served)?

Not that I would really suggest this, it's a DOS waiting to happen.

Dokku can do it in [two commands](https://github.com/dokku/dokku-letsencrypt#usage):

    dokku config:set --no-restart myapp DOKKU_LETSENCRYPT_EMAIL=mail@example.com
    dokku letsencrypt app

The problem is the volume of certs needed, not the simplicity of LE for the smaller usecase.

There're limits to the amount of subdomain certs you can request, so I imagine this wouldn't work.

https://letsencrypt.org/docs/rate-limits/

> Combined with the above limit, that means you can issue certificates containing up to 2,000 unique subdomains per week.

LetsEncrypt's software is open-source. A commercial CA could use it, remove the limits and add EV if they wanted, then lower their costs to $50 per domain: much lower and much more trustworthy than Symantec...

If your vendor supports those certificates. I am amazed by the amount of software from government contracts or the education field that specify certain certificate vendors. I have two required vendors (government vendor software specified by grant) that require one of three certificate vendors. I am not pleased, but not a real lot I can do.

1. Let's Encrypt has fairly stringent rate limits: https://letsencrypt.org/docs/rate-limits/ You can only get up to 2000 subdomains per week (20 certs * 100 names per cert). If you want to provision a large site, this might be way too small. For instance, my college computer club ran a web hosting service that offered everyone a $username.webhost.example.edu hostname, and there are well more than 2000 active users. So it would be a multi-week process to issue all the certs.

GitHub, for instance, has three million users. Provisioning a cert for each github.io domain would take 29 years. Yes, you can contact LE and ask for a limit increase, but three million certs would still spam the public cert transparency logs, LE's internal records, etc. significantly. That is a cost. LE rounds down the cost of an individual cert, even 20 certs per week, to zero, but the cost of three million certs is very nonzero.

2. Wildcards work in mass-hosting situations where individual certs don't. Again, for my college computer club's server, putting a few thousand <VirtualHost> blocks in Apache's configuration makes it take forever to start. I tried this. It was a bad plan. The better plan is mass-hosting tools like mod_vhost_ldap or even RewriteRules based on the hostname, but they don't let you interact with SNI, because as far as Apache (and thus mod_ssl) see, it's just a single <VirtualHost>.

3. In order to issue a cert, you need to publicly respond for the name on the cert. If you're issuing public-CA certs for private-network websites (which is generally a best practice over running an enterprise CA), you need to briefly configure a DNS entry for the private name to respond to either the DNS challenge or the HTTP challenge. You can't just configure a DNS entry internally. So your internal deployment process now involves updating public DNS. For anyone who's not running publicly-facing infrastructure (i.e., most companies, whose public Internet presence is just a website), there may not even be an automated means of updating public DNS.

A wildcard cert, meanwhile, will just email the owner of the registered domain via e.g. WHOIS contact info, which requires no external configuration, and is a one-time setup process. Everything else is internal at that point.

I love Let's Encrypt, but it's ill-suited to use cases where wildcards are popular.

Why didn't you use the classic webserver.example.edu/~$username ? Your current implementation would be a nightmare to admin in comparison

Isn't the same origin policy per domain? I suppose it's a security benefit that students can't xss each other.

Yes, exactly. At least until suborigin header [0] becomes widely supported.

[0]: https://w3c.github.io/webappsec-suborigins/

We originally did that, but we wanted different origins for each user, same reason GitHub uses username.github.io. Also, we wanted to support a few non-web services (we support svn://username.webhost.example.edu).

Administratively, we use mod_vhost_ldap, and it hasn't been complicated. If anything it's less complicated, because a number of larger websites (departments, courses, etc.) get somename.example.edu CNAMEs from the IT department, and those are virtual hosts too. Back when we were using only webhost.example.edu/~username URLs, the separate virtual hosts were a special case. Now they're just an entry in LDAP with a different DocumentRoot, that's all.

A wider set of devices that accept it.

If you have a service that serves to a fleet of STBs, TVs, or other embedded devices, they have a fixed set of RootCAs and getting the OEM to update those (and possibly through a ton of different resellers) is a nightmare.

While the embedded devices won't be impacted by this announcement (if the deprecation goes ahead), there might be some additional work for anyone that services web browsers AND embedded devices from the same endpoints.

This is a pretty big deal; Symantec controls many root CAs that are pretty old and widely distributed. If you're supporting embedded devices (or phones) with pretty old root stores, you don't have that many choices, and it can be hard to know what they really are, because documentation of root stores is fairly sparse.

Of course, there's not a good way for clients to indicate which root CAs they accept, and so they don't. If you get into the situation where newer devices don't support Symantec certs, and older devices don't support non-Symantec certs, it's time to figure out how to guess if you're talking to a newer or an older device and give appropriate certs. :(

Support.

And as mockable as that might sound, it comes in handy for businesses with special requirements.

Why do i feel like support is one of the reason they issued so many certs they should not have?

Such as the issuance of SHA1 signed certificates long after they've been deprecated? /snark

(Sorry, I couldn't resist.)

EDIT: Apologies, didn't notice the other poster beat me to it.

LE is not scalable. You can't do wildcards, and you don't want to authenticate every subdomain to LE by having it spawn a http server. You don't even want most of your stuff to face the internet to begin with.

I've never hit te rate limit on LE. Seems to me you need to be running a public site that gives each user a subdomain, or similar setup, before you run into such issues.

You don't need a HTTP server to do authentication, it's also possible to use DNS and TLS SNI. There's certainly no need to spawn a server per domain, even for HTTP.

If your implementation is complex enough to require many certs, these problems are already solvable. Either fork over the money for a wildcard cert, or account for the extra work in your planning.

The setup we use is to have our own authoritative nameserver for a 'dyn' subdomain, and do DNS auth. We auth a subdomain with LE in less than 10 seconds.

Reply on news.ycombinator.com