Hacker News new | comments | show | ask | jobs | submit login

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 :)




The biggest usability challenge for me is that each crypto tool uses its own key store. kgpg, ssh, yubikey, openvpn, etc. Do you foresee allowing your client to pick up the private key from a smartcard like a yubikey? My goal is to centralize all the certs in a place that I will always have access to - and not have a different passphrase for each cert (which I will forget) or 1 passphrase for all certs (even worse). 1 passphrase for my cert-store (the yubikey) but which contains all my certs.


I could be wrong but isn't Let's Encrypt more oriented towards securing servers?


Lets encrypt is for helping servers offer ssl encryption to people for free.


Right, I get that. I've been looking through their code and the draft RFC here and there over the last few days (I'm considering using it for internal applications). He mentioned yubikey, pgp, and openvpn and it started to sound more like he was talking about a supporting client use cases. I can see the convenience in using a common client key but it seems more secure to keep things compartmentalized, particularly when it comes to mixing client and server stuff.


I could see wanting to store the Account Key on one of these devices.

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.


There are also StartSSL and WoSign, which provide the A+ certificates for free (see example WoSign domain audit: https://www.ssllabs.com/ssltest/analyze.html?d=checkmyping.c...)


What are the constraints on the official client that motivated you to author simp_le?


The primary difference is in the underlying philosophy. I encourage everyone to read the manifest from the main project site [0]. Most of the points are counteracting bad design decisions (IMO) made in the official client.

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


Thank you for your work on this project. It is exactly what I need. I don't want the main LE package, which is bloated and annoying to use. I love LetsEncrypt for what they're providing as a free service, but I think they're a little too ambitious from the start for their client. Start small.

Anyway, you have a new user! :)


Nice job! I found LE's client irritating to use as well. Yours sounds clean and correct.

(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.)


It's probably motivated in no small part by helping the type of person that's currently not encrypting their application/server and should be. TLS, certificates and PKI's are something a lot of people have a hard time with.

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.


That's exactly why we designed the client that way - we wanted to make it easier for people who have no idea how to add certs to encrypt their server.


People who have no idea how to add certs are also unlikely to know how to login to their web server using SSH or how to install a package.

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.


>People who have no idea how to add certs are also unlikely to know how to login to their web server using SSH or how to install a package.

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.


Webserver config modification has indeed taken an immense amount of programmer effort. It's actually pretty magical when it works well, and it's suprisingly robust, but it's still filled with horrible edge cases everywhere.


I don't understand the point of "not specifying output files". First: I just used your client and it worked, it is great work, thanks for that! But the one thing I did not understand was the -f options. Why don't you implement an (in my eyes much easier and common) interface of --output-key path and --output-cert path?

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.


Similar to the dependency issues raised elsewhere, I wrote this script largely because none of my servers run python:

https://lolware.net/2015/10/27/letsencrypt_go_live.html


Got an example of how to drop it into crontab? I'm not really a Python guy and it seems to only run under the venv which I'm not sure how to setup from a cron job.

EDIT: Never mind, figured it out, I can just run the simp_le script directly from the venv directory.


Thanks for this. I had the same problem!


Ehhhh, so I get why you made this, but at the same time, LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership. You actively performed an action that declared: hey I still retain control of this and it hasn't been compromised. (as opposed to other states your cert could be in -- abandoned, compromised, password forgotten and you were too lazy to get the cert revoked-- trust me, engineers made cron because we were lazy especially when it comes to mundane things).

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.


Actually, no: the default 90-day certificate lifetime was chosen such that it wouldn't be too inconvenient for manual renewal if necessary, but was intended to encourage automatic renewal: https://letsencrypt.org/2015/11/09/why-90-days.html


Let's Encrypt gives encouraging automation as a reason why they choose 90 days:

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.

https://letsencrypt.org/2015/11/09/why-90-days.html


> If we’re going to move the entire Web to HTTPS ...

Doesn't support IIS at all


There's been some efforts to support IIS, including a client for use with powershell.

[1] https://github.com/ebekker/ACMESharp


Most viable product.

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.



Hah thanks, I knew something felt wrong about what I wrote. :P


I think `Most` was quite adequate given the achievement though.


   > Wants secure webserver
   > Uses IIS


That philosophy is perplexing because system admins already have to manually handle things like software upgrades. Unlike SSL renewals, upgrades usually occur to an arbitrary frequency yet admins seem to be able to cope.

I'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.


What? No browser displays a notification when a website changes its cert. It doesn't even show you a notification if it changes its key, that's the whole point of key pinning: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... (A pin failure results in a non-bypassable HTTPS error: https://projects.dm.id.lv/Public-Key-Pins_test )


The most popular way to get that is: https://addons.mozilla.org/en-US/firefox/addon/certificate-p...

I personally no longer use it because of all the noise, even before lets encrypt.


The end users should ideally not be prompted when they see a certificate renewed by the same CA. It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well. Of course everything could be tuneable.

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)


> It should also ideally be a /renewal/ of the old one, and not an entirely new private key generated each time as well

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.


There's a browser that gives certificate change notifications by default?


Users should be able to safely ignore certificate changes. No one should need to install Certificate Patrol to have a safe experience.

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).


How do you decide whether the new certificate is genuine, other than it being issued by a valid CA?


Maybe the message could be hidden if the new cert was signed by the old one?


> LetsEncrypt intentionally chose 90 days for the duration of the certs. Presumably because renewing a cert is a positive confirmation that you still retain ownership.

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.


>hey I still retain control of this and it hasn't been compromised.

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 get your point, but what sysadmin doesn't want to script everything?


You can't script everything. Otherwise, we'd all be at the beach drinking mojitos checking Slack to see how the bots are doing.

I mean, that's the goal. But we're a ways off.


We are all at the beach and were just wondering where you were!





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

Search: