Hacker News Reader

Comment by Drdrdrq | Hacker News Reader

> You can purchase an SSL certificate through one of our web partners or a Certificate Authority. Read this article to learn more.

Really? No mention of Lets Encrypt? Does anyone still buy certificates nowadays, especially for dev sites?

View on HN

They explicitly mention letsencrypt as a free provider when you click the "Read this article" link.

It's not like they made any effort to make it visible, though. And "purchase" implies that the options they present are non-free.

Which is interesting, I would expect Google to promote Lets Encrypt... Or do they assume devs already know about it?

They probably don't want to cause ill will by being partial to a particular CA, even if they're supporting it.

Of course they do.

Let's Encrypt provides DV (Domain Validation). Not OV (Organization Validation).

Obviously .dev is intended for software development and most domains there would probably be using DV only so this might not apply to it, though.

OV is useless. No consumers look at it. It’s just a sad attempt for CAs to trick people into paying for something they don’t need.

Seeing the organisation name next to the lock icon definitely gives me an extra layer of warm and fuzzy feelings. I’d say it has some value for those that can pay for it.

You are talking about EV certificates. OV-validated certificates require (the best case) the user to click on the padlock icon to reveal more information about the certificate.

Do you even use Amazon or Internet banking?

It might sound useless for those who doesn't know what it is.

However, for those who does it is very useful and getting more useful.

Browsers might (if not yet, coming soon to you) raise red flags if you try to use a website whose certificate was signed by a rogue CA that, according to DNS instructions, shouldn't be able to do so for that domain.

Browsers might demand OV from high profile websites in theory.

etc, etc, etc.

Maybe we are

Not all certificates are created equal

> Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.

I buy them. I don't like paying for them, but I want a certificate I know will just work for years without having to run certbot or one of its clones on my server. Well, that and LE didn't yet allow wildcard certs when I bought mine. They've already dropped their maximum validity from three to two years though, so I'll probably throw in the towel when they further reduce their validity to less than six months.

Well that's nice. But that mean you'll have to manually buy, upgrade install and test them. I have better things to do.

Takes about 5 minutes of time. It really isn't a big deal.

So does setting up Let's Encrypt + automating the renewal, and you don't have to spend a dollar in those 5 minutes.

5 minutes once forever is even less of a big deal.

A certificate that last for years... That's exactly how you end up with a certificate that expired and no one realized. An automated process is a way more reliable.

Until the automated process breaks. I've encountered more "invalid certificate" warnings on Let's Encrypt sites than any others.

Let's Encrypt certs are valid for 90 days.

There are 2 reasons: 1. To limit damage from key compromise and mis-issuance 2. To encourage automation.

What is the issue with running the certbot on your server? It's not like you have to run it manually.

Here are official reasons: https://letsencrypt.org/2015/11/09/why-90-days.html

P.S. Wildcard certs are available for almost a year now: https://community.letsencrypt.org/t/acme-v2-production-envir...

The issue might be executing 3rd party code on a server.

ACME is an open protocol (and very soon it will be an IETF Internet Standard too). There are many alternative implementations. Just find one you trust. We actually did our own DNS-based implementation for our infrastructure.

I don't want to run someone else's code on my server just for this (the default certbot wants root access too, yikes), nor do I want to analyze someone else's implementation before running their code, and I sure as heck don't have the time, patience, or interest to write my own implementation of ACME just for the one service that uses it.

I want to go to a website, have it tell me to put a string into a meta tag or DNS TXT record, and then save the key it returns on my box. Then I want to forget about it for the next 2-3 years.

Honestly I don't even want to do that. I want my nameserver to generate a DANE/DNSSEC record for me automatically, and for browsers to honor that. It isn't like domain verification is any more secure than a DNSSEC record would be.

Take a look at https://github.com/joohoi/acme-dns/ (which of course still requires trust in the client lib)

We do something similar, although not through a REST API. We handle all this cert management centralized on one server, which publishes the DNS records for DNS verification etc.

On our other servers is then just a simple script that periodically checks if the certs on the machine are near the expiry date and if so pulls a new one from the central system.

ACME protocol is fairly straight forward to implement, and you can easily write your own implementation with existing code (OpenSSL, Apache/nginx, etc).

With many commercial registrar's, although they offer a valid and long certificate, their technical aspects aren't very good. Many CAs don't support ECC certificates, the must-staple flag or CT SCTs embedded in the certificate.

I work a lot with web PKI, and every time I have to deal with a CA that's not LE or Digicert, I sigh out loud.

Reply on news.ycombinator.com