You may also want to try alternative client from https://github.com/kuba/simp_le. It can be easily dropped into crontab and renew certificates when necessary.
Disclaimer: I'm the author of simp_le and developer of the official client :)
Disclaimer: I'm the author of simp_le and developer of the official client :)
edit: Was mostly thinking about smartcards, etc. Honestly, since most of the crypto operations can be performed by OpenSSL, I guess the account key can already live on any device with PKCS11 support.
In general, official client tries to do too many things at once. In the result, the code base is huge -- too big to be easily audited; it's also proven that it's likely to have a lot more bugs. On a similar note, letsencrypt-auto, the default installation method, pulls in Apache plugin with all of its dependencies. And so on, and so forth...
At the same time standard modes of operation are well hidden and/or difficult to configure. For instance, running the official client without root is technically possible, but let me know how much time it took you to figure this out ;). Likewise, scripting is pretty much impossible, because the CLI tends to ask interactive questions... "webroot" plugin is probably the only plugin that could be made into non-interactive mode, and again you have to be knowledgeable enough to figure out all necessary flags.
simp_le tries to takes the best from the official client ("webroot" plugin -- not stealing, I authored that plugin myself) and adds some missing features that IMO should be the standard. E.g. you can just just put `simp_le --some --flags && this_command_will_be_run_only_if_cert_was_renewed_eg_restart_nginx` into your crontab -- this mode of operation is simply not possible with the official client.
NB You can also turn simp_le into a standalone binary (~8MB) using built-in PyInstaller setup [1] and distribute to your machines without having to install any dependencies (even Python) :)
I hope that answers your question. You can also catch me on #letsencrypt, or better yet #simp_le (both at Freenode).
[0] https://github.com/kuba/simp_le#manifest [1] https://github.com/kuba/simp_le/tree/master/pyi
Anyway, you have a new user! :)
(I'm just amazed that LE decided to try modifying webserver config files automatically. There are soooo many ways for that to fail. It's going to take an immense amount of programmer effort for very little gain.)
We're at a stage where people are capable of developing a web application but creating a (suitable) private key, generating a CRL and then using the resulting certificate in Apache is currently beyond their capabilities. Which is kind of cool in one sense but kind of scary in another.
For people who can SSH and install packages, I think they are better served being shown how to add couple lines to make SSL work than some magic that could screw up their web server config. After all, these people chose to learn how to login to the web server instead of just managing their site from a CMS. They would probably like to learn how to configure something like SSL.
You'd be surprised I think.
>They would probably like to learn how to configure something like SSL.
I think you'd be surprised again. It's not even always about aptitude–quite often it's just laziness. The reason that many of these people aren't encrypting today is because they don't want to invest the time and effort. "My copy-pasted openssl commands didn't work? Eff this."
Operations is as much a mindset as it is a skill. Some developers have it, some don't.
Having to script that with symlinks is nothing I can't do, but something that sucks a bit. Otherwise the crontab would not even need to call a bash-skript wrapping that stuff, it would be just your client with proper parameters. I'd much prefer that.
EDIT: Never mind, figured it out, I can just run the simp_le script directly from the venv directory.
This is around-about way of saying that 90 days was a well-thought out duration to issue a cert and the process of renewing it manually is there as a positive (rather than passive) confirmation you retain control. These guys are doing a public service, on par with archive.org and the EFF. I'm not sure, but even though I've been using cron since before I was a teenager, I'm not throwing that entry in.
Edit: Whoops, so I was half-wrong, mea culpa. https://letsencrypt.org/2015/11/09/why-90-days.html Part 1 addresses the security issue I brought up, and part 2 endorses automation. My mistake.
They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenience than longer ones.
Doesn't support IIS at all
IIS is ~12% of the market, and they were able to catch 78% already.
They've always said, they're working on a basic version to get traction, and improving it from there.
> Wants secure webserver
> Uses IISI'd also contend that 90 day expiry makes end-users less sensitive to certificate change notifications; at present if a website renews its cert after a year I receive a pop-up and I pay attention. Receiving one every 60 days will just condition people to start ignoring cert changes, whether valid or not.
I personally no longer use it because of all the noise, even before lets encrypt.
I believe these are sane defaults.
* Prompt on CA change? (Default Yes) * Prompt on private key change? (Default No IF the cached certificate is on the old CA's revocation list.) * Prompt on CA renewal? (Default No)
sure? A new key provides quite a bit of security benefits because even when the key got loose without you noticing, three months later, it won't be usable any more when the new cert is made for a new key.
Of course, if the certificate changes to an untrusted one, the browser should flag it -- and if the server specifies HSTS, then the browser should block the user from clicking through anyway (increasing the pressure to make sure the cert is always trusted and unexpired).
LetsEncrypt does domain validation only so there is zero check who owns the server. So no, that makes no sense. You can already crontab the official client anyways.
For the most part certificates have never provided this guarantee. What they do guarantee is that A) the entity you're communicating with is in control of the private key and signed certificate that you expect B) your communication with that entity is secure from a man in the middle attack. And mostly B if you're visiting the site for the first time.
I mean, that's the goal. But we're a ways off.