Letsencrypt implemented as a shell script
github.com
github.com
./something.py account.key domain.key domain.csr -o fullcert.pem
acme-tiny is 95% of the way there, but it doesn't output the full chain. I may just fork it and add the extra step, but I prefer it in the official client.
Really easy to set up and run from a cron job. Outputs the full chain as well.
Just wanted to let you know that I just pushed a few updates, the code now no longer requires perl, uses the more generic shasum tool, uses base64 in openssl instead of the systems base64 binary, and some more stuff.
There are a few more dependencies I want to get rid of, like 'sed'. But 'openssl' and 'curl' will stay as depdencies.
I also want to expand this script with the ability to detect changes in the domain config and with a check if a certificate is about to expire so that it can be renewed in a cron-job or something similar.
Revocation is another thing that I kinda should look at, for now you'll have to do that with one of the other clients that has this option.
And thanks to the author of acme-tiny, which kinda inspired me to write this.
1 it's accepted without warning in browsers or
2 it lets users ignore learning how to use the openssl binary (or writing their own tools with libssl, polarssl, etc.) to generate ca and site keys, certs, csr's, crl's, etc., or
3 both?
Here, the author appears to benefit mainly from 1.
Assuming letsencrypt does not do any sort of commercial CA-type "verification" then why do they need to be a CA? Why does one need an account?
Answer: browsers clinging to CA system.
Why not just get browsers to drop the warnings for self-signed certs?
The goal here, I thought, is to facilitate encrypted traffic, not to give a false sense of "authentication", correct?
Encryption and authentication are two different things.
Every user should understand that.
1) It does challenge-response domain validation from an external server. It's not enough for an attacker to intercept and modify traffic between the client and server -- they also have to control the route between the server and LE. This isn't an infallible check but it dramatically raises the difficulty of an attack, especially if the check is done from multiple independent locations.
2) LE supports Certificate Transparency, which means they verifiably log all certificates that they issue to multiple third-party observatories. Even if an attacker can bypass domain validation, they can't actually get a certificate without immediately making it obvious that they've done so, giving the server operator the chance to revoke the certificate and investigate (if they're paying attention).
This reminds me of the situation with email where if a user has not purchased a domain name, then it is nearly impossible for the user to send or recieve email without a third party "email provider".
Will encryption become the same? If at least one endpoint has not signed up with some third party (e.g., letsencrypt) _and_ purchased a domain name, then it becomes nearly impossible for two endpoints to encrypt traffic between them?
Will we ever again allow users to be fully empowered, _without the involvement of third party endpoints_ (CA's, domain regstrars, etc.), to send email, encrypt traffic, and all the other basic things one can do with a computer and an internet connection? Is it unfathomable that two parties connected to the internet might actually know and/or trust each other already, without involvement of a third party interloper?
Those are meant to be yes or no questions, or perhaps a rhetorical ones. No need to provide rationale. :)
DANE-TA or DANE-EE still would have been better than any and all of this DV public CA nonsense. A DV cert from a public CA proves that someone on the other end of the connection momentarily controlled either the DNS records for your domain, or your web server, at some point in the near past. That's it.
DV is an extremely weak proof of identity, and provides no authentication at all (as in, proof that the issue was actually authorised by the domain owner).
Full DNSSEC verification by the issuing CA (LetsEncrypt) still wouldn't mitigate attacks against the "Simple HTTP" method.
Encryption without authentication isn't really a good idea, because you can trivially MITM someone, serve them your certificate for google.com, open up a connection to google.com yourself, and it's now effectively as good as plain-text.
The security community was really upset with SuperFish and the recent Dell eRoot for the same reason -- you effectively lost accurate authentication, making it pretty easy to degrade someone's connection to plain-text.
This assumes the user is relying on certificates for authentication. Certificates that are likely tied to domain names.
What if the user authenticates by another means? SSH keys, real life meeting and exchange of keys, keys printed on paper and sent in the postal mail, etc. No domain name involved.
There are other ways to authenticate an endpoints besides domain names and certificates.
It's possible to have encryption without authentication.
It's also possible to have each of encryption and authentication handled by a different program. What we have now are programs that try to do both, and may do a very bad job of one at the expense of the other. These programs provide a false sense of "security".
The fundamental question: Are domain names easier to MITM than IP addresses?
One thing is that it just works, it's a trusted CA and there is no bullshit "please install this cert" stuff.
The other thing is the automatisation. There were some CAs with free certificates before, but you had to manually click around in a webinterface, manually put a file on a webserver or copy an ID from an email, or whatever to verify that you are the owner of the domain. This process often took from around 30 minutes to several hours, while the acme-protocol is designed to handle validation in seconds, and it actually works. You can start a new project, send of the signing command, and in seconds you'll have a certificate.
It was also a quick refresher on how god damn ugly bash's syntax is.