
Letsencrypt implemented as a shell script - lukashed
https://github.com/lukas2511/letsencrypt.sh
======
StavrosK
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.

~~~
kbaker
You may also want to look at
[https://github.com/kuba/simp_le](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.

[https://news.ycombinator.com/item?id=10672006](https://news.ycombinator.com/item?id=10672006)

~~~
StavrosK
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!

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

~~~
StavrosK
And a _whole operating system_! I like my shell scripts running on bare metal.

~~~
mikeash
A CPU whose native ISA is bash would be interesting.

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

~~~
chengiz
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.

~~~
lukas2511
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.

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

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

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

~~~
ketralnis
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

~~~
umaguma
Yes! You got it!

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

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

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

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

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

