Kruisgesigneerde CA: de sleutel klopt, de AKI-binding niet

Twee CA-certificaten kunnen dezelfde publieke sleutel en hetzelfde subject hebben en toch niet uitwisselbaar zijn. Het ene is zelfondertekend, het andere is kruisgesigneerd door de oude root, en hun uitgevernamen, serienummers en handtekeningen verschillen. Een blad kan zich specifiek aan een van beide binden via zijn Authority Key Identifier. Die binding blijft onzichtbaar tot een client de verkeerde keten kiest en de handshake faalt zonder duidelijke reden.

Werk deze vijf controles in volgorde af: elk sluit een andere fout uit.

Controle 1: teken beide ketens voordat je de template aanraakt

Schrijf de paden op. De oude populatie vertrouwt Oude root A, die CA B uitgaf, die het blad van de server uitgaf. De nieuwe populatie vertrouwt het zelfondertekende CA B rechtstreeks. Beide B-certificaten dragen dezelfde sleutel en hetzelfde subject, en dat is precies waarom iemand die een subjectregel leest één CA ziet waar de client er twee ziet.

De kruisgesigneerde kopie moet ook een echt CA-certificaat zijn, met basic constraints en key usage die ondertekenen toestaan.

Controle 2: vergelijk de AKI-velden, niet alleen de sleutel

De uitgevernaam van het blad moet overeenkomen met het subject van B, en dat deel klopt meestal. De Authority Key Identifier is waar de twee kopieën uiteengaan, omdat hij een sleutelidentificatie, een uitgevercertificaat en een serienummer kan dragen. De sleutelidentificatie komt met beide kopieën overeen, omdat de sleutel identiek is. De velden uitgever en serienummer komen met precies één overeen, en daarom kan een keten die tegen de zelfondertekende kopie wordt gebouwd falen tegen de kruisgesigneerde.

Inspecteer het blad in plaats van te gissen: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Vergelijk daarna beide kandidaten met openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", en dezelfde opdracht tegen de zelfondertekende kopie.

Als het blad uitgever en serienummer draagt, voltooit alleen het certificaat dat die waarden beschrijven de keten, welke kopie een client ook heeft geladen.

Controle 3: wijzig het uitgeefbeleid, nooit de ondertekende bytes

Extensies leven binnen de handtekening. Er een toevoegen, verwijderen of bewerken op een bestaand blad is geen reparatie, het is een ander certificaat, en het vereist heruitgifte. De wijziging hoort in het uitgeefbeleid: authorityKeyIdentifier = keyid,issuer:always laat nieuwe bladen de certificaatspecifieke binding dragen, terwijl keyid alleen de lossere vorm houdt die past bij een bewuste kruisondertekeningsovergang. Beslis welke je PKI wil voordat de volgende batch wordt ondertekend.

Het bewerken van een gedeelde template verandert ook elk toekomstig certificaat, niet alleen de server voor je.

Controle 4: verifieer elke vertrouwenspopulatie apart

Test het oude pad en het nieuwe pad als aparte runs. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem oefent de kruisgesigneerde route, en dezelfde opdracht met de nieuwe root en zonder untrusted-bestand oefent de zelfondertekende route. Beide roots in één bundel mengen verbergt welke keten is gekozen. Herhaal daarna met echte clients, want een VPN-backend kan een keten verkiezen of een certificaat vastpinnen op manieren die openssl niet doet.

Lever het tussenliggende certificaat via de serviceconfiguratie die de client echt leest, niet via een wikipagina.

Controle 5: houd het oude pad op een uitfaseerklok

Kruisondertekening houdt een oud vertrouwenspad ontwerpmatig in leven, wat zowel het doel als het risico is. Het verhelpt geen gecompromitteerde oude root en haalt die root uit geen enkele client. Schrijf op wanneer het oude pad geen vertrouwen meer geeft, en bevestig dat die dag echt komt.

Als elke client de nieuwe root kan overnemen voordat de bladen bewegen, is een eenvoudige uitrol met dubbel vertrouwen simpeler dan kruisondertekening, en laat het één ding minder uit te faseren.