Let's Encrypt Overview
cryptologie.net
cryptologie.net
https://github.com/diafygi/letsencrypt-nosudo
The only thing that has to be run as sudo on your production server is a simple python one-liner that temporarily serves the required file. The script prints out this one-liner so you can copy and paste it into your server's terminal, then kill it when the challenge is done.
[0] https://github.com/letsencrypt/lets-encrypt-preview/blob/mas...
[1]: https://github.com/diafygi/letsencrypt-nosudo/blob/9607deb7b...
The official Let's Encrypt client is mostly focused on ease of use. This script is mostly focused on not knowing your secrets or requiring privileged access, and it assumes you know what a CSR is and how to install a signed certificate on your webserver.
> the address of the CA is hardcoded in the program so be sure to use the official lets-encrypt
Now, the idea of a nosudo letsencrypt is a good idea, but if such a thing should exist it should be made on the officiel repo and audited like lets encrypt was (note that this is just my opinion).
I would like to use this service, but I do not want a program to do things for me on my server unless it's part of the OS distribution, so this will help.
Why do you need sudo to serve a file though? Is it a restricted port?
Two notes, which I also sent to the author:
* Renewal does work already, it's just not documented anywhere. There is a script that can check when your cert is a specified amount of time from expiry, get a new cert, and subsequently deploy the new cert by updating symlinks. This mechanism works now, if the script is run from cron.
* You can use the client on a machine that doesn't have Nginx or Apache, it just won't be able to install the resulting cert. But the client's standalone mode can obtain the cert and save the associated files in the current directory. (In this case, they also won't be enrolled for automated renewal by the renewer script.)
If people think of useful integration features for particular platforms, we can take patches, or those platform developers can write their own clients. :-)
I wonder if this can be socially engineered/tricked to gain a certificate for someone else's domain. Like, I've seen at least one service (Majestic Seo) that asks you to upload a document to your domain to get certain services. Now that this (will soon) exist, any such service that someone uses can generate a cert and MITM the site.
Also, if they're verifying over http, couldn't anyone just mitm the verify connection? Well, anyone with access to any computer along the route between Let's Encrypt and whatever domain they want.
Edit: Ok, technically it's a CSR signed by a private key, but you could still use the key to self-sign a cert or something... But none of that mitigates the MITM attack described above.
I know W3schools is often thought of as useless, but for the upload script example on there there is no validation: http://www.w3schools.com/php/php_file_upload.asp
I imagine uploading something called "../verifyme.txt" would upload it to the root of the website.
The security issue there is not the fact that MitM becomes slightly easier, it's that you can alter the site for all visitors and don't need MitM.
Ultimately you have to bootstrap trust from somewhere. Perhaps in future DNSSEC can be used to solve this problem (though DNSSEC is of course itself just another PKI).
You also can't trust signed data if you don't trust the signature. That's the real problem here. This whole protocol is an attempt to establish trust, but it's based only on temporary control of a server's network traffic. Probably that's the legitimate owner of the domain, but maybe it's somebody malicious who merely had access to their network for a time. You can't really be sure.
If you need to pay for a cert before seeing if your hack worked, there will be less attempts.
This way, if your mitm failed, you didn't lose anything.
The real problem is that if somebody can intercept your HTTP traffic, they can register their own account key. After all, they can control your domain, and that's all letsencrypt cares about! If you haven't already registered an account key, I can't see how anything would stop them. If you already use a different CA and don't want to bother with letsencrypt, you might never find out either!
Because, as far as I understand, the answer is no: signing certs have no sense of signing "for an origin". If a CA issued me a CA cert, I could use it to create a signed cert for microsoft.com. Which seems nonsensical.
All I want is to get issued a CA cert that lets me sign arbitrary things within my domain's scope. Basically, the X.509 equivalent of a DNS NS record, delegating responsibility for making assertions about that domain (and only that domain) to "my" CA. Why is that so hard?
That's one of the several elephants on the room with the CA system. They issue non-leaf certs with a big frequency for people like the GP, with a honest reason to want them.
and is called by the CFSSL library, that has isCA = false as default (https://github.com/cloudflare/cfssl/blob/152152bec641f502651...)
Also it is verified that the CSR doesn't contain that field in Boulder: https://github.com/letsencrypt/boulder/blob/aa71088c440a63e1...
This test is called when you send the CA a CSR: https://github.com/letsencrypt/boulder/blob/08ac100788c7edaf...
I don't know for other CAs, but from that quick look of the code boulder doesn't seem to sign certificates that can sign other certificates.
You could approach the problem by creating your own root CA for the domain and then issue subordinate CA certs, but obviously for clients to validate them they would need to import your root into their trusted store (in a corporate IT scenario you would push out the root as part of the domain policy).
It's hard because for the longest time (e.g. between 1995 and about 2010) nobody really cared about SSL. It was a box you ticked when implementing a login form or a credit card purchase page. So the infrastructure was neglected, progress was lethargic and generally everything bitrotted.
This can be seen quite clearly in the state of OpenSSL, in the number of exploits in TLS stacks that started appearing in recent years once academic attention was focused on them, etc.
The feature you want is called name constraints and for the longest time was not really implemented anywhere. So that's why CAs don't do it. Also: this would be a highly niche feature and CAs, like any businesses, weigh up implementation cost vs potential market size and risk when choosing what to support.
That doesn't mean it will never happen. It could, now there's a lot more focus on the SSL infrastructure in the wake of Snowden.
They do run things in the open, though, and development is open source, so I think the updates have been pretty good...
therefore, they still have two and a half months approximately until "mid 2015" is over.
So unfortunately it'll only help with your dev sites if they're available on the public internet.
I don't expect the Let's Encrypt CA will be willing to help keep servers (or certs issued to them) a secret -- for example, the certs are likely to be published in Certificate Transparency! -- but you're right that the ACME DNS challenge doesn't require the server to be publicly accessible and doesn't even require the underlying subject name to exist in the publicly-visible DNS.
The good thing is the ACME protocol looks pretty straightforward so I'm sure someone will write that tool, even if Lets Encrypt themselves aren't interested in providing it.
If I get a cert from someone like letsencrypt for a domain I control, for example "xyz.com", will that same cert also work for "wiki.xyz.com", "blog.xyz.com", "someotherthing.deepdomain.xyz.com" and so on?
I'm interested because I use jwilder/nginx-proxy and then have a docker container for each of my webapps, each connected to a different subdomain (video, music, rss, vm, desktop, files, etc).
1. Get a separate certificate for each subdomain. Let's Encrypt makes this feasible since the certs are free and require a minimum of human overhead to obtain.
2. Get a single certificate that covers each subdomain by using Subject Alternative Names, which are currently supported by Let's Encrypt.
3. Get a wildcard certificate for "*.xyz.com". Let's Encrypt does not support this and I do not think it plans to, at least not in the initial release.
The main question is - is the set of subdomains known before-hand, or is it highly dynamic? If it is fairly stable, then options 1 or 2 will work well for you; otherwise, you probably want option 3.
Choosing between option 1 and 2 usually depends on the details of your infrastructure and your threat model. For example, are all these subdomains served from the same server or different servers? If it's the same server, you might be more inclined to use 1 cert for all of them (option 2) since it will be easier to manage. Do all the domains have the same threat model? For example, what if you run blog.xyz.com on one server and billing.xyz.com on a separate, hardened server. In that case, you would want option 1 because if you used the same cert on both servers, obtaining the private key from the less-secured blog.xyz.com server could be used to attack traffic for billing.xyz.com.
The subdomains are somewhat dynamic, since I'll add more whenever I add a new webapp to the server.
My question is: wouldn't wildcard certs be faster if the behavior on your site skipped around different subdomains? One certificate for all vs individual certs for each subdomain. I may be way off, I'm a novice when it comes to SSL/TLS handshake so please correct my ignorance.
You're right about the "just using a bunch of separate certs" solution being slower, though, especially with HTTP/2 (which, because of origin combining, uses exactly one real socket per TLS cert.)
With a wildcard cert, the third-party CDN would need your private key for your self-hosted www.example.com site. With different keys & certs per-site, the process is more modular.
I agree that wildcard certs would be great and I'll default to using them for the simplicity (e.g. temporarily activate a quick test.example.com site to check something works) but the ability to keep things modular is also great.
They should use HSTS and redirects, though.
Edit: sed "s#g/e#g + e#g"
https://github.com/diafygi/letsencrypt-nosudo/blob/master/si...
A good start for trying to figure out the workflow.