Kruisondertekende CA: die sleutel stem ooreen, die AKI-binding nie

Twee CA-sertifikate kan dieselfde publieke sleutel en dieselfde subjek hou en steeds nie onderling verwisselbaar wees nie. Een is selfondertekend, die ander is deur die ou wortel kruisonderteken, en hul uitreikernamen, reeksnommers en handtekeninge verskil. 'n Blaar kan hom spesifiek aan een van hulle bind deur sy Authority Key Identifier. Daardie binding bly onsigbaar totdat 'n kliënt die verkeerde ketting kies en die handshake misluk sonder enige ooglopende rede.

Werk deur hierdie vyf kontroles in volgorde: elkeen sluit 'n ander faling uit.

Kontrole 1: teken albei kettings voordat jy aan die sjabloon raak

Skryf die paaie neer. Die ou populasie vertrou Ou Wortel A, wat CA B uitgereik het, wat die bediener se blaar uitgereik het. Die nuwe populasie vertrou die selfondertekende CA B direk. Albei B-sertifikate dra dieselfde sleutel en subjek, en dit is presies waarom iemand wat 'n subjekreël lees een CA sien waar die kliënt twee sien.

Die kruisondertekende kopie moet ook 'n egte CA-sertifikaat wees, met basic constraints en key usage wat ondertekening toelaat.

Kontrole 2: vergelyk die AKI-velde, nie net die sleutel nie

Die blaar se uitreikernaam moet met B se subjek ooreenstem, en daardie deel hou gewoonlik. Die Authority Key Identifier is waar die twee kopieë uiteengaan, want dit kan 'n sleutelidentifiseerder, 'n uitreikersertifikaat en 'n reeksnommer dra. Die sleutelidentifiseerder stem met albei kopieë ooreen, aangesien die sleutel identies is. Die uitreiker- en reeksvelde stem met presies een ooreen, en daarom kan 'n ketting wat teen die selfondertekende kopie bou, teen die kruisondertekende een misluk.

Ondersoek die blaar eerder as om te raai: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Vergelyk dan albei kandidate met openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", en dieselfde opdrag teen die selfondertekende kopie.

As die blaar uitreiker en reeks dra, voltooi net die sertifikaat wat daardie waardes beskryf die ketting, watter kopie 'n kliënt ook al gelaai het.

Kontrole 3: verander uitreikingsbeleid, nooit ondertekende grepe nie

Uitbreidings lê binne die handtekening. Om een by 'n bestaande blaar by te voeg, te verwyder of te wysig is nie 'n herstel nie, dit is 'n ander sertifikaat, en dit vereis heruitreiking. Die verandering hoort in die uitreikingsbeleid: authorityKeyIdentifier = keyid,issuer:always laat nuwe blare die sertifikaatspesifieke binding dra, terwyl keyid alleen die losser vorm hou wat by 'n doelbewuste kruisondertekening-oorgang pas. Besluit watter een jou PKI wil hê voordat die volgende bondel onderteken word.

Om 'n gedeelde sjabloon te wysig verander ook elke toekomstige sertifikaat, nie net die bediener voor jou nie.

Kontrole 4: verifieer elke vertrouenspopulasie afsonderlik

Toets die ou pad en die nuwe pad as afsonderlike lopies. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem oefen die kruisondertekende roete, en dieselfde opdrag met die nuwe wortel en geen untrusted-lêer nie oefen die selfondertekende roete. Om albei wortels in een bondel te meng verberg watter ketting gekies is. Herhaal daarna met regte kliënte, want 'n VPN-agterkant kan 'n ketting verkies of'n sertifikaat vaspen op maniere wat openssl nie doen nie.

Lewer die tussen sertifikaat deur die dienskonfigurasie wat die kliënt werklik lees, nie deur 'n wiki-bladsy nie.

Kontrole 5: hou die ou pad op 'n aftree-klok

Kruisondertekening hou 'n ou vertrouenspad doelbewus lewendig, wat beide die punt en die risiko is. Dit herstel nie 'n gekompromitteerde ou wortel nie, en dit verwyder nie daardie wortel uit enige kliënt nie. Skryf neer wanneer die ou pad ophou om vertroue te gee, en bevestig dat daardie dag werklik aanbreek.

As elke kliënt die nuwe wortel kan aanvaar voordat die blare skuif, is 'n gewone dubbele-vertroue-uitrol eenvoudiger as kruisondertekening, en dit laat een ding minder oor om af te tree.