> Now you've still got a hurdle to overcome. In order for nginx to serve out the right certificate chain, you'll need to bundle the intermediary. So you should wget that from The official Certificates Download page.
A small suggestion - instead of wget-ing the certificate chain from the page, I would use the cert-chain-resolver tool[0]. It's super simple, but highly effective bash script that wraps around OpenSSL / wget and does all this for you.
Had the author used the official tool, the chain would be automatically downloaded. [0] Additionally the author is over-weary of the official tool complaining it modifies server conf files. In fact the default option recommended to beta users, './letsencrypt-auto auth', simply downloads the certificates and doesn't touch conf files at all.
Note that "set -e" doesn't work in subshells so you have to be extremely careful if you make complex subshell commands or write set -e in every subshell too.
I used the options you mention before, however I found it highly unreliable. I have replaced them with better manual error handling and tests. Please review the latest code. I'm looking forward to any reported issues.
Also I'm going to rewrite it to a different language, Shell was really just a quick hack. Probably in C. I want to keep it minimalistic in dependencies.
Let's Encrypt is already very easy to use, but for those looking for a totally transparent way to use it, keep an eye on Caddy. It's a web server with Let's Encrypt built in to serve HTTPS by default: https://caddyserver.com/blog/lets-encrypt-progress-report - no extra tools or configuration needed.
Probably would be a better ideia, in terms of software reusability and security, to put a lets encrypt module on apache or nginx rather then put an apache or nginx module on lets encrypt.
There's a certain amount of back-and-forth involved in getting a domain-validated certificate. I say to the registrar "I want a cert for www.google.com" and they say back "Prove you control www.google.com by putting this file at www.google.com/yes-give-the-cert-to-michaelt.txt" then the registrar retrieves that file.
You also have to generate the private key in the first place, get the URL in the right field in the CSR, send the right file to the registrar (don't accidentally send them the private key!), convert between the dozens of file formats (.pem .crt .cer .key .der .p7b .p7c .pfx .p12 .jks), add the right intermediate certificates, put the file in the right place, make sensible cipher selections, set your file permissions right, make a secure backup of your key, check it works in several browsers and OSes - and repeat the whole process in a year or two when that certificate expires.
In the all-encrypted http2 world of the future, it would be better if the web server just took care of all that the first time it was started - just like a Linux server automatically generates a SSH private key at first boot.
And another small note in regards to CSR: typical CA today uses the CSR only to get public key you want to have signed and replaces everything else with whatever they deem correct.
Did a CA once accidentally sign a raw CSR that requested to itself become a CA? It seems like I remember something like this, but I couldn't find evidence. Anyway, that's one reason for the CA to be very careful what values it pulls out of the CSR.
One small note on HTTP/2: The TLS requirement never reached consensus in the working group. HTTP/2 implementations are free to add or remove the requirement.
A big part of the reason is that free certs exists already (startssl), but it takes A LOT extra work to set it up.
The whole point here is that eventually the deployment tool can be integrated in existing server software, such that when you set up your server on your domain, requesting a certificate can be an automatic step that the sysadmin and web developer don't even have to think about.
This makes sure encryption will eventually be deployed by default everywhere, because it is literally easier than not to.
Nitpick: not for businesses. If you're asking for a certificate for anything that they may suspect has slight relation to any commercial activity, the request will be denied. It may be accepted by chance, but that's unreliable.
Companies who don't want to pay currently have only single option - WoSign, and they had started to give out free certificates relatively recently (I heard of them only this February)
> Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in
obtaining or relaying sensitive information such as health records, financial details, personal information etc.
StartSSL will make you pay to revoke a certificate if you need to.
They have some sort of regex they use to flag business domains. For example, if your domain contains the word 'billing', then they won't give you a cert.
I can't use StartSSL because my DNS registrar doesn't populate whois the way they like it. Also, anyone relying on some sort of whois privacy cannot use StartSSL.
I would like to add that from my personal experience I would not recommend the free StartSSL cert for personal use. The certs are free but revoking them costs money, so when the whole Heartbleed thing happened a lot of people got screwed. Regardless of the cert owners ability to pay for it, StartSSL made the web an arguably less secure place with that business decision and many did not pay to revoke their free cert. For a time there were even discussions of removing all the StartSSL certs from Firefox as a result [0].
I agree but I think registration and configuration should be split a little bit more. I personally won't trust it with my config files (and god knows what other wonderful webserver will emerge next month), but having an automated cert-generation tool is great.
Also, they absolutely must improve OSX support. One of the main objectives is to help people who are in the web field but wouldn't otherwise bother learning the intricacies of SSL configuration; these people by and large use Macs.
> I agree but I think registration and configuration should be split a little bit more. I personally won't trust it with my config files (and god knows what other wonderful webserver will emerge next month), but having an automated cert-generation tool is great.
The official client can be ran in 'auth' mode, in which it will not write to your server configs. It can still automate the authentication process for you by looking at where the DocumentRoot is, and placing a file there. But this is also optional, since there is a manual authentication mode as well that just gives you a file, and you'll have to make it available under your domain somewhere and tell it when you've done so.
> Also, they absolutely must improve OSX support. One of the main objectives is to help people who are in the web field but wouldn't otherwise bother learning the intricacies of SSL configuration; these people by and large use Macs.
I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO.
> They also use Mac on their servers?
No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never".
> I know, I just think "auth mode" could be a separate tool to improve usability. It might just be an alias, I don't care, but it's easier to remember "get-cert" than yet another double-dash parameter IMHO.
It's a subcommand, not a "double-dash parameter". You have to supply one of the following, for it to do anything:
(default) run Obtain & install a cert in your current webserver
auth Authenticate & obtain cert, but do not install it
install Install a previously obtained cert in a server
revoke Revoke a previously obtained certificate
rollback Rollback server configuration changes made during install
config_changes Show changes made to server config during installation
> No, but very often they develop and try new tools on their Macs. By blowing the mac experience you're forcing them/us to spin up a vm (if you can) and repeat the installation. This raises the bar for adoption a little bit. In these fickle times, it can make the difference between "oh wow this is magic" and "can't be arsed, will check it out later/never".
It's a tool meant for servers, to configure server software. I'm not sure why anyone would want to run it on their development machine, especially since a domain name needs to be pointed towards a webserver running on that machine that is accessible from the WAN.
> I'm not sure why anyone would want to run it on their development machine
Do you usually download and run random tools for the first time directly on a server box?
> a webserver running on that machine that is accessible from the WAN
Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today.
It's required to supply a subcommand, or it won't do anything. That is a big difference from a flag which you may forget to use, and then the program runs anyway.
> Do you usually download and run random tools for the first time directly on a server box?
I usually spin up a virtual machine for testing out server stuff.
> Ok then you really should specify this somewhere. I've gone through the github readme and the User Guide without this being mentioned anywhere. I'm probably stupid for not running arbitrary beta tools on random wan-facing servers, but I'm certainly not the only stupid person in IT today.
Me? I'm just a happy let's encrypt beta user. https://letsencrypt.org/howitworks/technology/ seems like a pretty clear, easy to comprehend, overview to me. I'm not sure how you were planning on validating ownership of a domain to a third party if you don't want that third party to request resources served by that domain.
It's not that you forget to use it, it's forgetting what you're supposed to specify. Anyway, it's a UI thing so we'll never agree. Fine.
> I usually spin up a virtual machine for testing out server stuff.
Yes, we've established that. What I'm saying is, not everyone does. In fact, the people you most want to use this tool (the SSL-illiterate, so to speak) are probably the ones most likely not to do it.
Well then, there must have been a miscommunication about the aim of this project. The target user, from what I understood, was supposed to be the SSL-illiterate who doesn't really care too much about the whole tech, he wants things to Just Work. The experts could already self-sign or snag a certificate here or there; the point of this tool was supposed to be helping workaday IT guys get on board the encryption thing with the minimum of effort and cost.
None of these people is going to read that page (who reads "about" pages on marketing websites?). They are going to clone the repo, check the readme, maybe check the user guide linked from the readme. If it doesn't work the first time for whatever reason (because the guide is not clear where it can and cannot be run), they're going to drop it and just keep doing what they're already doing (which, after all, Just Works already, it's just not encrypted).
If LE developers want to onboard stupid people like me, they have to clarify that:
1) this is supposed to run only on internet-facing servers with a domain already pointed to them,
2) this doesn't work on mac -- no half-hearted "experimental support", if they can't be bothered they should just drop it,
3) all the info required to make it run "without thinking" should be either in readme or user guide.
There's alternative tools that use the same standard API, you don't need to use the standard tool.
If you want it to only register and authenticate to fetch a cert but not install it, and you want it to just tell you what you need to do so that you can do it manually if you so wish, then that's possible.
If you just want a free cert, you can use my letsencrypt-nosudo client[1], which doesn't ask for your private key or sudo access or have to be run on your server (except for one copy-paste line you can inspect). The official letsencrypt client is geared much more towards someone who doesn't understand how TLS certs work. For people who know what they're doing, you can use lightweight clients like mine to just get your free cert.
Let's encrypt certificates are valid for only 90 days, and I guess the argument is that you want automatic tooling to take care of renewal if it happens so often.
That might actually be a good thing, though. Currently I have to do it for a couple of domains every year. By forcing me to automate it, it takes me more time once, but afterwards I don't have to look at it anymore at all.
Ugh, really? I was planning on only using the tools to write out the initial certificate file, as I don't want too much running on my servers. This has certainly put a damper on my excitement about Let's Encrypt.
From a quick look at the protocol, it shouldn't be an issue to run the ACME client on one host and scp CSRs from your servers to it, hand them to lets encrypt, and move the results back. So yes, you have to touch or run it every 2-3 months, but it doesn't have to run on all your servers.
I'm more wondering if I can cron it (without sudo), and not have it run as a daemon. Then, once every two weeks or so, it can just refresh the cert using the csr I generated before. It should be pretty easy to do, I'm just not familiar with the clients at this point.
Plus lack of identity validation. While the author of the article minimizes this, we shouldn't remove it from the equation just because users can't tell the difference. The right thing would be to fix the users understanding rather than weaken the product.
LetsEncrypt will be good for all those sites we deploy with self-signed certs, but won't be replacing major sites any time soon.
Is identity validation under any circumstances more than snake oil?
Neither users nor browsers could tell whether a site is supposed to run a domain- or identification validated certificate. (Fun fact, HN uses a domain validated cert.) All you get is higher costs for some X.509 fields nobody ever looks at, and nobody would miss if an MITMing attacker replaced your ID validated cert with an domain validated one.
You can use HPKP to pin EV-only root CAs, so you can still replace your cert, but it can only be replaced against another EV one.
Doesn't protect against a hacked/rogue CA, but against someone getting access to your DNS/mail/web server and getting a useable certificate from a only-domain-validating CA.
Just because the CA or the intermediate says EV doesn't mean that they only issue EV certs. The CA we use at work will issue certs with their EV root when we need compatibility with older installs, they only had their EV root cross signed.
Yes, but EV is not the same as identity validation. That's another variant of certificates that was only introduced because identity validation alone is so bloody useless.
> Plus lack of identity validation. While the author of the article minimizes this, we shouldn't remove it from the equation just because users can't tell the difference. The right thing would be to fix the users understanding rather than weaken the product.
But should we? I've never looked at an SSL cert past seeing the green lock icon and "https". Maybe I'm an idiot but I just don't see the value in checking it every time I go to a site AND remembering if it was just domain or one with identity the last time I visited...
Not anywhere that I can find. Let's Encrypt is very important or full participation on the web isn't available to the poor. The internet should be fully usable by anybody with an IP. Adding the cost of a PKI cert is a barrier to entry.
> Startssl
...won't give me a certificate. (they have in the past, I don't know why they changed their mind)
This assumption that a single private business providing free certificates (but mind the fine print) is somehow an a solution to the SSL problem is poor engineering[1]. Unfortunately, this kind of
attitude has become very common in recent years.
[1] You should always have a second source for anything critical. A design that is dependent on a single point of failure that you don't control is a design that is guaranteed to fail unpredictably.
"The performance complaint is long debunked" - There are still performance hits.
- There are still two additional round trips on the first https connection vs http. That means there are still cases where http is faster than https, even when using spdy/http2.
- Also, the initial (before an HSTS header is seen) redirect from http -> https when typing in a domain name adds to the overall first load time.
Even after the performance and maintenance issues, we still have the local-development issue (developing on 127.0.0.1). You still need to own a domain name to get a cert from Let's Encrypt.
I'm happy Let's Encrypt is making certs easier so we can start focusing on the _next_ hurdles of massive TLS adoption. :)
A lot of developers, even today, come to me asking for a server configured to run a specific directory over SSL, with the rest of the site over plaintext.
The argument I am always given is that SSL will tax the CPU and the site won't be able to scale. I'm told it's a best practice and people will viciously defend "wasting" performance on parts of the site that don't need it.
It's not a common recommendation here, where people are arguably more aware of modern practices.
But amongst a lot of the population of entry level web developers I run into, it's a very common one, and it's also very wrong.
The "round trip" issue however that you point to, is totally valid, but also one that will not kill a site's ability to scale.
TLS absolutely does tax the CPU. Netflix published a paper [1] about the work they did to scale TLS in their cache appliances; after their work, they were able to get 10Gbps of https traffic out of a system that was previously limited by its network interfaces to serving 40Gbps of http traffic.
That certainly doesn't apply to everyone, a lot of people are using more CPU to generate their content than to serve it; in that case, maybe adding some extra CPU to encrypt isn't going to have a big effect.
Extra round trips can also affect the ability to scale: you'll need to be able to handle more connections open at a time, since each one will take longer to get the request to you. This is probably minor, unless you're on the edge of the number of connections your system can handle.
HSTS preload doesn't reduce the preamble to a TLS connection:
You have to send the TLS client hello, wait for the TLS server hello back (1 Round trip), send the handshake finished, wait for the server handshake finished (2nd round trip), before sending application data. TLS 1.3 is supposed to help with that (although I haven't read the spec), but that's probably just bringing it down to one extra round trip in the common case. Add tcp (one round trip), and http (one round trip), and it's four round trips, twice as many as plain http.
If you are serving us users on broadband, and you only have servers on one side of the country, half of your users are going to see about 80 ms round trip, so https slows down your first page load by 160 ms, even before you worry about encryption. If you have users around the world, and servers in only one location, you're likely to see many users with 250ms or 300 ms, an very simple https page (short request, short response) is going to take a minimum of 1 second (2 round trips for tls, one for tcp, and one for http), and if your users are on congested mobile networks, ouch.
It doesn't reduce the TLS connection, but it reduces two round trips for the HTTP->HTTPS redirect. If the link is https in the first place then it's not a problem, but if you type in a domain name it will try HTTP first before starts the TLS connection.
How. How is that thing still considered a solution? We are talking about Chrome's HSTS preload, right? How come downloading all the Internet's certs with a browser is considered at all? Yes, it's nice, but it's a bigger hack than Win95's GUI on MSDOS.
I can't wait to see how this industry will change after LE is fully running -- this is amazing. Are there any stats about the different cert types, specially about their deployment count and usage over time?
One thing I don't understand about the guarantees given by CAs is the one about the warranty, like the "$1,750,000 Warranty" from Comodo. How exactly can they provide that? Or is that some sort of MUST have if you want to partner with an insurance company?
What types of stats are you looking for? "Different types" meaning different CAs?
The warranty is odd. Its required to provide a warranty in certain situations by the CA/B Forum (industry standards body). This is partially because some countries laws require they be provided for the class of products/services that SSL falls under, so requiring it from everyone sort of levels the playing field.
But the large CAs (Symantec, Comodo, etc) are big fans regardless. They can advertise this preposterous "warranty" which protects you, and usually the customer does not ask too much about it and just likes the sound of it or assumes it will cover them if they are hacked (which is not what its for). It actually just covers some very small situations where the CA mis-issues your certificate.
Some lawyers and experts at TrendMicro and Firefox found that due to how the terms are written there is basically no way the end-user would ever actually see that money. Those insurance warranties have never been used.
About the stats: by "specially about their deployment count and usage over time" I meant the number of certs deployed by cert type (DV, OV, EV) and how has their usage progressed over time? If the second part is not clear, let's say that 5 years ago EV certs represented 2% among issued certs, and today it represents 1.4% -- I'm looking for historic data about this.
Thanks about the warranty clarification, so it only protects you if the /CA/ does something bad to you? In that case wouldn't it possible to sue the entity for, possibly, an even larger sum?
Stats like that may be available but I can not think of anything at the moment. I will look into that and let you know.
>Thanks about the warranty clarification, so it only protects you if the /CA/ does something bad to you? In that case wouldn't it possible to sue the entity for, possibly, an even larger sum?
Yes, I believe the damage has to be due to the CAs behaviors. The two major situations I can think of that would qualify would be:
1. The CA issues a certificate for your domain/company to someone who was not authorized. However I would think that cert would then have to be used in an actual attack so you could quantify your damages.
2. The CA is breached in some way that allowed your certificate to be compromised or allowed an attacker to create a fraudulent certificate for your domain/company.
That is a very good question about suing the CA for other damages. I am not aware if this has ever occurred but it certainly seems like it could.
No that's what I meant. I haven't signed up for the beta myself but there's been discussion of others testing the client on Discourse for a good while now.
The official client does not have to be ran as root. You can do the manual auth mechanism which just gives you the certificates. The authentication process against letsencrypt will give you a file to put in your webroot.
You ran a setup script, as root, without looking at it and are upset it installed things? Shouldn't you be more upset that you didn't take the time to look at what it does before running it as root?
letsencrypt-auto is specifically there to setup and update the entire environment for letsencrypt to work. If you don't run it as root, you get prompted to elevate. If you're at all concerned about what setup its doing, the code is eminently readable and a few seconds of perusal would direct you to the bootstrapping scripts (https://github.com/letsencrypt/letsencrypt/tree/master/boots...)
Running letsencrypt-auto is no different than running one of the curl | sh installers; they serve the same purpose. Getting you up and running under the assumption that you may be missing bits and pieces.
If you don't trust the official letsencrypt client, you can use this script to get your free certs. It doesn't install things or ask for sudo access or your private keys or have to be run on your server (except for one challenge response one-liner you can inspect). I wrote it specifically so people who didn't trust the letsencrypt client could still get free certs.
That's the whole point of the article -- from what I understand the standard letsencrypt installer makes changes; this script is easier to inspect & modify.
When should one expect to see an ACME client built into nginx so that you could specify an ACME-enabled CA instead of a key file right in nginx config and have nginx itself do the rest?
No that is not the entire point of a CA. The insurance that the big commercial CAs offer now is a farce. No end user has actually received the money for two reasons:
1. breaches that qualify are often written off by the underwriter as "gross negligence" or other such behavior which basically allows them to nullify the contracts and pay nothing
2. situations where the breach could be covered by the terms of the insurance are incredibly rare. Most situations where SSL compromise is at risk would not be covered. The insurance only helps you if the CA causes you damages through their own actions. In one of the most famous cases, the breach of the CA DigiNotar, the underwriter said that DigiNotar misrepresented themselves and invalidated all their policies.
Let me rephrase with a quote from the public-key cryptography wiki:
"An attacker who could subvert any single one of those certificate authorities into issuing a certificate for a bogus public key could then mount a "man-in-the-middle" attack as easily as if the certificate scheme were not used at all."
I agree. Why not just have an interface like encrypted = encryption.encrypt(bytes)? Deal with getting a certificate and storing it for me, the reason people don't encrypt everything today is because it's a pain in the ass.
> With Automatic Web Server Configuration
>
> This will automatically configure Apache and Nginx servers > with your new certificate.
I wished they wouldn't do that at all. There's a world of hurt in trying to pretend to configure the cert on the current system. That's simply never going to work reliably. Let the individual distributions do their job by providing just the rest.
A small suggestion - instead of wget-ing the certificate chain from the page, I would use the cert-chain-resolver tool[0]. It's super simple, but highly effective bash script that wraps around OpenSSL / wget and does all this for you.
[0] https://github.com/zakjan/cert-chain-resolver