Hacker News Reader

Comment by msumpter | Hacker News Reader

There is a nicely done 'how it works' on Let's Encrypt: https://letsencrypt.org/how-it-works/

I have read that, but it seems overly complicated. Why not just give the domain owner a private key and a script that is a few lines long. So he can sign a message from them and prove he has the key?

In the process you describe, there is no step where you confirm that you are actually the domain owner. Anyone could obtain a certificate for google.com.

Verifying domain ownership is what the challenges are responsible for.

In effect that is sort of what they are doing, but simpler.

You claim to have domain x.com. LetsEncrypt sends you a token. Place it in a DNS record or in a pre-determined path on your domain and ask LetsEncrypt to read it back.

If it matches, it is verified that you own the domain.

How is the scheme you propose simpler, whilst retaining the same base guarantee (that the requester is the owner of the domain in question)?

> in a pre-determined path on your domain

That would be easy and elegant. But they want you to install software on your server.

They want to make it easier, and that's the easiest way, but it's not required. You can perfectly well run it on your machine and copy the files manually to the server. You can even use a simple webpage as your local client: https://gethttpsforfree.com/

The only software you need is something that can speak the ACME protocol, which is what letsencrypt uses to receive your CSR (which you can generate yourself with openssl), issue challenge tokens and then (subject to you successfully passing the challenge) give you a certificate.

You don't necessarily have to do any of the above on the server for which you want the certificate. You can do it somewhere else and then transfer the resulting certificate to the intended host (either manually or with a shell script/ansible/puppet whatever).

The software just negociates the token and such things, and communicates with EL to say “I want to have a certificate for such and such domains”.

But you can place these tokens on your webserver by hand if you want, in a pre-determined path.

How do we know that the recipient of the key in your scenario (or the originator of the CSR) is in fact the domain owner? The domain contains contact information, but the exchange can't be done by email - that's not secure. Can't be done by SMS - that's not secure. We don't know them personally, so there's no obvious out-of-band technique that can be used.

We'd have to go back to physical snail mail using the address on the domain record, and/or notarization. Both of which of non-automated and very slow (relatively speaking).

I quite like using DNS verification for this sort of thing.

I always balked at the hoops I had to jump through until Let’s Encrypt came along. I now have two boxes, one Gentoo, one CentOS updating every three months pretty much pain-free. I know it's not a valid counter-argument but I'd say that 100M certs issued and the general tone of user feedback says you're wrong about it being overly complicated.

To know you're talking to the domain owner, I think you'd have to use the contact info from the whois info. I don't believe that's especially consistent across tlds.

The http or dns challenge/response is more reliable and pretty easy to automate and scale to many domains.

Reply on news.ycombinator.com