[Ach] bettercrypto.org certificate has expired today

[Jeroen Massar]

On 2017-02-26 01:04, Aaron Zauner wrote:
> 
>> On 25 Feb 2017, at 11:21, Hanno Böck <hanno at hboeck.de> wrote:
>>
>> On Fri, 24 Feb 2017 19:53:30 +0100
>> "L. Aaron Kaplan" <kaplan at cert.at> wrote:
>>
>>> FIXED & thx to maclemon!
>>
>> Is it fixed in the sense that you replaced it with a new (3 month) one
>> or have you implemented some kind of automation to renew it regularly?
>>
>> I think with LE it really doesn't make any sense to do it without
>> automation. Which is annoying in the beginning, but the right thing on
>> the long term.
> 
> Yes, I totally agree there. LE without the tooling (and their API) makes little to no sense.
> 
> About acme.sh in a follow-up mail: why? The Python tools are pretty decent as is their code-base (since I work[ed] on parts and have been using Python extensively in the past for systems tooling, I think I can reasonably judge), they use well maintained libraries and are checked by a lot of people. Exploiting a bash script is an order of magnitude easier than any Python code.
> 
> If you think the certbot code is bad - take a look at this mess: https://github.com/Neilpang/acme.sh/blob/master/acme.sh
> Even though I've seen far worse they do not make use of a lot of bashisms (which, for example, makes injection easier). A while ago I've written this - now community maintained - guide, if you're into bash check it out: https://github.com/azet/community_bash_style_guide

I'll toss in an alternative that one can consider (though I guess it
boils down to 'works for me' and personal opinion a lot for these things:

LEgo -- https://github.com/xenolf/lego

Written in the fun language of Go ;)

Noting from the README though:

"This is a work in progress. Please do NOT run this on a production
server and please report any bugs you find!"


I thought it was really auditable and it supports the right options that
I needed. Noting I am using the HTTP verifier...


In my setup I have:
 - one box that I use for 'management'
 - one VM 'acme' that only runs the LEgo client
 - multiple VMs that are HTTP frontends
   (nginx serving only static content)
   (these proxy to the backends and pass the ACME bit below to acme)
 - multiple VMS that are HTTP backends
   (nginx serving dynamic content)

Separation keeps any miscreant at bay of getting to the other step.
All config and content is in git.

The static frontends nginx config have an include, applied to every
vhost that states:
8<----
# ACME forward
location ^~ /.well-known/acme-challenge/ {
	proxy_intercept_errors  on;
	proxy_http_version      1.1;
	proxy_pass		http://acme;
}
---->8

Thus to update the SSL cert: login from the management box to the
lego at acme box account, run lego for all the domains (scripted of course):

lego --webroot /var/www/html/ --email="${EMAIL}" --domains="${DOMAIN}"
renew --reuse-key --days 45

Indeed, on the acme box there is a local nginx that serves from the
webroot; thus lego does not talk to the Internet.

Then logout from there, on the mgmt box run the script that copies the
crt/key files locally and then commit them in the right spot in git.

Kick nginx on the frontends. Presto.


Currently I just do this every ~2 months with a calendar entry, but in a
way I could automate this with a cron on the management box and then do
a 'nginx configtest' before a reload, just in case one of the certs went
b0rked.


The whole point of it all is separation (the lego account cannot touch
anything actually public). The acme VM also cannot talk much to the
Internet at large, nor can anybody speak to it directly, except for that
webroot path, which is mostly empty and will contain random strings thus
hard to guess what is in there.


The other thing here is that this supports pushing the certs to multiple
frontend boxes; while normally one would let acmebot etc modify your
configs and that is local and thus not on all the other boxes... (eek)...

Just my 2 cents on how paranoid I am, might give some idea to others...

Greets,
 Jeroen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20170226/8c7bc318/attachment.sig>