Live data from Hacker News

Milestone: 100M Certificates Issued

letsencrypt.org

81–90 of 197 posts

Re: Milestone: 100M Certificates Issued

#81
post #15
post #7

Earlier quoted context omitted.

What prevented Paypal phishing sites from buying certificates from other providers?

checks they're supposed to be performing. Some are ignoring them but being punished for it. http://www.bbc.com/news/technology-39365315

Both Mozilla[1] and Google[2] are on the record as saying that they don't believe CAs should be the ones to detect and block domains used for phishing and malware. Both are also platinum sponsors of Let's Encrypt.

[1]: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

[2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

Re: Milestone: 100M Certificates Issued

#83
post #30
post #10

Earlier quoted context omitted.

I was in the same boat, I didn't like having to run python on my server just to renew a SSL certificate. Still, a few months ago I decided to give it a try and I don't regret it. The certbot script is packaged in FreeBSD, it wasn't painful at all to setup and a crontask later it was over. Definitely beats the crappy free "startssl" certificates that I used previously.

acme.sh runs in pure shell, no need to install Python. It's my goto client and it just works.. everywhere. https://github.com/Neilpang/acme.sh

acme.sh + static verification is indeed a very nice zero maintenance solution.

Re: Milestone: 100M Certificates Issued

#84
post #80

I love letsencrypt but I wish they would hurry up with deterministic dns challenges. It would make securely automating certificate renewal vastly simpler and easier (especially for certs that are being used for non www serving endpoints e.g. mail servers etc). I worry that at the moment there are probably a lot of systems out there that leave DNS API keys lying around on endpoints because it's easier to automate the…

This is due to the CA/B Forum Baseline Requirements stating that domain validation via DNS records (and pretty much all other methods) has to use either a random value or a single-use request token.

There's a neat trick with CNAMEs and a separate DNS zone that works kind of as a workaround, if you're okay with introducing another piece of infrastructure[1].

[1]: https://github.com/joohoi/acme-dns

Re: Milestone: 100M Certificates Issued

#85
post #73

Earlier quoted context omitted.

The LE protocol is fully open and even specified in RFCs - I wonder if any paid cert providers will ever move to that type of painless automated renewal (plus automated billing, of course). This would allow folks to potentially get their "advanced" certs (EV, wildcard, crossdomain, etc.) renewed without the rigmarole that you mention (although some cert categories come with their own non-automatable processes). Right…

EV certificates are not allowed to be renewed automatically AFAIK.

That's not a part of the ACME protocol (which is what Let's Encrypt implements), it's a policy decision of Let's Encrypt. Grandparent's comment is about other CAs offering EV certs over ACME.

Re: Milestone: 100M Certificates Issued

#86
post #84
post #80

I love letsencrypt but I wish they would hurry up with deterministic dns challenges. It would make securely automating certificate renewal vastly simpler and easier (especially for certs that are being used for non www serving endpoints e.g. mail servers etc). I worry that at the moment there are probably a lot of systems out there that leave DNS API keys lying around on endpoints because it's easier to automate the…

This is due to the CA/B Forum Baseline Requirements stating that domain validation via DNS records (and pretty much all other methods) has to use either a random value or a single-use request token. There's a neat trick with CNAMEs and a separate DNS zone that works kind of as a workaround, if you're okay with introducing another piece of infrastructure[1]. [1]: https://github.com/joohoi/acme-dns

Yeah I read somewhere that they were working to try and get the CA/B rules changed to allow it (no idea if this is true).

Will check out the CNAME trick - thanks!

Re: Milestone: 100M Certificates Issued

#87

Earlier quoted context omitted.

Indeed, but I cannot see how this addresses my question?

because your private key never needs to be compromised, even if your server is breached, because it never needs to be on the server. That said, I agree that if the PK is only used for this single server, you have bigger problems than its loss if your server is breached.

If the key isn't on the server how does software use the certificate?

Re: Milestone: 100M Certificates Issued

#88
post #73

Earlier quoted context omitted.

EV certificates are not allowed to be renewed automatically AFAIK.

That's not a part of the ACME protocol (which is what Let's Encrypt implements), it's a policy decision of Let's Encrypt. Grandparent's comment is about other CAs offering EV certs over ACME.

???

EV guidelines have nothing to do with Let's Encrypt or ACME. They state that even for renewal all checks have to be done again, which cannot be automated.

Re: Milestone: 100M Certificates Issued

#89
The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew.

As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc:

https://letsmonitor.org

Feel free to use it for any certs.

Re: Milestone: 100M Certificates Issued

#90

The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew. As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc: https://letsmonitor.org Feel free to use it for any certs.

Out of interest, what makes you not want to rely on auto-renew?
Post reply on HN