Verify the published certificate¶

The problem¶

You want to confirm that the certificate people are encrypting to still corresponds to the keys in your KMS account — that nobody has published a substitute, and that a certificate rebind has not happened.

Why this check exists¶

Anyone holding kms:Sign on the certification primary can mint a new subkey binding signature, attaching a different encryption key to the same identity. Republish that and every future message is encrypted to a key they control. The original encryption key is untouched, so nothing in KMS looks wrong.

What catches it is comparing the published certificate against the public keys KMS actually holds. Both roles can do this — the module grants kms:GetPublicKey on both keys to reader and certifier alike, specifically so this check does not require the higher-privileged role.

Steps¶

1. Fetch the public key from KMS¶

aws kms get-public-key \
  --key-id "$(tofu output -raw encryption_key_alias_name)" \
  --output text --query PublicKey | base64 -d > kms-subkey.der

2. Reduce it to a comparable fingerprint¶

openssl pkey -pubin -inform DER -in kms-subkey.der -outform DER \
  | openssl dgst -sha256

SHA2-256(stdin)= 9f2c...  (64 hex characters)

3. Extract the encryption subkey from the published certificate¶

Fetch whatever you publish over WKD, then pull the subkey's public point out of it and hash it the same way. The comparison is between the raw public keys, not between file formats — an OpenPGP packet and a DER SubjectPublicKeyInfo encode the same point differently.

The tooling for this belongs with certificate assembly, in sigillum. Until that lands, the practical check is step 4.

4. Check the certificate's fingerprint against your record¶

Record the certificate fingerprint when you first publish it, somewhere outside AWS:

gpg --show-keys --with-fingerprint published-cert.asc

A fingerprint that differs from your record means the certificate changed. That is either a rotation you performed, or one you did not — and if it is the latter, treat it as an incident: the private key that signed the rebind is the certification primary, so start by auditing kms:Sign in CloudTrail against that key.

Make it routine¶

This check is only useful if it happens on a schedule rather than after a suspicion. Record the fingerprint at publication, and re-check it whenever you touch the identity — and at least whenever someone leaves the certifier list.