matrey / acme-tiny-auto Goto Github PK

Now that LE switched to "R3", the intermediate certificate check fails.

• Need to take the intermediate from the API response
• Validate the intermediate with the root
• Refactor the OCSP stapling part (make it domain-specific rather than global)

Only Python 3 available by default on Ubuntu 16.04 LTS
Should not be a problem for acme_tiny, as it's compatible with both Python 2 and 3

Might be enough to use /usr/bin/env python instead of python
Need to test it on a fresh Ubuntu 16.04 LTS

https://github.com/diafygi/acme-tiny

NOTE: Since Let's Encrypt's ACME v2 release (acme-tiny 4.0.0+), the intermediate certificate is included in the issued certificate download, so you no longer have to independently download the intermediate certificate and concatenate it to your signed certificate. If you have an bash script using acme-tiny <4.0 (e.g. before 2018-03-17) with acme-tiny 4.0.0+, then you may be adding the intermediate certificate to your signed_chain.crt twice

From https://news.ycombinator.com/item?id=12787735

you don't need the account key at all if you can re-do the domain verification every time.
In most cases I delete the account key right after verifying the domain and getting a cert, and let certbot generate a new one every time.

• L(abelled)TSV format, good for fluentd/fluentbit
• add an entry even for runs that didn't do anything (can be used as a health check / ensure the cron works)
• record errors especially for cronjob

Regarding this line: https://github.com/matrey/acme-tiny-auto/blob/master/acme-tiny-auto.sh#L104
openssl genrsa 4096

2048: pros

The next relevant value in the table is 112 bits of security, which roughly corresponds to RSA with a key length of 2048 bits. At the moment this value is considered “Acceptable,” which means that it is not known to be insecure and it is deemed to be so until 2030.

While it is true that a longer key provides better security, we have shown that by doubling the length of the key from 2048 to 4096, the increase in bits of security is only 18, a mere 16%. Moreover, besides requiring more storage, longer keys also translate into increased CPU usage and higher power consumption.

If you need more security than RSA-2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA

RSA keys with >2048 bits are currently incompatible with Amazon Web Services. From the Amazon CloudFront Developer Guide: "The maximum size of the public key in an SSL/TLS certificate is 2048 bits" (remark from 2016 ; not necessarily true anymore + AWS offers free certificates these days anyways)

2048: cons

Yubico and Cisco position are valid, because they have hardware issue (HSM, PKI and smartcard don’t support 4096 bits very well).

The US Gov is starting to recommend 3072

Sources:

• certbot/certbot issues 489 and 2080
• https://www.yubico.com/2015/02/comparing-asymmetric-encryption-algorithms/
• https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand/
• https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand/
• https://wiki.archlinux.org/index.php/SSH_keys

Caught on this discussion: certbot/certbot#489

Except that barely anyone is changing their private key every 90 days as well, so the brute forcing on the grabbed captures can just continue on where it left off.
[...]
I am fairly certain that Certbot does that automatically, which was their point.