Hacker News new | past | comments | ask | show | jobs | submit login
Let's Encrypt has issued its first million certificates (eff.org)
443 points by thejosh on Mar 8, 2016 | hide | past | web | favorite | 152 comments

> It is clear that the cost and bureaucracy of obtaining certificates was forcing many websites to continue with the insecure HTTP protocol

I never realized this so clearly, but it's true. The biggest hindrance to security until LE was that certs were expensive and hard to install. I don't think it was so much the former as the latter. I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

Then again, for small things, like my home computer that I want to access some stuff on but don't want to pay $10 for, self-signed was fine, so I guess the price was a problem, to a degree.

> I never realized this so clearly, but it's true. The biggest hindrance to security until LE was that certs were expensive and hard to install. I don't think it was so much the former as the latter. I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

Absolutely! Every time I had to create a CSR and install an SSL certificate on a server (having done it before in the past), I felt repeatedly terribly painful the process was.

I've wondered if this issue could have been solved a long time ago by commercial companies (the way LetsEncrypt solves it or similar), it just wasn't as good business :-)

Heh. If the CAs had done this ages ago the cost of certs would have collapsed. I can't help but think that collusion between the CAs was a regular thing to prevent something like LE from happening in order to prevent the business model from souring.

I'd imagine so. I also like the approach that Amazon has taken with its recently launched AWS Certificate Manager. You can create as many SSL certificates as you like free of cost, even wild-card ones (which if I am correct Let's Encrypt does not support yet), and the AWS Certificate Manager takes care of the rest. The only restrictions, off the top of what I've read, are: 1) You have to be using the AWS infrastructure; b) You'd have to use their load balancer or CDN solutions, against which the certificates are placed.

SSLMate has been doing that for a while.

Certsimple does autorenewal.


I personally find the hassle of installing, configuring and, crucially, testing, both LetsEncrypts scripts, and an accompanying cronjob, much more work and worry than a static nginx ssl config.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling.

You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and just focus on the actual work. Every year, you have to request a new certificate, wait for your certificate authority, upload the new certificate to the server, reload your webserver, check if everything works.

With LE, you do all of that once. You set up the tooling and the cronjob once. You make sure it works once. And you're done. No more hassle.

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways.

I'm not claiming these risks are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind.

And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons.

On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders.

I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.

> What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date?

That's why I renew them a week in advance. I set up Nagios checks which alert me when a certificate is not renewed. Those were already in place before LetEncrypt since human error is just as likely as a script breaking.

I renew every month and have not hit their rate limits. That way, even if the cron job doesn’t fire and I don’t notice, there is another chance a month later.

  given that LE takes just as much time and effort for
  initial set-up as a standard multi-year cert
I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way.

It's just going to take a long time to get there :)

> I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH

It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better.

A better comparison would be with DNSSEC...

The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense.

The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.

The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.

As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.

Yes, there will be products to make this simpler, but the point is, unless you are willing to grant LetsEncrypt a DV cert monopoly, to the exclusion of all others (or at least those not compatible with their API), then, in general, it can never be as easy as just turning it on.

DNSSEC puts the CA monopoly in the DNS. There is no API for a hypothetical web server using DANE, because there's no need for periodic domain validation. Of course, DNSSEC is a disaster, so it's a non-starter... but I'm still going to lament the fact that everything is terrible.

Since LetsEncrypt's API protocol is being standardized through the IETF (https://tools.ietf.org/html/draft-ietf-acme-acme), there's no reason any new competing free certificate providers can't be compatible with it. In the long term, if more show up (and I wouldn't be surprised if some existing CAs refocus their business on EV and start offering free DV certs through ACME), I see no problem with software giving the protocol a "monopoly", in the sense of building in auto-configuration support for it.

> Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception.

Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.

He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.

Let's Encrypt renews certificates after 60 days by default, giving you a 30-day grace period for outages, etc. Use a daily cronjob and monitor your certificates. Setup alerts if your certificates are closer than, say, 25 days to expiration. This should cover temporary outages, bugs, etc. - and the monitoring bit is no different from what you should already have even with manual renewal.

> What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios?

I run my cron job[1] every hour. It checks for the expiry of my existing set of certificates and has a configurable parameter as to how soon before expiry to renew them.

[1] https://github.com/frutiger/concorde

Nagios will tell me when my certificate is a month within expiring. This is a standard nagios plugin. The cronjob runs nightly, checks if renewal is necessary (once a month, certificates valid for 3 months, so will renew when 2 months are still left) and then does its thing.

run it @weekly

it's what I do

I think you are underestimating the cognitive burden this added complexity puts on your ops person (maybe yourself)

I know for me, it was a choice between farting around with lets-encrypt for hours, or a $40 wildcard cert. so I went with the $40/year cert instead.

There are just too many choices for lets-encrypt with no super-simple how-to for people who don't know this stuff (like myself).

I thought the same, until I actually took it upon myself to actually try LE. 15 minutes later, I had all my sites on LE, automatic renewal configured. I'm looking forward not having to sign in to some website, cut'n'paste certificates around, convert to/from PEM, figuring out what the correct chain is this time, etc.

I guess I'm stupid then, because I spent more than an hour trying to figure an easy way to add these to my auto-provisioned servers before giving up and using the static cert instead.

Can you update the certificate without taking down your nginx server? I assume you need port 443 for LE to verify your domain, right? Can you use a different port?

Yes, use the "webroot" method of the official Let's Encrypt client.

I see, thanks. I use the docker container "version", so I assume I have to somehow mount a volume to the container, that's also accessible from my nginx ( or whatever ) container, so it can serve the static file LE creates. Is there something more to it?

sure - run the renewal from a different server

You can do it on the same server without downtime by using the "webroot" method of the LE client.

You're right, even with Let's Encrypt HTTPS is still more work than speaking insecure HTTP. But it's a brand new project, and we're working to ensure the amount of effort involved is monotonically decreasing.

In the next few months we'll be shipping an Nginx installer plugin and model renewal scripts for operating systems to provide native automated renewal with their packages of the client. Both of those should help to reduce the amount of work for your use case!

I'm in the same boat - especially because I need wildcard certificates (or just lots of certs).

I'm thinking the only thing that would really fix this is an nginx module that would automatically fetch certificates for domains when they're first requested via SNI. First hit takes some time, then it's cached and refreshed once a month or something... it would effectively mean 0 configuration SSL for all new domains.

If you can use OpenResty (nginx+Lua), then that's exactly the approach I've taken for a plugin I've been developing recently (SNI, on-demand, and caching): https://github.com/GUI/lua-resty-auto-ssl There's still a couple loose ends to tie up, but we've been using it on production for a few weeks now, and it's been refreshingly nice to not worry about SSL for new domains.

Regarding the 5 requests per week, I believe that's only for repeated re-issuances of the same domain. As long as you cache the certs, then this shouldn't be an issue. Registering new certificates for new domains is limited to 500 per 3 hours: https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

Wouldn't work, sadly you're limited to 5 requests per apex per week.

that has to be one of the dumbest things I've read all year.

this is too hard: https://antipaucity.com/2016/02/26/automated-lets-encrypt-ss... ?

> I'd gladly pay 10% more for my cert if it meant my server could renew automatically without me touching it at all.

I wrote a server that does this. Would be happy to have your feedback sometime: https://caddyserver.com - here's how it works with regards to Let's Encrypt certs: https://www.youtube.com/watch?v=OE5UhQGg_Fo&t=32m

Oh, I've downloaded Caddy and used it a few times, I love it but haven't switched anything to it yet.

To me, the killer feature right now is that I can just drop it in my /usr/bin directory and have a performant HTTP server in the current dir with just one command. I don't use the LE integration (even though I love the feature) because I haven't deployed it in anything outward-facing.

One small nit would be that I'm not very clear on how the LE fetching is done (where all the files are placed). The docs do mention this, but I left with a feeling that I was still not very clear on where the files go after reading it. Other than that, great job on Caddy!

Found this tutorial yesterday about how to do it with letsencrypt https://www.digitalocean.com/community/tutorials/how-to-secu...

I use simp_le for that. I more meant "I'd have paid a CA 10% more for automation", but that ship has sailed now that LE has launched. I'm probably not going to be using anything else any time soon.

Yeah. I was really against SPDY/HTTP2 only supporting encrypted websites until Let's Encrypt came along, as it would have "forced" all the small sites to keep using HTTP 1.1 forever. Now I don't mind the requirement at all.


From what I got, it forces opportunistic encryption only. If there is no special signed cert available, it just generates one randomly and uses that. Unsafe against people who can modify your connection, but it protects against passive eavesdropping.

All major browser vendors decided not to implement opportunistic encryption in HTTP/2.

So they force either a valid cert or nothing? Not even unencrypted http/2? Because that would be quite awesome.

Edit: are there statements where they say they don't intend to implement it ever, or is it just not supported yet and e.g. Microsoft might still implement it later to please some enterprise stakeholder?

According to this[1], that's a permanent decision. Given that both Google and Mozilla have discussed plans that would eventually mark http:// as unsafe in the UI, I don't think that decision is going to change.

[1]: https://daniel.haxx.se/blog/2015/03/06/tls-in-http2/

Well there is a difference between unsigned encrypted and unencrypted, I'm not saying marking http:// as unsafe implies that they'll always regard unsigned encrypted as completely unprotected, especially with closed source browsers (or browsers where development is a closed process).

Thanks for all the information though! :)

From the point of view of an active MITM attack there is no difference between unsigned encrypted and unencrypted.

I tried to get SSL cert for my fathers company and different kinds of certificates just scared me. Do you know there is a kind of cert where you need to go in person with your ID and register yourself? I'm currently using LE for 6 domains, 2 of them joined as first 100 LE domains, before LE was supported by Ubuntu.

However, imho, he biggest reason to ever use self signed is that you can set expiry @2099 and it won't degrade anything.

1. You'd have install the custom CA in all devices. Ever tried it on Android? The "network may be monitored" warning doesn't go away.

2. If the certificate is ever compromised, you'll have to keep it in the revocation list forever, or replace the entire CA.

(And I hope your CA contains a DNS name restriction.)

>1. You'd have install the custom CA in all devices. Ever tried it on Android? The "network may be monitored" warning doesn't go away.

This is the most annoying part of using certs for Radius authentication with Android. Either you self-sign a cert and forever get these warnings, or you let someone else sign your cert and then that CA can issue device certs for your domain.

At least modern Android version support setting the CA certificate in the wifi settings.

(And then there's the university way of things: just run your own trusted (!) CA ;-) (e.g. in Germany: signed by DFN)

And hosting companies selling certs are incentivised to not provide HTTPS by default.

The number of not https wordpress admin pages and plain text ftp logins still in regular use is chilling and directly attributable to this misaligned incentive.

There's an oft-neglected issue with this. From experience, when a hosting company supplies an SSL certificate to a customer, here's the usual process. The first thing that happens is the site totally breaks because browsers won't render mixed content.

So the customer calls their developer and their developer calls the host and insists it's a server problem and someone spends an hour or more explaining what mixed content is to a developer and how to fix it.

Then someone runs it through the SSLLabs test and decides they don't like seeing RC4 supported. So you provide some warnings regarding it, confirm, and then oblige, but then you get angry, aggressive emails because their entire office uses Windows XP and their website doesn't work.

A company can burn hours on every individual SSL deployment. There's plenty of unfortunate incentives against hosting companies.

The default LE client was kind of a pain to work with. The docker container was better but where it really helped was the Lego golang implementation. That one 'just works' and was super easy to setup behind nginx to run automatically. It also writes a nicer config dir.

In case anybody didn't know, there are already over 10 alternative clients. There should be something for everyone:


Still waiting on a Glassfish or Wildfly client. We managed to wrangle the standalone client to generate a certficate that can be used by glassfish, but it's not pretty. See the code here: https://github.com/hopshadoop/hopsworks-chef/blob/master/rec...

acme-tiny is another good and simple client, which I personally prefer.

I've recently compared 10 different Let's Encrypt / ACME clients: https://www.metachris.com/2015/12/comparison-of-10-acme-lets...

I forked acme-tiny the other day and replaced http-01 with dns-01. The dns-01 implementation is pretty simple and crude for now, I'll probably add dynamic dns update support at some point. All it does is print the records out and wait for you to add them manually.


For now I've just done enough to get a cert for a mail server.

In your review, whenever I click a "show output" link, it navigates to another page containing only "[object Object]". Can you change the href to be an onclick attribute or something like that?

Thanks for the suggestion, I'll update the post tonight. Didn't notice / cannot reproduce - it seems to work for me in all browsers.

I found the default client to work as expected. It doesn't automatically modify nginx config, but I really don't want it to. It's simple to point the config to a correct location and then just use the webroot plugin. (Granted that needed the change to allow access to hidden directory via HTTP, but that wasn't rocket science either)

Thanks for sharing your experience here, I'll go straight to lego when I go to set it up. It's hard to beat the simplicity of a Go binary for system tools like this.

How is a binary simpler then a script?

True Go binaries like lego[1] are statically compiled (zero external dependencies). No need to fuss about versions of installed dependencies, updates, package management, etc. You just run the binary and it just works.

[1]: https://github.com/xenolf/lego

Can't you package a script with all required dependencies, including the interpreter?

acme-tiny was the winner for me.

So what does this mean for the incumbent CAs? Are we going to see a lot of consolidation in that area?

At a first glance it looks like LE has neutered the DV cert business. How much of their revenue is up for grabs here... how strong is the incentive to pursue extra-legal means of killing off LE? (Such as by stealing and leaking their signing keys...)

I doubt it. CAs still have EV, wildcard, email, and code signing certificates that are often twice as expensive (or more) than their DV offerings. And some people will choose to pay for a DV cert just so they don't have to swap them out every 3 months anyway.

EV can die a fiery death. It is bullshit. I don't see a reason why LE can't issue wildcards in the future, though with their current setup they are even less important. Email certificates can be issued by LE as well. Code signing is the only one I see as problematic.

In either case, I suspect that LE will take a huge bite out of CA's bottom lines, since there are a lot more DV certs out there than EV ones.

Honest question: why is EV bullshit? It's easier for my mom to check for a green bar saying "Bank of America" than to understand the difference between bankofamerica.com and bankofamerica-onlinebanking491.com. EV may not be bulletproof, but it potentially makes some rather popular attacks way harder to execute at scale.

Well, for one because EV certs are ridiculously overpriced. Also, EV once again just guarantees that someone somewhere has a credit card and some papers they filed. Can I start a "Bang of America" and get an EV cert for that? Sure I can! (Don't google that).

Another example of where I think it's confusing is when EV actually uses the company name. Go to https://lastpass.com/ and take a look at their EV green bar. It says "LogMeIn, Inc [US]" and before it said "Marvasol". Neither of them says "LastPass" which is what I actually want to know. If the company name behind your product is not as widely known as your product, oops, you just scared your customer.

Basically, it's a hard problem: you are asking CA's to make the distinction between names that may be similar, and therefore used for fraud, vs distinct and used for legitimate purposes.

If you think EV certs are over-priced, then there's a big market opportunity waiting for you: just make a CA that sells them cheaper!

In practice, you probably won't do that, because if you look into the various costs EV CAs have, you'll find that the cost of what they're doing is actually non-trivial and it's not exactly a license to print money. Add up the costs of the company, the audits, the hardware to protect the keys, the humans to perform the manual verifications of the cert requests, the OCSP servers, the software dev costs etc ... it's not zero.

With respect to phishing, yes, you could get "Bang of America" (possibly), but this comes with two MASSIVE caveats:

• You cannot do so anonymously, or at least it's very difficult to do so.

• You cannot get something like "Bank of America System Network" because the CAs have procedures in place to stop that sort of thing ... like human review.

In practice, phishing sites based on similar looking letters were a thing decades ago but haven't been so for a long time, partly because there's only a tiny number of such combinations and the legit companies normally own them all. My experience of phishing sites from a few years ago was that they either used misleading DNS names like "www.bankofamerica.com.net.cdn.co.cn" which exploit the fact that people stop reading at ".com", or just didn't care at all and used phishing sites hosted on hacked web servers, which exploit the fact that a lot of people don't ever look at the URL bar at all.

EV is a key step towards fixing both problems, by giving people sensible human meaningful identifiers that are read left to right instead of right to left, and by providing a friendly name that could (in a smart browser) replace the junk in the URL bar entirely. If most sites used EV certs there's a chance users would actually start reading the URL bar again, and then they'd know where they are online.

I agree that companies whose primary web identities don't match their legal identities are an issue for EV certs, although arguably that problem will confuse users sooner or later anyway (e.g. if they need to send/receive money from that company). Better to have the names synced.

> companies whose primary web identities don't match their legal identities

On https://www.washingtonpost.com/, the EV bar reads: "The Washington Post (WP Company Llc)", so there are solutions for that, too.

Yeah, wildcards are a necessity when every certificate is difficult to obtain, but LE really means we hit post-scarcity and certificates can be issued on the fly for new domains and subdomains.

To an extent - LE still has rate limits for the number of certificates issued to a second level domain (5 in 7 days currently), so if you have many subdomains it could conceivably become unmanageable to keep them all updated.

EV is what CA's was supposed to do but initially never did; a trusted third-party validation that checks if a online identity really match the real world identity. Its similar to PGP key-signing, but on a government/industry level.

The question I wonder is if CA's can actually survive on only doing their intended job, and if the green bar can sustain enough trust to be worth paying for.

EV needs to be more widespread.

15 years from now we'll probably see a "Let's Validate" as a web-wide movement, to EV every website... but i'll probably cost $100.

What does updating every 3 months matter when you can cron the renewal?

My limited understanding- LE certs only say that the data sent between you and the server is encrypted, while traditional CAs also tell you 'who' that server belongs to.

So, your connection to trentmb.org may be secure, but it may not be this trentmb you're exchanging data with. Traditional CAs claim to do some sort of ID verification.

EDIT: I am very wrong.

This is incorrect, potentially in a few ways.

DVs are available from almost every CA. They're popular because they involve no paper checks which makes them cheap and fast. You don't need a company to get one, like you do with OV and EV.

DV should give some level of confidence that you're connecting with the owner of the domain name. CAs should make you go through a process that only a domain's controller could complete.

So I can't get a DV for paypal.com but I can get one for olipaypal.com if I own that domain. I can't get an OV or EV for either domain showing Paypal as the company unless I somehow manage to register that as a company name somewhere. Possible? Probably.

To be fair, with LE you do need to verify you're requesting the cert from the domain for which you're requesting it, so there's some validation. It would be really difficult (for me, impossible) to get a Let's Encrypt cert for, say, wellsfargo.com. It's not one of the fancy CV certs like at https://www.grc.com/intro.htm, but they're the same certs Amazon.com uses.

It looks [1] like some CAs depend heavily on DV certs (GoDaddy) while others do not (Digicert).

[1] http://www.netcraft.com/internet-data-mining/ssl-survey/

Interesting. I wonder how critical to GoDaddy's business the certificate sales are, or if they're really just a sideline to their core hosting business.

I hope that Let's Encrypt will be able to issue wildcard certificates at some point.

I believe you can add 100 subdomains to an LE certificate which gets you pretty close to a wildcard IMO (if you have over 100 subdomains then buying a real wildcard cert is probably a negligible cost for your service).

This is not quite right. You can pack up to 100 hostnames into ONE cert. That might be useful if you are trying to avoid SNI issues on a single shared IP address.

However, you are limited to five subdomain registrations or renewals per seven day window. Since certs are only good for 90 days, you are effectively limited to 60 or so, and that only if you do some crazy timing acrobatics, carefully spread the registrations out over the full 90 days and never make a mistake.

So I would say, at this point, LE is not an effective replacement for a wildcard cert for many people.

Scroll down to "Rate Limits": https://community.letsencrypt.org/t/quick-start-guide/1631

They really need to change the rate limits to something more reasonable. Both per domain and per ip.

That would be nice, but with it being so easy to get a certificate, you could just add a new SSL cert when you add the new subdomain.

If there only wasn't the limit of 5 certificates per domain per week [1].

[1] https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

When it comes to rate-limiting, example.com and foobar.example.com are treated as completely separate domains.

That would be pretty awesome, but it's not how I interpret the following: "This limit measures certificates issued for a given combination of Public Suffix + Domain (a 'registered domain')."

Do you have a source?

I do not believe this is true. That rate limit applies to second-level domains and all subdomains.

This is not true. I know from experience.

See the first point in https://community.letsencrypt.org/t/rate-limits-for-lets-enc...

Set up my first let's encrypt just a couple days ago. Was incredibly painless to then go add some subdomain certs.

Here's hoping for wildcards some day : )

Just to be sure, are you aware you can supply an infinite amount* of subdomains to be signed? If you need a finite and determined set of subdomains, that's totally possible.

* Well, I'm sure there's a limit, I just heard it's more or less unlimited.

Edit: A bit further in the thread I read a limit of 100 per cert, except you can only register or renew a few per day. Never mind that being unlimited, then.

Do their certificates still expire in only 90 days? That makes them very unappealing to me :/

Edit: I understand and agree on why they made it like this. But automating it is not an option in my use case, oh well... I agree it's for the better in the grand scheme of things :).


I think they do that on purpose to get people to automate the certificate renewal. Their default client of course messes with all sorts of configuration to make auto-renew work "out of the box".

Many people (myself included) aren't fans of their client getting so much access, but there are other clients out there that don't need it. I use acme-tiny[0] in a small shell cronjob once a month. It lets acme-tiny request a renewed certificate. Then it checks that the new certificate is valid, copies it to the right places and reloads the relevant services.

Honestly, I couldn't be happier about not having to manually change certificates again.

[0] https://github.com/diafygi/acme-tiny

Stop spreading FUD: it does not "mess with all sorts of configuration".

_Renewal doesn't touch any config files at all._ "letsencrypt-auto" puts the certs/keys under /etc/letsencrypt/keys. On renewal, new files get added. Old files are never touched. /etc/letsencrypt/live contains symlinks to the most recent files. Your webserver config uses these => its config does not need to be changed for renewal.

What you're talking about is only the initial certificate installation with "letsencrypt-auto run", and it makes a very targeted change in your Apache config. Use etckeeper if you don't trust it. If you still don't want that, use "letsencrypt-auto certonly".

(Note on server restarts: It also supports multiple methods, one of which is the webroot method, with which letsencrypt-auto does the challenge by putting a file under .well-known/acme-challenge/ of your webroot and lets your webserver handle the request, so it doesn't need to restart/replace your webserver itself.)

And about all these "minimalistic tools": I've seen one that literally did "new-cert.sh > $cert-file". If it failed (e.g. due to ratelimit, no internet connectivity, ...), it would null your old cert! Written and used by very smug people.

It wasn't intended to be FUD. The letsencrypt client needs to change the configuration of other services. This is a fact. Not everyone is happy about that, so I pointed out an alternative.

If you're happy with the official client, by all means, use it! There's nothing inherently wrong with that approach, it's just not compatible with the way I and some others prefer to do things.

EDIT in response to your edit:

> And about all these "minimalistic tools": I've seen one that literally did "new-cert.sh > $cert-file". If it failed (e.g. due to ratelimit, no internet connectivity, ...), it would null your old cert! Written and used by very smug people.

Absolutely, the minimal tools are not for people who don't know what they're doing. You absolutely would not run acme-tiny for example with write access to your actual cert that the web server is using, because any number of failure scenarios would result in downtime. That's why I specifically addressed that in the initial post you're replying to when I said: "Then it checks that the new certificate is valid, copies it to the right places and reloads the relevant services".

> The letsencrypt client needs to change the configuration of other services. This is a fact. Not everyone is happy about that, so I pointed out an alternative.

No, it doesn't NEED to. It's the most commonly discussed option, but it is not necessary. It can do the exact same "write to a folder in the webroot" mode most of the alternatives use.

(I'm not saying that there is no reason to use an alternative client, but that's not it)

The official letsencrypt client never touched any of my config files, it doesn't have to if you prefer to do it yourself.

> Stop spreading FUD: it does not "mess with all sorts of configuration".

It does more than you'd expect, IMO.

> letsencrypt-auto is a wrapper which installs some dependencies from your OS standard package repositories (e.g. using apt-get or yum), and for other dependencies it sets up a virtualized Python environment with packages downloaded from PyPI.


I was certainly a bit surprised when apt-get ran.

As said by others if you run it with certonly it doesn't touch the config at all. My cronjob contains a

path/to/letsencrypt-auto certonly --webroot --renew-by-default -w /var/www/letsencrypt/ -d example.com

and puts the signed certificates into /etc/letsencrypt/live/excample.com/fullchain.pem . This is followed by a service nginx reload

I did not trust their automatic configuration as well so I simply configured nginx to use the keys + cert and to serve .well-known/acme from /var/www/letsencrypt/ for all my domains.

That's all. It works quite fine and if something does not work (e.g. python breaks.) such that the renewal is unsuccessful. LE will send you an email in advance (I think 30 days) so you have plenty of time to look after it.

I don't think its fud. Calling apt-get is just crazy on my view.

I haven't fully automated mine yet, but I get alerts when any of my certs are getting close to expiry and I just have to run "/etc/letsencrypt/process.sh" now and it handles everything automatically at that point.

I'd rather run that script manually 4 times a year than go through the pain of renewing all of my certs by logging in to websites and pasting CSR's and Certs around every 1 or 2 years.

Once I'm comfortable with the process I'll just cron it and forget about it.

Don't forget this[1] gem which is my favorite way to use letsencrypt. It will let me run it by cron (or periodic on FreeBSD) plus I can have my own post-run script that takes my certificates and keys and puts them in the format I need for Hitch (SSL termination for Varnish), push those changes, restart the service _inside_ a FreeBSD jail automatically.

It's advanced setups like this where LetsEncrypt fails out of the box, but it's nice we have tools like this at our disposal now.

[1] https://github.com/lukas2511/letsencrypt.sh

You're supposed to automate renewal.

Since v0.4.0 all it takes is a "letsencrypt renew && apachectl graceful" in a daily cronjob (or, preferably, systemd timer), it handles the rest. Tweak as you like.

Assuming you use Apache. For many, it's simply not a fast enough web server without reverse proxies in front of it.

Still crossing fingers for full nginx support soon.

And, of course, there's other services than web servers that benefit from LE certificates. Mail, FTP, chat, etc. …

No, actually not.

"letsencrypt-auto renew" uses the same settings you've used with "letsencrypt-auto run/certonly". If you're using nginx, that's probably the --webroot method. Which works for renewals too.

I don't know, I don't want letsencrypt to touch my config files. It just works fine without that "magic" anyway if you're willing to add a few lines to a config file.

I agree, but i think the LE target audience is not you. Their whole thing is to be easy and use the "magic", to get the people who don't want to buy a certificate or deal with the config files, onto good encryption. I'm their audience and now my low-power volunteer run FM radio station website has HTTPS with a recognised CA.

If you use the letsencrypt python client with "certonly --webroot", it will never touch your config files at all. You can add "-n" to make everything non-interactive and command line-only.

If you use letsencrypt with "certonly --apache" (or --nginx, when the nginx plugin is released) it will make only transient changes to your config in order to obtain the cert, and then restore it to the original state before exiting.

If you use letsencrypt with "run" (which is the default command) it will make config changes if those appear to be necessary for installing the cert.

One challenge we've had is how to design the command line interface to ensure that the users who want maximum automation get it, and the users who want maximum manual control also get that. Both set of behaviour are available.

Use webroot auth and it's fine with nginx. I just ran my first set of renewals with half a dozen domains on nginx. All fine apart from one which hadn't used webroot when I first set it up. Edited the config and it then worked fine.

Be sure to have a script that checks the results of your cronjobs, though:

"It is possible to hit the rate limit using letsencrypt renew and have it fail or partially fail for that reason."


They launched with 90-day expiry but without a robust renewal process.

True. Although if you run it daily, you'll have multiple opportunities for the renewal to go through before it actually expires. It'll survive a couple of unsuccessful tries in the default/recommended configuration, at least if I'm understanding everything correctly.

I understand and agree on why they made it like this. But automating it is not an option in my use case, oh well... I agree it's for the better in the grand scheme of things :).

Since v0.4.0 all it takes is a "letsencrypt renew && apachectl graceful" in a daily cronjob"

I'm glad your setup is so simple.

May I point you to the awesome Caddy server of Matt Holt [0]. It automatically obtains and !renews! lets-encrypt certificates.

[0] https://github.com/mholt/caddy

Go get a free 3 year cert for up to 5 domains from WoSign then.


>"automating it is not an option in my use case"

Then you're doing it wrong - there is no reason you shouldn't be able to automate it that I can envision

There are valid scenarios. Placing a certificate on something like an F5 or Citrix VPX appliance pretty well forces you down the email verification route.

Then you've got those appliances that take a power cycle and 30 minute outage to install such a certificate. Five year certs are very attractive for this situation.


Given that LE does certificate transparency, would it be possible to find out what their millionth certificate was?

CT doesn't seem that transparent. crt.sh only shows the certificate for one of my domains, despite them all having certs issued by the same CA on the same day. Go figure.

I'm assuming we're talking about CAs other than Let's Encrypt? In which case this is expected; not many CAs currently submit all their certificates to CT logs. It's only mandatory for EV certificates. The biggest source for Google's CT log servers is probably Googlebot, so unless your site is publicly available and crawlable, this is nothing unusual.

Interesting. Are you comfortable with mentioning the domain name(s) here?

And for the record, here is the millionth LE cert in all its glory: https://crt.sh/?id=14392504

> Are you comfortable with mentioning the domain name(s) here?

Not to just anyone, no. The certificates aren't all in service for HTTPS, which might explain some of it, but I don't know.

Super! Just set up my first secure website with Nginx.

Absolutely simple. Literally the only way it could have been easier is if letsencrypt had been installed on my Centos 6.7 box but it was only a `git clone' away.


1) Stop the web server.

2) ./letsencrypt-auto certonly --standalone -d _my_domain1_ -d _my_domain2_ ... At the curses prompt give it your contact email address, and accept the licence

3) Edit nginx.conf - Change all listen 80s to listen 443s. Add the following commands

   ssl_certificate /etc/letsencrypt/live/_my_domain_/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/_my_domain_/privkey.pem;

   # bump up protection

   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers on;
4) Start the web server

5) Doh! Go through website changing hardcoded http:// links to protocol (scheme) relative links // See here: https://www.paulirish.com/2010/the-protocol-relative-url/

6) Restart the web server


Ok. It's doesn't seem that simple now that I say it but it was easier than wrestling with Apache and rewrite rules :)

I had no experiance with Nginx and doing the 80-443 redirct was pretty simple.

server { listen 80; listen [::]:80 ipv6only=on; server_name www.mydomain.com; return 301 https://$server_name$request_uri; }

Their certificates over time graph looks hockey stick-ish. Very good sign :)

How useful is this for a home server where there is no domain name registered? Can it be configured for my local secure web server?

You mean getting a CA-issued certificate for a host name like "myfileserver", without a domain name? No, if that were allowed, you could use that globally trusted certificate to go play man-in-the-middle on somebody else's network which also happens to have a "myfileserver".

In general, certificate authorities should only issue certificates with unambiguous subjects.

Of course, if you don't need a certificate that is automatically trusted by everyone, then you can still generate a certificate yourself, without the help of a Let's Encrypt or any other CA. You would have to configure the machines on your network to trust it though.

You need a domain name registered. Otherwise what would they issue the certificate for? You could buy a domain though, then have a local dns resolve it to your own machine.

Alternatively you could use a self signed cert and sign it to localhost or whatever, then configure all your browsers to trust this certificate.

Is it possible to do without Chrome complaining about the validity of the self signed cert?

If you have a registered domain and get a DV cert from LE or anywhere else, chrome will not complain about the cert. If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device.

> If you self-sign it, chrome, or any other browser, will complain, unless you add your own CA to the trusted list on each device.

You say it like "any browser will complain unless you modify the device", but in Firefox you can just add it to the local trust store. They manage their own so that works just fine.

Many applications actually allow you to permanently accept a certificate (heck, SSH) which then alerts you if it changes. It is actually reasonably secure if you aren't on an insecure network the first time around. Just Chrome keeps complaining annoyingly.

> Otherwise what would they issue the certificate for?

A subdomain of something like DynDNS or just your IP address. I know you can't for good reasons, but I'm just saying, it would make sense if you never heard it's for domains only.

DynDNS works fine. CA/B Baseline Requirements (which all trusted CAs have to follow) forbid issuance of certificates that include internal names. Whether you actually bought the domain or just have control over a subdomain (as with DynDNS) doesn't matter.

As long as the domain is on the Public Suffix List (which should be best practice for DynDNS providers), you don't even have to worry about rate limits.

AFAIK, certificates for non-reserved IPs would be allowed. Let's Encrypt doesn't support that, however. I imagine proof of ownership would be harder to demonstrate for an IP address (compared to a DNS name).

> As long as the domain is on the Public Suffix List

Oh, cool, I did not know that this project included stuff like DynDNS! I thought a normal, paid domain was the only way to go (other than dot tk).

> AFAIK, certificates for non-reserved IPs would be allowed.

Many IP addresses are dynamic though, I know of no CA where you can register an IP address and I'd imagine it being for that reason (and it might be CGNAT and perhaps some other reasons). You can of course self-sign one with an IP address, but I don't expect any CA to sign those.

I host many small sites on a $10/month shared server with a typical LAMP stack host. Unfortunately, SSH access is limited so I keep running into issues getting Let's Encrypt running. Has anyone else run into any issues? Not looking for step-by-step help, just wondering if I'm alone.

I have seen paid software promising to solve this [0], but I'd rather not pay to get a free certificate.

[0] https://letsencrypt-for-cpanel.com/

I'm one of the developers of that paid plugin. We developed it primarily for my day job (as a web host, SSL is one of the worst support burdens for us), but it's been really successful for other hosts as well.

The situation certainly sucks for shared hosting customers who do not have access to LE. However, cPanel have stated that they will be delivering the functionality as an out-of-release plugin between 11.56 and 11.58.

If you don't want to pay, I suggest taking a look at one of the dependency-free, root-less tools, such as acmetool[1]. You should be able to plug this into your crontab without any issues. Depends how limited your SSH is, though.

1. https://github.com/hlandau/acme . Great tool. Unfortunately the official Let's Encrypt client tooling is really quite poor. Python was not a good choice (way too many dependencies get pulled, esp. for such a simple ops tool, messed up situation with 2.6/2.7/3.x availability across Linux distros).

Get a shared host that supports Lets Encrypt, there are many.


Crocweb is missing from this list.

First of all, I love this.

One nagging thing in my mind, though, is how easy it seems it would be for a Three-Letter Agency to backdoor LE to pieces. Then again, I guess that's nearly just as true for any CA out there.

(I don't mean to pooh-pooh this useful service! And, if there's any interloper-mitigation going on that I don't know about, I'd be happily put straight!)

Certify for Windows IIS with autorenewal https://certify.webprofusion.com/

What are the benefits of using LE over Cloudflares HTTPS?

End-to-end security - even if the path between the client and CF itself is secure & authenticated, you need a valid cert (like from LE) to secure & authenticate the path between CF and your server - what they call "Full SSL (strict)."

LE is okay but the 90 day limit puts me off. It's so much easier to do a self-signed for 10 years. The problem with self-signed certs isn't intrinsic to them, it's a problem with browsers scaremongering for the lowest common denominator.

For my mail server which only I use, my websites which only technical people visit, etc, there's no reason to deal with the hassle of LE.

Absolutely. Browser warnings actually make it sound like unencrypted connections are preferable.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact