EFF Announces Certbot Client For Let's Encrypt (eff.org)

Peter Eckersley, the staff technologist for the Electronic Frontier Foundation, writes: EFF has just launched Certbot, which is the next iteration of the Let's Encrypt client. It's a powerful tool for obtaining TLS/SSL certificates from Let's Encrypt, and (if you wish) automatically installing them to enable and tune HTTPS on your website. It's extensible, and supports a rapidly-growing range of server software.
As of last week more than three million certificates had been issued, according to EFF.org, and despite a new name and host, Certbot "will still get certificates from Let's Encrypt and automatically configure HTTPS on your webserver.... We expect OS packages to begin using the Certbot name in the next few weeks as well."

Comments

CPanel

[U2xhc2hkb3QgU3Vja3M]

Any web hosting service worth the price will have an up-to-date CPanel that already has an easy-to-use "Let's encrypt" option.

Re:CPanel

[EphemeralEclipse]

There are a lot of us who have our own servers for various use cases in the form of Virtual Private Server and Dedicated. This tool, if works as advertised, will make my life much easier. No more configuring webservers manually to point to the cert directory I downloaded using let's encrypt's webroot tool. Benefit of this is that it seems like it will be supported by EFF as well, which trumps a lot of third-party tools on Github that might one-day go on unmaintained.

Re:CPanel

[gmack]

Those of us who prefer a hosting system that does not run the webserver as the same user the files of the website were owned by still need something workable.

interesting

[Anonymous Coward]

http://marc.info/?l=openbsd-misc&m=146285553703534&w=2

Re:interesting

[Anonymous Coward]

Wow. Just in case anybody might be at risk of taking the OpenBSD-misc list seriously

I particularly like the guy convinced that attackers can stop HSTS by "just blocking port 443" apparently without having tried that (if you block 443 for a host with HSTS set, the browser just says it can't reach that host at all, no sidestep possible)

All the usual anti-TLS stuff comes out though, it's supposedly not necessary, but it's also not secure enough, it's a distraction from the important goal of blocking Javascript (!?) but it doesn't matter anyway because you can install packages downloaded from FTP and for the past couple of years OpenBSD even knows how to PGP sign them...

I presume OpenBSD is embarrassed that this list exists, but if so why does Theo post there? Ah, because he too wants to get in a dig about how if people write big complicated things it means they're shit - as evidenced by OpenBSD's sprawling garbage heap of an OS.

Still depends on gcc? Still needs root?

[Anonymous Coward]

Do I still need to install a compiler on the server to use it, and then wants to be run as root? Because I consider that a total no-go.
When I tried to run it, it seemed like a bunch of security-worst-practices bundled into an auto-installer that doesn't even ask you before it installs things that should never be on a server.

Re:Still depends on gcc? Still needs root?

[NotInHere]

You need to prove to Let's encrypt that you own the domain. For that you have to add a special file to a special place inside the http accessible part of the website. This special file can only be added by root. Other than that there are multiple ACME clients available if you dont like one you can use others as well.

https://community.letsencrypt....

Re:Still depends on gcc? Still needs root?

[Anonymous Coward]

You need to prove to Let's encrypt that you own the domain. For that you have to add a special file to a special place inside the http accessible part of the website.

So, I'd also have to open up the standard HTTP port to outside traffic just so they can check I 'own the domain'? that, and the idea of running
a 'certificate management agent' on my web server....no, no thanks, I think I'll just stick to my 'home-rolled' certificate and my server sitting on a decidedly non-standard port..hell, it's been working for years now, and for what I use it for this'll suffice.
thanks anyway..(and btw, why the hell does the certbot want yum?)

Re:Still depends on gcc? Still needs root?

[CRC'99]

You need to prove to Let's encrypt that you own the domain. For that you have to add a special file to a special place inside the http accessible part of the website.

So, I'd also have to open up the standard HTTP port to outside traffic just so they can check I 'own the domain'? that, and the idea of running
a 'certificate management agent' on my web server....

I've been using StartSSL's free certs for that exact reason. They've got free 1 year certs vs LE's 30 days - and recently they've done a StartAPI to get these automagically.

Right now though, they still use HTTP validation - like LE - but hoping they'll have other options.

I've also just finished a proof of concept implementation of their API at https://github.com/CRCinAU/sta...

Hoping to get some review on it and hopefully some submissions to add to the functionality.

Re:Still depends on gcc? Still needs root?

[CRC'99]

Hah - and being too quick on the Submit button, I forgot the more important point I was getting at... (Say, I should apply to be an editor)

Once you validate the root domain with StartSSL / StartAPI, you can create certificates for any subdomain attached to that domain - so you don't have to have port 80 to the world - or even a web server installed on anything but the root domain - and most people already have a setup like www.mydomain.com / mydomain.com going to the same web server.

Re:Still depends on gcc? Still needs root?

[Anonymous Coward]

You need to prove to Let's encrypt that you own the domain.

Correct

For that you have to add a special file to a special place inside the http accessible part of the website.

Sort of. LetsEncrypt will expect a certain URL to provide a certain response. There's no need to involve files.

This special file can only be added by root.

Absolutely wrong in all ways. If you're using a file at all (which isn't necessary) then any user with write permissions to the directory where the file goes is perfectly capable of putting the file there.

Re:Still depends on gcc? Still needs root?

[motokochan]

You don't need to be root to add the challenge file, just have permission to write to the website folder.

You can also use DNS verification, although that method is not present in Certbot yet. There are a few third-party clients that do support that method, however.

Why need root to write to your own site's htdocs?

[tepples]

You need to prove to Let's encrypt that you own the domain. For that you have to add a special file to a special place inside the http accessible part of the website. This special file can only be added by root.

Why can't a process running under the user account of the website's owner write to a folder owned by the website's owner? As far as I can tell, the only part that ought to need superuser privilege is configuring the web server to use a particular certificate.

Other than that there are multiple ACME clients available if you dont like one you can use others as well.

The shared hosting provider WebFaction refuses to make automatic Let's Encrypt support available or let users programmatically upload a private key and certificate. Instead, the user has to submit a support ticket every time the certificate changes. This led to the creation of a passive-aggressive ACME client called letsencrypt-webfaction, which automates obtaining the certificate and filing a support ticket every two months.

Hiawatha webserver and Let's Encrypt

[Aethedor]

The latest release of the Hiawatha webserver has its own Let's Encrypt script included. Seems to work ok. Anybody tried Hiawatha yet? How good is it?

Re: Hiawatha webserver and Let's Encrypt

[Anonymous Coward]

Hiawatha's letsencrypt script is the most easiest one I've seen. I don't use Hiawatha for production, but it's rock solid and just a brilliant webserver.

Still no official Windows client?

[rklrkl]

It's surprising that after all this time in beta and a move of its home to EFF, there still doesn't appear to be an official client for Windows Servers running IIS. Yes, there's several unofficial Windows clients, but am I supposed to trust them and even if I did, which one is the best?

Re:Still no official Windows client?

[krelvin]

Would most likely get a better answer via their support forum at Let's encrypt than hoping for a good answer here.

Re:Still no official Windows client?

[Anonymous Coward]

Never mind IIS on Windows.

How about Apache Server on Windows?

They already support Apache Server on almost everything else.

Re:Still no official Windows client?

[Anonymous Coward]

It feels irresponsible to give users a sense of trust and security on a Windows platform.

certs

[fyngyrz]

Was this the service that provided certs of short-length expiration, a year or so?

Or am I thinking of something else?

Re:certs

[Anonymous Coward]

Yes, Let's Encrypt does provide certs with short expiration time, but they last 3 months rather than an entire year. The idea is that you have a client that automatically renews your certificates for you.

StartSSL provides 1-year certificates.

Re:certs

[fyngyrz]

Ah. Well, okay, then this: Why not just issue a certificate that works long term and doesn't require unnecessary network activity and exposure?

I presume there is some benefit this is supposed to provide, but I'm sure not seeing it.

Re:certs

[JesseMcDonald]

Given the fact that certificate revocation lists have not proven particularly effective, the advantage of the short renewal period is that a compromised certificate can only be used for a few months at most before it expires naturally. This requires a bit more (automated) network activity, but reduces the exposure to attacks against the site's private keys.

Re:certs

[fyngyrz]

And these attacks, uses of compromised certificates, are they common enough to justify this level of paranoia?

Re:certs

[fyngyrz]

Also, can the automated process be compromised? Seems like if you can get a site's certs, you can probably compromise the cert-obtaining automation as well, no?

Re:certs

[JesseMcDonald]

Seems like if you can get a site's certs, you can probably compromise the cert-obtaining automation as well, no?

In the most typical installations, probably, though there are ways to prevent that. The automation doesn't actually need to run on the same machine as the main site, much less under the same user account. The script just needs to be able to publish a file at a well-known HTTP URL on the target domain—the operator could easily arrange to have that request forwarded elsewhere, and pass the new certificates to the server through a dedicated channel. A reverse proxy could also be employed to keep the HTTPS certificates away from the server running the main site, which is the most likely target for attack.

In any case, even if one assumes that the server itself is compromised along with the certs, fixing that is just a matter of cleaning up or replacing the server, whereas the compromised certificates remain a threat until they eventually expire. Once the server is fixed the attacker won't be able to obtain any new certificates.

The threat model is an attacker with one-time access to the certificates and the ability to mount an active MitM attack, but not persistent control over the server; if the attacker controlled the server itself they wouldn't need to compromise the certificates.

Convenience

[Anonymous Coward]

Indeed, you could even set up a user that can only write to the challenge folder; that's the recommended configuration for acme-tiny.

But to set that up you need knowledge of how to set permissions; I think certbot expects root in order to avoid that.

Re:Convenience

[tepples]

But to set that up you need knowledge of how to set permissions

All you really need to do is set up suexec. Then your CGI and FastCGI scripts run as you, and the ACME client running as you can write to the challenge folder that you own.