Implement ARI support when checking certificate renewal #959
Conversation
| serial="$("${OPENSSL}" x509 -in "${cert}" -noout -serial | cut -d= -f2)" | ||
| encserial="$("${OPENSSL}" asn1parse -genstr "INT:0x${serial}" -noout -out - | tail -c +3 | urlbase64)" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Ah yes, I remember reading about the positive integer stuff. Makes sense.
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.