Krydssigneret CA: nøglen matcher, AKI-bindingen gør ikke

To CA-certifikater kan have den samme offentlige nøgle og det samme subjekt og stadig ikke være udskiftelige. Det ene er selvsigneret, det andet er krydssigneret af den gamle rod, og deres udsteder-navne, serienumre og signaturer er forskellige. Et blad kan binde sig specifikt til et af dem gennem sin Authority Key Identifier. Den binding forbliver usynlig, indtil en klient vælger den forkerte kæde og handshake fejler uden nogen indlysende grund.

Udfør disse fem kontroller i rækkefølge: hver af dem udelukker en forskellig fejl.

Kontrol 1: tegn begge kæder, før du rører skabelonen

Skriv stierne ned. Den gamle population har tillid til Gammel Rod A, som udstedte CA B, som udstedte serverens blad. Den nye population har tillid til det selvsignerede CA B direkte. Begge B-certifikater bærer samme nøgle og subjekt, og det er netop derfor, en person der læser en subjektlinje ser én CA, hvor klienten ser to.

Den krydssignerede kopi skal også være et rigtigt CA-certifikat, med basic constraints og key usage der tillader signering.

Kontrol 2: sammenlign AKI-felterne, ikke bare nøglen

Bladets udsteder-navn skal matche B's subjekt, og den del holder som regel. Authority Key Identifier er hvor de to kopier skilles, fordi den kan bære en nøgleidentifikator, et udsteder-certifikat og et serienummer. Nøgleidentifikatoren matcher begge kopier, da nøglen er identisk. Felterne udsteder og serienummer matcher præcis én, og derfor kan en kæde, der bygges mod den selvsignerede kopi, fejle mod den krydssignerede.

Undersøg bladet i stedet for at gætte: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Sammenlign derefter begge kandidater med openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", og den samme kommando mod den selvsignerede kopi.

Hvis bladet bærer udsteder og serienummer, er det kun det certifikat, som disse værdier beskriver, der fuldfører kæden, uanset hvilken kopi en klient tilfældigvis indlæste.

Kontrol 3: ændr udstedelsespolitikken, aldrig signerede bytes

Udvidelser lever inde i signaturen. At tilføje, fjerne eller redigere en på et eksisterende blad er ikke en reparation, det er et andet certifikat, og det kræver genudstedelse. Ændringen hører i udstedelsespolitikken: authorityKeyIdentifier = keyid,issuer:always får nye blade til at bære den certifikatspecifikke binding, mens keyid alene bevarer den løsere form, der passer til en bevidst krydssigneringsovergang. Beslut, hvilken din PKI vil have, før næste batch signeres.

Redigering af en delt skabelon ændrer også ethvert fremtidigt certifikat, ikke kun serveren foran dig.

Kontrol 4: verificér hver tillidspopulation separat

Test den gamle sti og den nye sti som separate kørsler. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem udøver den krydssignerede rute, og den samme kommando med den nye rod og uden untrusted-fil udøver den selvsignerede rute. At blande begge rødder i én bundle skjuler, hvilken kæde der blev valgt. Gentag bagefter med rigtige klienter, fordi en VPN-backend kan foretrække en kæde eller pinné et certifikat på måder, openssl ikke gør.

Lever det mellemliggende certifikat gennem den servicekonfiguration, klienten faktisk læser, ikke gennem en wikiside.

Kontrol 5: hold den gamle sti på et nedtagningsur

Krydssignering holder en gammel tillidssti i live ved design, hvilket er både pointen og risikoen. Den afhjælper ikke en kompromitteret gammel rod, og den fjerner ikke den rod fra nogen klient. Skriv ned, hvornår den gamle sti holder op med at give tillid, og bekræft, at den dag faktisk kommer.

Hvis hver klient kan tage den nye rod, før bladene flytter, er en almindelig dobbelt-tillidsudrulning enklere end krydssignering, og den efterlader én ting mindre at nedlægge.