Hacker News new | past | comments | ask | show | jobs | submit login
Letsencrypt implemented as a shell script (github.com)
60 points by lukashed on Dec 5, 2015 | hide | past | web | favorite | 32 comments

I just need something that can do:

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

You may also want to look at https://github.com/kuba/simp_le . Written by the same developer as the official client.

Really easy to set up and run from a cron job. Outputs the full chain as well.


I tried that as well, but installation wasn't trivial. I think the author pushed it to PyPI yesterday, so I'll give it another shot, thanks!


A shellscript... and a perl script and the openssl command line binary!

And a whole operating system! I like my shell scripts running on bare metal.

A CPU whose native ISA is bash would be interesting.

And a nearly empty README

Hey there, author of this thingy here, nice to see that some people like what i'm wasting my time on ;)

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.

Why do you care about the sed dependency? It's a basic unix command that everyone has. Unless there's some strong time penalty, it'd be better to use sed over some weirdass bash syntax.

Well, i'll have to check if the syntax i used works under BSD sed, because that seems to differ slightly and I ran into problems in the past.

Is the lure of letsencrypt that

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.

Telling the browser to accept all self-signed certificates is a bad idea, because it's no more difficult for an attacker to create one of those than the legitimate domain owner. Let's Encrypt has at least two huge immediate benefits:

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

It sounds like domain registrars are being used to supplant the role of CA's?

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

almost anyone can set up trivial end to end encryption using any number of methods without relying on outside agencies. SSH, VPN, PGP, the list goes on. The issue is getting a HTTPS cert trusted by the general public, which is a much harder problem. Before letsencrypt, you had to pay a CA to issue you a cert. For a DV cert, they verified that you had permission to get a cert through a small number of ways. Most involved just getting an email through the whois entry for your domain, or setting a specific entry in DNS. Those aren't any more "secure" then letsencrypt's methods. If anything, a letsencrypt cert is arguably MORE secure, as it only lasts 3 months, so the domain needs to be rechecked more often.

You can encrypt between end points using self signed certs or your own CA just fine, but without the CA system you'll need some other way to prove that the signer is who you think they are. This could be a phone call or whatever other method you like

Yes! You got it!

Where can I run queries against these verifiable logs for my domain?

The allure over other DV CAs is that it's gratis, and, soon, that it'll be deployable at the push of a button.

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

Doesn't LetsEncrypt require that you have DNSSEC enabled on your domain, as a first step? DV is a valid proof of identity, assuming DNSSEC, right?

No, DNSSEC isn't required. LetsEncrypt supports a bunch of DV methods right now[0], but the bottom line is that if someone can control either your DNS server or your web server (any web server on an IP at which your domain points) then they can always get a certificate for your domain. This applies to all DV cert issuance from most CAs afaik.

Full DNSSEC verification by the issuing CA (LetsEncrypt) still wouldn't mitigate attacks against the "Simple HTTP" method.


Well, there are two major reasons why I think letsencrypt is great right now.

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.

TLS is a system designed to support both authentication and encryption. Losing authentication is actually a pretty big deal, so of course browsers won't do it.

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.

"... because you can trivially MITM someone..."

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?

It authenticates the same thing most ssl certs do. That you have control over the domain. Self-signed certs don't do that, so a letsencrypt cert is actually more secure then a self-signed cert.

Now that's something one can use on a server w/o python. It's obviously harder to use than a fire and forget service, but it broadens the use-cases to simple gear where you don't want to run everything (or can't).

I thought one of the big intended advantages of letsencrypt was the apache and nginx integrations.

It is one of the big intended advantages, but the way it is implemented in the official client is not very flexible, and has a huge dependency list. We just added some support for Let's Encrypt to Virtualmin, and the official client proved clumsy to work with. The smaller clients that have been discussed here lately would have been simpler to integrate (and we may end up with our own Perl implementation before long, so it can be used in Webmin without adding a big stack of dependencies).

unless you need letsencrypt in, for example, in puppet.

Appreciate the effort. Just skimmed through the code, it seems to depend on perl.

It was also a quick refresher on how god damn ugly bash's syntax is.

I think I would have just written it in Perl, and remove the bash dependency (since bash is not installed, by default, on some minimal distros...Perl is also missing in such a case, but depending on both is certainly not better).

Applications are open for YC Summer 2019

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