Hacker News Reader

Comment by mootothemax | Hacker News Reader

I strongly recommend using acme-tiny for generating Let's Encrypt certificates:

No worrying auto-configuration; no need to take sites down; no unknown unknowns.

Just follow the simple steps, and automatic certificate generation can be set up in moments.

(in fact, I'd be kinda surprised if Let's Encrypt don't start recommending it as their "know what you're doing? then use this" option)

View on HN

That looks like a lot more work than the official client. I don't get why so many people immediately on the first day of public beta turn to alternative clients. I used the official one, and by looking at the --help options I easily found how to automatically generate a certificate without taking down the server, and without using root privileges:

    letsencrypt -t --work-dir /tmp --logs-dir /tmp \ 
    certonly --webroot /var/www/example.com/htdocs -d example.com

With this in nginx.conf:

    listen 443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem

Those paths are examples obviously. But I did that, issued a 'service nginx reload', and it was done. I can reissue that command in a cron job to renew whenever I want.

There are some Python dependencies for the official client, but my package manager installed them for me, so I don't get why people avoid it, especially when most of these alternative clients require more work.

The official client handles your registered account, and I don't trust the alternatives not to mess with that or be incompatible in some way, so if you ever want to seamlessly use the official again you might end up with a different account identity or something. I don't know, I didn't look too deeply into it, other than the steps, and the official one was easiest for me.

>That looks like a lot more work than the official client.

Maybe some people have different experience levels, time constraints, or patience for the non-obvious than yourself?

I myself by far found tiny-acme the simpler client to understand; there was absolutely zero worrying about what modifications are being made to configuration files, nor concerns about how best to get everything in a nice cron job.

If this is a case of the official client's documentation being too dense for the likes of me, then so be it.

Edit:

>There are some Python dependencies for the official client, but my package manager installed them for me

I just saw the top post regarding this, and then re-read about it in your comment.

For me - again, possibly a different use case to your own - this is not cool.

It's not about ease of use, it's about trust.

acme-tiny is short enough that anyone with a cursory knowledge of Python can audit it and know exactly what it's doing.

If you don't trust the official client, why do you trust them to be your certificate authority? Also, note that I ran this command as a normal user, not root.

The purposes for which you trust a CA and the purposes for which you trust a software developer are different, the ways of verifying what they do are different, and the ways their work can go wrong are different.

I work on the official Python client for Let's Encrypt, but I support people's decision to use a different client if they prefer.

It's frustrating to see the occasional conspiracy theory suggesting that the Let's Encrypt project somehow wants to backdoor the client in order to compromise people's servers (an idea that occasionally gets brought up on our forums!). But it makes sense that some people want a client that doesn't modify their server configurations. The official client tries to modify server configurations because we believe that many people don't have the expertise or inclination to do it on their own. That goal does make the official client more complex, and there are still plenty of integration bugs to find and fix. If people want a simpler and more hands-off client without the integration features, they should definitely use one, and it's a valuable service that this option is available.

> because we believe that many people don't have the expertise or inclination to do it on their own.

So they've set-up a server or VPS, installed a web server and possibly a CMS, configured virtual hosts and appropriate users, hooked-up an RDBMS but... SSL is too hard?

Don't kid yourself, most hobbyists are keen on Let's Encrypt because it's free.

People who really don't have knowledge or inclination for SSL configuration will be waiting for an option on their hosting provider's control panel. They don't have root shell access.

> It's frustrating to see the occasional conspiracy theory suggesting that the Let's Encrypt project somehow wants to backdoor the client in order to compromise people's servers

That's not the only reason someone might not want to use the LE client. Here are a few others:

1. The LE client might have a bug that causes problems on my server.

2. I may have done something non-standard to my config files that the LE client undoes.

3. Someone may have compromised the LE client or one of its dependencies without your knowledge.

I agree with those concerns, and I definitely don't mean to suggest that people who chose not to use the client all believe in conspiracy theories about the developers' intentions.

Wow, awesome to hear you chime in, and thanks for your great work on getting Let's Encrypt up and running!

Please don't take my post as a direct criticism of the official client; I think it's just a question of use cases, and my case doesn't have much overlap with the "I want a client that takes care of everything" use case.

If you can't trust a CA not to prevent their official client from becoming malware, then I don't see how you can trust them to maintain their position as CA. There is no real scenario where the official client is discovered to be backdoored, and people go on using Let's Encrypt certificates.

Malware isn't the problem - their automagic client screwing up my webserver is the problem. This is a justified concern given that the official client already demonstrates bad behavior by causing side effects on --help (see my top level post).

Even worse: It already has screwed up my webserver.

Script crashed while trying to verify, left the apache config files in the modified state.

Trying to get that back to work took another half hour of the server being down.

I’m gonna use the simple website someone made to generate certificates from now on.

Take a look at acme-tiny as well. You can run acme-tiny in a cronjob to update your certs, since LE certs expire in 90 days.

Doing it manually every 90 days isn’t that hard. I’d prefer if the default client would properly separate the parts it does, though.

It is not a concern at all for me, because I can run that command from a user that does not have privileges to mess anything up. Those options make it not even attempt to read or write any web server configuration. All it does is create the certificate.

>If you don't trust the official client, why do you trust them to be your certificate authority?

I took the OP to mean e.g. editing configuration files correctly, rather than a question of the code itself being compromised.

In other words, a concern about day-to-day coding rather than security.

I trust them to maintain a secure CA (and I trust that there are adequate checks and audit mechanisms in place).

I do not necessarily trust them to not muck up my webserver configs, or to accidentally expose my private key due to some bug. While I have no reason to doubt the code quality of the official client (and I'm certainly not suggesting I suspect any malicious activity), I suspect the checks in place for the client are probably less rigorous than those for the CA itself.

acme-tiny is less than 200 lines. Short enough that reviewing the code took a trivial amount of time, and now I'm using a client that I can trust completely.

I could certainly do the same thing with the official client, but it would take me several hours (at least) to get to the same level of comfort.

Good look then auditing Python with it.

For some folks, even running Python where you terminate your SSL/TLS is too much of external dependencies.

That's an argument I can never win. There is always another layer down the stack that I haven't/can't audit. That doesn't mean it's not better to audit what I can.

True - Someone implemented it in bash/openssl/curl/sed only.

https://github.com/lukas2511/letsencrypt.sh

Reply on news.ycombinator.com