Kryssignert CA: nøkkelen stemmer, AKI-bindingen gjør det ikke

To CA-sertifikater kan ha samme offentlige nøkkel og samme subjekt og likevel ikke være utskiftbare. Det ene er selvsignert, det andre er kryssignert av den gamle roten, og utstedernavnene, serienumrene og signaturene deres er forskjellige. Et blad kan binde seg spesifikt til ett av dem gjennom sin Authority Key Identifier. Den bindingen forblir usynlig til en klient velger feil kjede og handshake feiler uten noen åpenbar grunn.

Gå gjennom disse fem kontrollene i rekkefølge: hver av dem utelukker en annen feil.

Kontroll 1: tegn begge kjedene før du rører malen

Skriv ned stiene. Den gamle populasjonen stoler på Gammel rot A, som utstedte CA B, som utstedte serverens blad. Den nye populasjonen stoler direkte på det selvsignerte CA B. Begge B-sertifikatene bærer samme nøkkel og subjekt, og det er nettopp derfor en person som leser en subjektlinje ser én CA der klienten ser to.

Den kryssignerte kopien må også være et ekte CA-sertifikat, med basic constraints og key usage som tillater signering.

Kontroll 2: sammenlign AKI-feltene, ikke bare nøkkelen

Utstedernavnet på bladet må samsvare med B sitt subjekt, og den delen holder vanligvis. Authority Key Identifier er der de to kopiene går fra hverandre, fordi den kan bære en nøkkelidentifikator, et utsteder-sertifikat og et serienummer. Nøkkelidentifikatoren samsvarer med begge kopiene, siden nøkkelen er identisk. Feltene utsteder og serienummer samsvarer med nøyaktig én, og derfor kan en kjede som bygges mot den selvsignerte kopien feile mot den kryssignerte.

Undersøk bladet i stedet for å gjette: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Sammenlign deretter begge kandidatene med openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", og den samme kommandoen mot den selvsignerte kopien.

Hvis bladet bærer utsteder og serienummer, er det bare sertifikatet disse verdiene beskriver som fullfører kjeden, uansett hvilken kopi en klient lastet.

Kontroll 3: endre utstedelsespraksis, aldri signerte bytes

Utvidelser lever inne i signaturen. Å legge til, fjerne eller redigere en på et eksisterende blad er ikke en reparasjon, det er et annet sertifikat, og det krever ny utstedelse. Endringen hører hjemme i utstedelsespraksisen: authorityKeyIdentifier = keyid,issuer:always får nye blad til å bære den sertifikatsspesifikke bindingen, mens keyid alene beholder den løsere formen som passer for en bevisst krysssigneringsovergang. Bestem hvilken PKI-en din vil ha før neste parti signeres.

Å redigere en delt mal endrer også hvert framtidig sertifikat, ikke bare serveren foran deg.

Kontroll 4: verifiser hver tillitspopulasjon separat

Test den gamle stien og den nye stien som separate kjøringer. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem øver den kryssignerte ruten, og den samme kommandoen med den nye roten og uten untrusted-fil øver den selvsignerte ruten. Å blande begge røttene i én bundle skjuler hvilken kjede som ble valgt. Gjenta etterpå med ekte klienter, fordi en VPN-backend kan foretrekke en kjede eller feste et sertifikat på måter openssl ikke gjør.

Lever det mellomliggende sertifikatet gjennom tjenestekonfigurasjonen klienten faktisk leser, ikke gjennom en wikiside.

Kontroll 5: hold den gamle stien på en avviklingsklokke

Kryssignering holder en gammel tillitssti i live ved design, og det er både poenget og risikoen. Den bøter ikke på en kompromittert gammel rot, og den fjerner ikke den roten fra noen klient. Skriv ned når den gamle stien slutter å gi tillit, og bekreft at den dagen faktisk kommer.

Hvis hver klient kan ta den nye roten før bladene flytter seg, er en vanlig dobbel-tillitsutrulling enklere enn kryssignering, og den etterlater én ting mindre å avvikle.