Well, the certificates are generated on the server, which is a Linux machine. I’m using the certbot tool to generate the certificates, which admittedly isn’t an ideal choice considering it’s a web app, but it’s the first thing I found, it was easy to get started with, and I didn’t have a whole lot of time to write something that talked to the ACME API directly. That’s for a future update :)
With an automated, zero-cost CA, there are very few legitimate cases for wildcard certificates, and the risks increase with their use.
I don’t understand why LE couldn’t simply allow for higher thresholds on certificate issuance, and instead support certificates that are actually a worthwhile goal: free S/MIME that doesn’t involve suckling at the Comodo teat.
The biggest use case for wildcard certs is SaaS. If I have 10,000 SaaS customers with hosted domains like customer.example.com, LE wouldn’t want to issue (and renew!) that many certs. It also may exceed their rate limiter.
LE creates SAN certificates, which let you group together multiple domains under one certificate. So you can use LE for a SaaS product like this if you’re clever about automatically grouping domains together. See: https://letsencrypt.org/docs/rate-limits/
I know that LE can support up to 100 domains in the same certificate with SAN certificates. But I feel like the complexity implied by grouping domains together is not worth the few hundred bucks of a wildcard certificate.
I agree. If you can prove you own the domain, shouldn’t you be able to call your domain whatever you want and get a certificate for it?
So the real risk, it seems to me, is in the way you show that proof. If the CA asks for this proof in a way that’s not secure, that to me would be a problem.
I like supporting wildcards but I do wish they’d dramatically increase the rate limits and decrease the suspension time. Getting banned for a week after a fuckup or bug is nuts.
This is great to hear! I’ve been using Let’s Encrypt for a client’s site and it’s been awesome to use.
Which OS and client?
Well, the certificates are generated on the server, which is a Linux machine. I’m using the
certbottool to generate the certificates, which admittedly isn’t an ideal choice considering it’s a web app, but it’s the first thing I found, it was easy to get started with, and I didn’t have a whole lot of time to write something that talked to the ACME API directly. That’s for a future update :)This is disappointing.
With an automated, zero-cost CA, there are very few legitimate cases for wildcard certificates, and the risks increase with their use.
I don’t understand why LE couldn’t simply allow for higher thresholds on certificate issuance, and instead support certificates that are actually a worthwhile goal: free S/MIME that doesn’t involve suckling at the Comodo teat.
The biggest use case for wildcard certs is SaaS. If I have 10,000 SaaS customers with hosted domains like customer.example.com, LE wouldn’t want to issue (and renew!) that many certs. It also may exceed their rate limiter.
Yes, this is exactly why I can’t use LE for my business right now.
LE creates SAN certificates, which let you group together multiple domains under one certificate. So you can use LE for a SaaS product like this if you’re clever about automatically grouping domains together. See: https://letsencrypt.org/docs/rate-limits/
I know that LE can support up to 100 domains in the same certificate with SAN certificates. But I feel like the complexity implied by grouping domains together is not worth the few hundred bucks of a wildcard certificate.
I’ve not known many companies that want to publish their full customer list so publicly :)
What are the risks for wildcard certificates?
I do like the option when it’s there. For example when SNI is not available and you are running low on IPs.
The main concern is phishing.
If you look at your URL bar and see a green lock next to
https://www.paypal.com.mysite.biz/login.php, you’re a lot more likely to log in.[Comment removed by author]
I agree. If you can prove you own the domain, shouldn’t you be able to call your domain whatever you want and get a certificate for it?
So the real risk, it seems to me, is in the way you show that proof. If the CA asks for this proof in a way that’s not secure, that to me would be a problem.
[Comment removed by author]
You may be interested to know that browsers limit wildcard certs to one level deep, for this reason.
What does this risk have to do with phishing?
In any event, the CAs aren’t the right place to solve phishing, services like SafeBrowsing are.
I like supporting wildcards but I do wish they’d dramatically increase the rate limits and decrease the suspension time. Getting banned for a week after a fuckup or bug is nuts.
Agreed 100%.
This is great news! Just last night I realised I needed one for a project, was trying to find the cheapest option. Guess I might wait :D
This is a good candidate for the
releasetag, since it’s a new feature being released/announced.Good point. Will remember next time.
No worries. :)