Looking through the code and the issue tracker (https://github.com/letsencrypt/letsencrypt) I can't help but think they are approaching this wrong... In an attempt to make the certificate install completely hands off and fully automated, they are baking in a tremendous amount of complexity on top of a fundamentally brain-dead simple process.
I need to generate a private key, send you the public key, and get you to sign it. Somewhere in there, I need to prove I have control of the HTTP server on the existing A record, or that I can add a DNS TXT.
I can't say I'm a fan of shipping a SimpleHttp server baked into the tool, listening on port 80 (so run as root) which is also trying to deal with account authentication at the same time as generating the CSR, scanning directories of private keys to try to figure out how to sign the ACME nonce, etc. Getting this 'letsencrypt-auto' process to be able to receive and respond to HTTP requests on my domain is a different class of problem than getting a specially crafted file into a specific path on my domain. The former is clearly much more difficult in production than the latter....
Why not simply a script which;
- Takes as it's input the CSR and privkey files
- Does an HTTP GET to retrieve the ACME nonce
- Sign the nonce, generate the file you need to put on your webserver and tells you
the path to put it.
- Prompt to 'Press ENTER once the file is in place...'
- HTTP GET to indicate file is in place, server verifies, and returns the completed
full-chain cert.
(An optional parameter with a path to copy the signed-nonce file would make the script non-interactive.)
This could be written in a few lines of bash, right, assuming you could find an openssl command line which could sign the nonce in the correct form?
Keep in mind you have to repeat this process every 6 months with your live site, so what we want are simple composable / pluggable tools which don't try to own too much of the overall process, right?
Alternatively, ship two separate scripts (le-verify, le-certify) which create the ACME validation file and retrieve the cert once the file is in place, respectively.
I'm also not quite sure, why is there any concept of a user account on letsencrypt at all? Hopefully it is optional, I don't see what in this process requires that I register an "account" with them?
It takes a CSR and user public key as input. Then, it prints the signing commands you need to run (so it doesn't have to know your private keys). Then, prints the command you need to run on your server. Finally, it prints your signed cert. Enjoy!
The official Let's Encrypt client is aimed at an audience that doesn't know what a CSR is. For those that do and just want their free certs, I wrote this script to them to get their free certs without having to trust any client.
Thank you for writing this alternative program and quickly responding to help in the issue tracker. This program's workflow feels much more pleasant for an admin who knows how TLS works.
Is it possible to serve a text file on the existing server rather then taking it down for the python web server?
Sweet! The part where you generate the code to run the HTTP server... can that also be done by generating a file which you copy to the existing server's root directory?
Wow, ACME protocol seems way over-designed for what was actually required.
The client has a "manual" mode as you describe, but it's practically undocumented right now. It lets you create the certificate on any machine and leaves serving the verification file up to you.
I do hope they polish it up or at least properly document it for the launch.
My guess is that in the future distro/OS maintainers will just incorporate this into the as normal packages. I signed up for the beta, but was bummed that it's not yet supported on OpenBSD. I thought I would implement it, but because of dependencies that don't support OpenBSD(psutil) I couldn't.
I commend their efforts, and I'm sure this will get more people to deploy TLS. But I don't think we're the intended audience of their auto client. I just want a key that's signed, and like you I'm not willing to let soem script touch my configs. My Apache configs are highly customized, so they'd probably break anyways.
I thought at least part of the point was eliminating the cost factor with strong crypto controls on the backend on a widely accepted CA with a sane process for validating ownership (ACME).
There is a case to be made for ease of use, but I don't think they are broadening the horizons for TLS by making it as easy as "sudo letsencrypt -d www.example.org auth". Because 9 times out of 10 when you enter that command the first thing that will happen is 'port already in use'. Now what, shut down the production server? Or, trust this [1] to parse and edit my config files directly?
Now, tell me they created a Wordpress plugin which you install, activate, and magically you now are running TLS, and I am 100% with you. That's a package which makes 100% sense to me. But there's no 'git pull' or 'sudo' anywhere in there that an end-user would see or have any clue about.
If the person installing or renewing the cert is trying to decide, what should I type here...
user@www:~$
Then I think the answer is not what they are currently shipping. Give me a tool which lets me generate the ACME validation file, and then a second command to pull the cert once the file is in place. Two bash scripts which don't even need 'sudo' to run. Save the "full automation" for things like Wordpress plugins, not the shell.
Requiring the script to be run as root is a design decision, and I highly doubt it will be changed. They use the fact that the script is able to bind a privileged port (80) to prove it's being run as root so that chaos does not ensue in shared hosting environments.
I would agree the level of automation which the tool currently exerts (and the potential for resultant chaos) is definitely a good reason to require root privs by design.
I'm sure that they do not feel like the level of automation imposed by the tool is somehow a necessary component of the validation before they will generate a certificate. Certainly, there is no cryptographic value, because their tool doesn't do anything special, so there's no proof or requirement you actually run this particular tool. On their side they make the request for the validation file on the domain root on port 80, but the particular machine being controlled may be, in turn, replying to a request on a higher port.
The pair of bash scripts I would want to use each simply create a file in the CWD, so they cannot possibly cause chaos, and therefore I think most would agree can be shipped without imposing (artificially or not) a sudo requirement.
If they think that being fully automated is the main reason why people are interested in them they are mistaken. Top two reasons seem to be that they are free and that there are no usage restrictions.
I personally don't want a fully automated process. Shutting down all my virtual hosts to let their tool pretend to be my server is a big NOPE.
You can specify the web root of the domain you are trying to validate using the webroot plugin, meaning that you do not have to stop your current HTTP server or run another one, it just adds the verification file to your website's root.
The "turn off server while it generates certificates" was indeed the one surprise in the process for me (while the rest was quite straightforward, kudos on that).
What I wonder is why it has to be port 80, not another port ?
Yeah this is the bizarre part of this whole enterprise.
The core and biggest problem here is getting valid certificates for free. That enables the process for people who are interested, and means those people can go on to make everyone else aware of it, which raises the amount of crypto in use overall.
Sorry. I didn't keep detailed records of the comments I've been reading about let's encrypt over the last half year or so. :)
But I've noticed that most people were happy about free and no restrictions while the automatic part mainly just got how is that going to work and will it screw up my server comments.
I think that is the techie HN echo chamber effect.
I have spoken to lots of people (Yay! More anecdata) about the idea of lets encrypt (Business people with small websites) and the "automatic" bit was very much a plus point.
The ones I know of run their own servers for small things like wordpress blogs, small magento e-commerce installations etc.
To be brutally honest, they would be better off with a hosting service to take care of things since SSL is not the only issue they have and they lack full-time techies.
The official client is intended to have a simple mode as well as a "full-service" mode. That said, our client is never going to be ideal for everyone. We'd be happy to see others create clients that work well for them!
We'd also like to see support for Let's Encrypt built in to servers, so a separate client isn't necessary. That would really allow for the best, most seamless user experience.
What was the thinking behind the decision to require the tool to run a server on port 80, It's not unmanageable, but having to kill my web server to get new certs seems an odd decision to make.
But it's wrong to build an giant automated system. Had we completely forgotten the UNIX way?
Build a (letsencrypt-nosudo) first. Let it do one task and do it well - obtain a signed certificate. Let it have the simplest interface possible - command-line options and exit status with stderr output for details. Make it fast, small and robust and that'll be pinnacle of usability for those gray-bearded old-fashioned sysadmins.
Then build letsencrypt-magic-pixie-dust that'd use the said script to obtain a certificate and then bake cookies, feed the pigeons and wreck your webserver configuration as it seems fit. Let it still have command-line options as the only UI.
Then build letsencrypt-ui-{cli,gtk,ncurses,qt,android,wpf,whatever} to control that beast, so even a non-techie grandma could be able to get everything for her blog in a single tap.
Why bundle all this in a single giant monolithic[1] project is beyond me.
___
[1] Not in sense of internal stucture, but in sense of how it's facing the end-user. And AFAIK there's single bin/letsencrypt (and letsencrypt-auto shell script wrapper)
It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply ignored important parts of the HTTPS deployment task.
But the traditional UNIX philosophy has not been working well for TLS to date, and certificates are hard to do right in a simple way. If every web developer and sys admin needs to know about the following things:
- how to get a cert from us
- how to bind a privileged port (:80 or :443) or reconfigure a webserver to prove domain control
- the difference between end-entity certificates, CA certificate chains, "combined" end-entity and CA chains, and the weird heisenbugs you can get by getting them mixed up
- how to handle the need to renew certificates periodically
- the HTTP secure cookie flag
- the HSTS header
- redirects from HTTP to HTTPS
- the Content-Security-Policy: upgrade-insecure-requests directive
- OCSP stapling
- the tradeoffs involved in ciphersuite tuning
Then we are never going to have a universally encrypted and secure Web.
So we set out to build a client that will, as it matures, get all of those things right for you. Meanwhile, the Python client does support console-only (-t) or non-interactive (pass in flags to avoid all questions) modes of operation.
As we get to a 1.0 release, we expect those modes will be more robust and documented / discoverable for those who want them. But we think that many web developers will be happier to not have to know the difference between a cert, a cert chain, and a full chain.
> Keep in mind you have to repeat this process every 6 months
Actually every 90 days and they're talking about reducing that cert lifetime further still so as to encourage use of the automated tool.
No way am I going to run a root tool in production and the alternative of manually running it for every server every 60 days or whatever is infeasible.
A good concept made unattractive through pushing a mandate.
>Keep in mind you have to repeat this process every 6 months with your live site, so what we want are simple composable
It's just a script that must be run as specific user from specific directory, don't see a reason why it can't run from cron.
> why is there any concept of a user account on letsencrypt at all? Hopefully it is optional, I don't see what in this process requires that I register an "account" with them?
I got accepted to beta tests last week, I got allowance for 4 domains, 3 of which are public, one is commercial, one for my blog and one for ownCloud. They run on HTTPS TLS1.1 and TLS1.2 only. I didn't even know there are accounts.
> Keep in mind you have to repeat this process every 6 months
Renewal and revalidation are not the same process. Unfortunately they're thinking about making the revalidation period 90 days as well. That would suck as I have several sites where the content is generated by a script which would have to be disabled to serve a file.
I've documented how I got it working for my site last night (using manual mode to explicitely specify the domain names), including the dhparams step you'll need to get the A+ rating with ssllabs:
https://gist.github.com/cecilemuller/6d70cb4f463d8a391db1
I used their docker container in manual mode and the whole process was a great experience. No need to stop the main server. The steps were:
1. Run the container without ports in manual mode
2. Use the GUI to enter account data and URLs for the SAN certificate
3. Let the client print out the challenges
4. Copy the challenges to the webroots using the provided command
5. Press ENTER and wait a few seconds. Certs and Keys are ready to be linked from the webserver.
Everything went as expected and I am a happy user of letsencrypt.
You can technically use TLS with anything. All the certificates give you is a trusted 3rd party that authenticates that a domain is what it claims to be. So if you want that authentication for your NAS domain name, then of course.
Eric (a Virtualmin employee) has been experimenting with Let's Encrypt for some time, and, as I understand it it is possible to setup manually without any extra hoops imposed by Virtualmin (which is usually the case, as Virtualmin does things in a very standard way, by design). We have plans to include support in the very near future; not the next release, which is coming in a few days, but soon after.
Nothing should prevent you from setting it up manually, but it will be available easily in the near future, as well.
Edit: I just talked to Eric. The official client has historically required extremely new Python versions (newer than any Linux distro for servers ships with), but that's recently been fixed. I think Jamie was already working on implementing our own client, however, because of that problem, so we may end up shipping our own client. Regardless, it'll soon be supported by Virtualmin. We're as excited about it as anyone.
Probably. Jamie will determine the UI for it, but it'll probably be as simple as turning it on for the domain. Validating the certificate requires either an addition to DNS or to the web root directory; so the domain will need to have a valid glue record, but otherwise Virtualmin will be able to do all the work.
And, it does look like Jamie will be implementing a client for it within Webmin, so we won't need to add the ACME Python client and its dependencies to make it spin. A nice side effect of that is that Webmin alone will also be able to use Let's Encrypt, instead of a self-signed certificate for Webmin itself (of course, people who have purchased certs can use those for Webmin, but if you have dozens or hundreds of Webmin systems, it'd be silly to figure out certs for all of them; even a wild card cert would be a nuisance to deal with).
What I also don't like is that its python.
Nothing against python, however it's really aweful that I need to somehow distribute that files either via tar.gz, unpack install the requirements, etc..
I think a static binary would've been way better, ie. rust, golang, c, c++. even a simple *.jar file would've been better, however that comes with another cost.
I need to generate a private key, send you the public key, and get you to sign it. Somewhere in there, I need to prove I have control of the HTTP server on the existing A record, or that I can add a DNS TXT.
I can't say I'm a fan of shipping a SimpleHttp server baked into the tool, listening on port 80 (so run as root) which is also trying to deal with account authentication at the same time as generating the CSR, scanning directories of private keys to try to figure out how to sign the ACME nonce, etc. Getting this 'letsencrypt-auto' process to be able to receive and respond to HTTP requests on my domain is a different class of problem than getting a specially crafted file into a specific path on my domain. The former is clearly much more difficult in production than the latter....
Why not simply a script which;
(An optional parameter with a path to copy the signed-nonce file would make the script non-interactive.)This could be written in a few lines of bash, right, assuming you could find an openssl command line which could sign the nonce in the correct form?
Keep in mind you have to repeat this process every 6 months with your live site, so what we want are simple composable / pluggable tools which don't try to own too much of the overall process, right?
Alternatively, ship two separate scripts (le-verify, le-certify) which create the ACME validation file and retrieve the cert once the file is in place, respectively.
I'm also not quite sure, why is there any concept of a user account on letsencrypt at all? Hopefully it is optional, I don't see what in this process requires that I register an "account" with them?