Krosssignert CA: nøkkelen stemmer, AKI-bindinga gjer det ikkje

To CA-sertifikat kan ha same offentlege nøkkel og same subjekt og likevel ikkje vere utskiftbare. Det eine er sjølvsignert, det andre er krosssignert av den gamle rota, og utgivarnamna, serienumra og signaturene deira er ulike. Eit blad kan binda seg spesifikt til eitt av dei gjennom sin Authority Key Identifier. Den bindinga blir verande usynleg til ein klient vel feil kjede og handshake feilar utan noka openber grunn.

Gå gjennom desse fem kontrollane i rekkefølgje: kvar av dei utelukkar ein annan feil.

Kontroll 1: teikn båe kjedene før du rører malen

Skriv ned stiane. Den gamle populasjonen stolar på Gammal rot A, som gav ut CA B, som gav ut bladet til tenaren. Den nye populasjonen stolar direkte på det sjølvsignerte CA B. Båe B-sertifikata ber same nøkkel og subjekt, og det er nettopp difor ein person som les ei subjektlinje ser éin CA der klienten ser to.

Den krosssignerte kopien må òg vere eit ekte CA-sertifikat, med basic constraints og key usage som lèt signering til.

Kontroll 2: samanlikn AKI-felta, ikkje berre nøkkelen

Utgivarnamnet på bladet må samsvare med subjektet til B, og den delen held vanlegvis. Authority Key Identifier er der dei to kopiane går frå kvarandre, fordi han kan bere ein nøkkelidentifikator, eit utgivarsertifikat og eit serienummer. Nøkkelidentifikatoren samsvarar med båe kopiane, sidan nøkkelen er identisk. Felta utgivar og serienummer samsvarar med nøyaktig éin, og difor kan ein kjede som blir bygd mot den sjølvsignerte kopien feile mot den krosssignerte.

Gransk bladet i staden for å gisse: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Samanlikn deretter båe kandidatane med openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", og den same kommandoen mot den sjølvsignerte kopien.

Viss bladet ber utgivar og serienummer, er det berre sertifikatet desse verdiane skildrar som fullfører kjeden, kva kopi ein klient enn lasta.

Kontroll 3: endre utgivingspraksis, aldri signerte bytar

Utvidingar lever inne i signaturen. Å leggje til, fjerne eller redigere ei på eit eksisterande blad er ikkje ein reparasjon, det er eit anna sertifikat, og det krev ny utgiving. Endringa høyrer heime i utgivingspraksisen: authorityKeyIdentifier = keyid,issuer:always får nye blad til å bere den sertifikatsspesifikke bindinga, medan keyid åleine held på den lausare forma som passar for ein medviten krosssigneringsovergang. Bestem kva PKI-en din vil ha før neste parti blir signert.

Å redigere ein delt mal endrar òg kvart framtidig sertifikat, ikkje berre tenaren framfor deg.

Kontroll 4: stadfest kvar tillitspopulasjon separat

Test den gamle stien og den nye stien som separate køyringar. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem øver den krosssignerte ruta, og den same kommandoen med den nye rota og utan untrusted-fil øver den sjølvsignerte ruta. Å blande båe røtene i éin bundle gøymer kva kjede som vart vald. Gjenta etterpå med ekte klientar, fordi ein VPN-backend kan føretrekkje ein kjede eller feste eit sertifikat på måtar openssl ikkje gjer.

Lever det mellomliggjande sertifikatet gjennom tenestekonfigurasjonen klienten faktisk les, ikkje gjennom ei wikiside.

Kontroll 5: hald den gamle stien på ei avviklingsklokke

Krosssignering held ein gammal tillitssti i live ved design, og det er både poenget og risikoen. Ho bøter ikkje på ei kompromittert gammal rot, og ho fjernar ikkje den rota frå nokon klient. Skriv ned når den gamle stien sluttar å gje tillit, og stadfest at den dagen faktisk kjem.

Viss kvar klient kan ta den nye rota før blada flyttar seg, er ein vanleg dobbel-tillitsutrulling enklare enn krosssignering, og ho etterlèt éin ting mindre å avvikle.