Implement ARI support when checking certificate renewal

[BtbN]

This implements ACME ARI according to https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/

Since we can't trigger a run at some point in the future, this is implemented according to the alternative approach.
It assumes the script is run once per day, so if the randomized renewal time is within the next 24h, a renewal will be triggered.

I did not test this on OSX/non-coreutils systems, so I do not know if the date-magic for it works. But I also didn't find any good portable way to deal with those rfc3339 dates.

[sur5r]

What's the reaseon for the roundtrip through asn1parse?

AIUI,

encserial="$("${OPENSSL}" x509 -in "${cert}" -noout -serial | cut -d= -f2 | hex2bin | urlbase64)"

does the same thing.

[BtbN]

It's implemented in line with https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/
Which does the same round-trip, just in go-code.
It reads to me like it's done to "ensure the serial is a positive integer". Why it does that, I'm not sure myself.
If for example the serial starts with 0x87... like in that example, piping it through asn1 like that would result in a leading zero-byte being added, which LE apparently expects:

$ openssl asn1parse -genstr "INT:0x87123456789A" -noout -out - | tail -c +3 | hexdump -v -e '/1 "%02x"'; echo
0087123456789a

Now if the ID does not start with a 1 bit, the extra 00 is not added:

$ openssl asn1parse -genstr "INT:0x57123456789A" -noout -out - | tail -c +3 | hexdump -v -e '/1 "%02x"'; echo
57123456789a

[sur5r]

Ah yes, I remember reading about the positive integer stuff. Makes sense.

[a-tze]

Since 0.7.2 was released without this feature, is there any new target milestone for this feature?

[a-tze]

FWIW: because of current events, I use 7f4ef7f in production and it works like a charm.

[a-tze]

Ok, Murphy is at work: one issue has shown up: OpenSSL 1.1.0 on older Debians outputs the AKI with a prefix of "keyid:" in front of the hex string.

I put something like " sed '/s/keyid://' " into the extraction command and that fixed it. There is probably a more elegant solution.

I did not research, if the output changed with OpenSSL 3.x or with any other specific version, or if it might even be distribution-dependent.

[BtbN]

Should be fixed now, and parsing should also be a bit more robust in general for lack of grep.

I also was made aware that the RFC calls for the client sending the certificate identifier along whenever renewal info is present, to indicate to the server which certificate is being replaced.
This was pretty simple to implement, since it's already calculated, and just needs to be passed through a few function calls to be included in the order payload.