Krossignuð CA: lykillinn passar, AKI-tengingin ekki

Tvö CA-vottorð geta borið sama opinbera lykil og sama subject og samt ekki verið skiptanleg. Annað er sjálfsskrifað, hitt er krossskrifað af gömlu rótinni, og útgefandanöfn þeirra, raðnúmer og undirskriftir eru ólík. Blað getur tengst sérstaklega öðru þeirra í gegnum Authority Key Identifier sinn. Sú tenging helst ósýnileg þangað til biðlari velur röngu keðjuna og handshake mistekst án augljósrar ástæðu.

Farðu í gegnum þessar fimm athuganir í röð: hver um sig útilokar mismunandi bilun.

Athugun 1: teiknaðu báðar keðjurnar áður en þú snertir sniðmátið

Skrifaðu slóðirnar niður. Gamla hópurinn treystir Gömlu rót A, sem gaf út CA B, sem gaf út blað netþjónsins. Nýi hópurinn treystir sjálfsskrifuðu CA B beint. Bæði B-vottorðin bera sama lykil og subject, og þess vegna sér manneskja sem les subject-línu eitt CA þar sem biðlarinn sér tvö.

Krossskrifaða eintakið verður líka að vera alvöru CA-vottorð, með basic constraints og key usage sem leyfa undirskrift.

Athugun 2: berðu saman AKI-reitina, ekki bara lykilinn

Útgefandanafn blaðsins verður að passa við subject B, og sá hluti stendur yfirleitt. Authority Key Identifier er þar sem eintökin tvö greinast, því það getur borið lykilauðkenni, útgefandavottorð og raðnúmer. Lykilauðkennið passar við bæði eintökin, þar sem lykillinn er sá sami. Reitirnir útgefandi og raðnúmer passa við nákvæmlega eitt, og þess vegna getur keðja sem byggist gegn sjálfsskrifaða eintakinu mistekist gegn því krossskrifaða.

Skoðaðu blaðið í stað þess að giska: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Berðu svo saman báða kandídatin með openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", og sömu skipun gegn sjálfsskrifaða eintakinu.

Ef blaðið ber útgefanda og raðnúmer, þá lýkur aðeins vottorðið sem þessi gildi lýsa keðjunni, hvaða eintak sem biðlarinn hlóð.

Athugun 3: breyttu útgáfustefnu, aldrei undirskrifuðum bætum

Viðbætur lifa inni í undirskriftinni. Að bæta við, fjarlægja eða breyta einni á núverandi blaði er ekki viðgerð, það er annað vottorð og þarf endurútgáfu. Breytingin tilheyrir útgáfustefnunni: authorityKeyIdentifier = keyid,issuer:always lætur ný blað bera vottorðssértæku tenginguna, á meðan keyid eitt og sér heldur lausari myndinni sem hentar viljandi krossskriftarumsvifum. Ákveddu hvort þitt PKI vill áður en næsta lota er undirrituð.

Að breyta sameiginlegu sniðmáti breytir líka hverju framtíðarvottorði, ekki bara netþjóninum fyrir framan þig.

Athugun 4: sannreyndu hvern traustshóp fyrir sig

Prófaðu gömlu slóðina og nýju slóðina sem aðskilin keyrslur. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem æfir krossskrifuðu leiðina, og sama skipun með nýju rótinni og án untrusted-skrár æfir sjálfsskrifuðu leiðina. Að blanda báðum rótunum í eitt búnt felur hvaða keðja var valin. Endurtaktu síðan með raunverulegum biðlurum, því VPN-bakendi getur valið keðju eða fest vottorð á vegu sem openssl gerir ekki.

Skilaðu millivottorðinu í gegnum þjónustugrunnstillinguna sem biðlarinn les í raun, ekki í gegnum wiki-síðu.

Athugun 5: haltu gömlu slóðinni á starfslokaklukku

Krossskrift heldur gömlu traustssloðinni lifandi að hönnun, sem er bæði tilgangurinn og áhættan. Hún bætir ekki fyrir íhlutun í gömlu rótina og fjarlægir ekki þá rót úr neinum biðlara. Skrifaðu niður hvenær gamla slóðin hættir að veita traust, og staðfestu að sá dagur komi í raun.

Ef hver biðlari getur tekið nýju rótina áður en blöðin færast, er einföld innleiðing með tvöföldu trausti einfaldari en krossskrift, og hún skilur eitt færra eftir til að leggja af.