Ristiallekirjoitettu CA: avain täsmää, AKI-sidonta ei

Kahdella CA-varmenteella voi olla sama julkinen avain ja sama subjekti, ja silti ne eivät ole vaihtokelpoisia. Toinen on itse allekirjoitettu, toisen on ristiallekirjoittanut vanha juuri, ja niiden myyjän nimet, sarjanumerot ja allekirjoitukset eroavat. Lehti voi sitoutua täsmällisesti yhteen niistä Authority Key Identifierinsä kautta. Tämä sidonta pysyy näkymättömänä, kunnes asiakasohjelma valitsee väärän ketjun ja handshake epäonnistuu ilman ilmeistä syytä.

Tee nämä viisi tarkistusta järjestyksessä: kukin sulkee pois eri vian.

Tarkistus 1: piirrä molemmat ketjut ennen kuin kosket mallipohjaan

Kirjoita polut muistiin. Vanha populaatio luottaa Vanhaan juureen A, joka myönsi CA B:n, joka myönsi palvelimen lehden. Uusi populaatio luottaa itse allekirjoitettuun CA B:hen suoraan. Molemmat B-varmenteet kantavat saman avaimen ja subjektin, ja juuri siksi subjektiriviä lukeva henkilö näkee yhden CA:n siellä, missä asiakasohjelma näkee kaksi.

Ristiallekirjoitetun kopion on myös oltava aito CA-varmente, jossa on basic constraints ja key usage, jotka sallivat allekirjoittamisen.

Tarkistus 2: vertaa AKI-kenttiä, älä vain avainta

Lehden myyjän nimen on vastattava B:n subjektia, ja tämä osa yleensä pitää. Authority Key Identifier on kohta, jossa kaksi kopiota erkanevat, koska se voi kantaa avaintunnisteen, myyjävarmenteen ja sarjanumeron. Avaintunniste vastaa molempia kopioita, koska avain on sama. Myyjä- ja sarjanumerokentät vastaavat täsmälleen yhtä, ja siksi ketju, joka rakentuu itse allekirjoitettua kopiota vasten, voi epäonnistua ristiallekirjoitettua vasten.

Tutki lehti arvaamisen sijaan: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Vertaa sitten molempia ehdokkaita komennolla openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" ja samaa komentoa itse allekirjoitettua kopiota vasten.

Jos lehti kantaa myyjän ja sarjanumeron, ketjun täydentää vain se varmenne, jonka nämä arvot kuvaavat, minkä kopion asiakasohjelma sattui lataamaan.

Tarkistus 3: muuta myöntämiskäytäntöä, älä koskaan allekirjoitettuja tavuja

Laajennukset elävät allekirjoituksen sisällä. Yhden lisääminen, poistaminen tai muokkaaminen olemassa olevassa lehdessä ei ole korjaus, se on eri varmenne ja vaatii uudelleenmyöntämisen. Muutos kuuluu myöntämiskäytäntöön: authorityKeyIdentifier = keyid,issuer:always saa uudet lehdet kantamaan varmentekohtaisen sidonnan, kun taas pelkkä keyid säilyttää löyhemmän muodon, joka sopii tarkoitukselliseen ristiallekirjoitussiirtymään. Päätä, kumman PKI:si haluaa, ennen kuin seuraava erä allekirjoitetaan.

Jaetun mallipohjan muokkaaminen muuttaa myös jokaista tulevaa varmennetta, ei vain edessäsi olevaa palvelinta.

Tarkistus 4: vahvista jokainen luottamuspopulaatio erikseen

Testaa vanha polku ja uusi polku erillisinä ajoina. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem harjoittaa ristiallekirjoitettua reittiä, ja sama komento uuden juuren kanssa ja ilman untrusted-tiedostoa harjoittaa itse allekirjoitettua reittiä. Molempien juurten sekoittaminen yhteen nippuun kätkee, mikä ketju valittiin. Toista sen jälkeen oikeilla asiakasohjelmilla, koska VPN-tausta voi suosia ketjua tai kiinnittää varmenteen tavoilla, joita openssl ei tee.

Toimita välivarmenne sen palvelukokoonpanon kautta, jota asiakasohjelma todella lukee, älä wikisivun kautta.

Tarkistus 5: pidä vanha polku poistumiskellossa

Ristiallekirjoitus pitää vanhan luottamuspolun elossa suunnittelun mukaan, mikä on sekä tarkoitus että riski. Se ei korjaa vaarantunutta vanhaa juurta eikä poista sitä juurta yhdestäkään asiakasohjelmasta. Kirjoita muistiin, milloin vanha polku lakkaa antamasta luottamusta, ja varmista, että se päivä todella koittaa.

Jos jokainen asiakasohjelma voi ottaa uuden juuren ennen kuin lehdet liikkuvat, tavallinen kahden luottamuksen käyttöönotto on yksinkertaisempi kuin ristiallekirjoitus, ja se jättää yhden asian vähemmän poistettavaksi.