Korssignerad CA: nyckeln stämmer, AKI-bindningen inte

Två CA-certifikat kan bära samma publika nyckel och samma subjekt och ändå inte vara utbytbara. Det ena är självsignerat, det andra är korssignerat av den gamla roten, och deras utfärdarnamn, serienummer och signaturer skiljer sig. Ett blad kan binda sig specifikt till ett av dem genom sin Authority Key Identifier. Den bindningen förblir osynlig tills en klient väljer fel kedja och handskakningen misslyckas utan uppenbar orsak.

Gå igenom dessa fem kontroller i ordning: var och en utesluter ett annat fel.

Kontroll 1: rita båda kedjorna innan du rör mallen

Skriv ned sökvägarna. Den gamla populationen litar på Gammal rot A, som utfärdade CA B, som utfärdade serverns blad. Den nya populationen litar direkt på det självsignerade CA B. Båda B-certifikaten bär samma nyckel och subjekt, och det är just därför en person som läser en subjektrad ser en CA där klienten ser två.

Den korssignerade kopian måste också vara ett riktigt CA-certifikat, med basic constraints och key usage som tillåter signering.

Kontroll 2: jämför AKI-fälten, inte bara nyckeln

Bladets utfärdarnamn måste matcha B:s subjekt, och den delen håller oftast. Authority Key Identifier är där de två kopiorna skiljs åt, eftersom den kan bära en nyckelidentifierare, ett utfärdarcertifikat och ett serienummer. Nyckelidentifieraren matchar båda kopiorna, eftersom nyckeln är identisk. Fälten utfärdare och serienummer matchar exakt en, och därför kan en kedja som byggs mot den självsignerade kopian misslyckas mot den korssignerade.

Granska bladet i stället för att gissa: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Jämför sedan båda kandidaterna med openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", och samma kommando mot den självsignerade kopian.

Om bladet bär utfärdare och serienummer är det bara certifikatet som dessa värden beskriver som fullbordar kedjan, vilken kopia en klient än laddade.

Kontroll 3: ändra utfärdandepolicyn, aldrig signerade byte

Tillägg lever inuti signaturen. Att lägga till, ta bort eller redigera ett på ett befintligt blad är ingen reparation, det är ett annat certifikat och kräver nyutfärdande. Ändringen hör hemma i utfärdandepolicyn: authorityKeyIdentifier = keyid,issuer:always får nya blad att bära den certifikatspecifika bindningen, medan keyid ensamt behåller den lösare formen som passar en avsiktlig korssigneringövergång. Bestäm vilken din PKI vill ha innan nästa batch signeras.

Att redigera en delad mall ändrar också varje framtida certifikat, inte bara servern framför dig.

Kontroll 4: verifiera varje förtroendepopulation separat

Testa den gamla vägen och den nya vägen som separata körningar. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem övar den korssignerade vägen, och samma kommando med den nya roten och utan untrusted-fil övar den självsignerade vägen. Att blanda båda rötterna i ett paket döljer vilken kedja som valdes. Upprepa sedan med riktiga klienter, eftersom en VPN-backend kan föredra en kedja eller fästa ett certifikat på sätt som openssl inte gör.

Leverera mellancertifikatet via den tjänstekonfiguration som klienten faktiskt läser, inte via en wikisida.

Kontroll 5: håll den gamla vägen på en avvecklingsklocka

Korssignering håller en gammal förtroendeväg levande av design, vilket är både poängen och risken. Den åtgärdar inte en komprometterad gammal rot, och den tar inte bort den roten från någon klient. Skriv ned när den gamla vägen slutar ge förtroende, och bekräfta att den dagen faktiskt kommer.

Om varje klient kan ta den nya roten innan bladen flyttar sig, är en enkel utrullning med dubbelt förtroende enklare än korssignering, och den lämnar en sak mindre att avveckla.