a small human has been consuming all my blogging time lately, but I decided to get back into the game with a post full of terrible ideas for how to abuse Certificate Transparency to re-create public key pinning:
Conversation
This is provided by TLSA records, not CAA. TLSA records work well. You can use them to pin the hash of a leaf key, an intermediate key or a root key. You can have multiple valid pins which allows rotation, etc. You can set TTL low to minimize disruption from making mistakes.
2
1
spent 15 minutes just now trying to get one of these services to print me an appropriate DNS record, no dice. Would love for any of this to be about 10x easier for the standard use-case of having a single SSL root issuer
1
To get the public key hash:
openssl x509 -in public-certificate.pem -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -hex
For leaf keys:
TLSA 3 1 1 5FDBAC0BE6EE09E8B118DF22392F90CC0421EAA05993900DA27B8BE5
Change 3 to 2 for intermediate/root keys.
2
Thank you for the guide. I am trying to generate what I said above, which (after reading) is TLSA 0 1 1. I do not know why I would use the leaf, since that will change every 60 days. It turns out it does not matter, as my DNS provider doesn't do TLSA. But, thank you.
2
3 1 1 is for pinning a leaf key. If you set certbot or equivalent to reuse the same key, it doesn't change. It obtains a new certificate with the same key. You can still manually rotate the key, phase in a 2nd record, deploy it and remove the old record.
2 1 1 for pinning an intermediate OR root key. You shouldn't pin the certificates because there can be variants of them. It's best to pin the key. Ignore the stuff for pinning certificate hash (more brittle for no benefit) or for including entire certificate (bloated/pointless).
1