Krússûndertekene CA: de kaai komt oerien, de AKI-bining net

Twa CA-sertifikaten kinne deselde iepenbiere kaai en itselde subject drage en dochs net útwikselber wêze. Ien is selsûndertekene, de oare is troch de âlde woartel krússûndertekene, en har útjouwernammen, searjenûmers en hantekens ferskille. In bled kin him spesifyk oan ien fan beide bine fia syn Authority Key Identifier. Dy bining bliuwt ûnsichtber oant in klient de ferkearde keatling kiest en de handshake mislearret sûnder in dúdlike reden.

Wurkt dizze fiif kontrôles yn folchoarder ôf: elk slút in oare flater út.

Kontrôle 1: tekenje beide keatlingen foardat jo it sjabloan oanreitsje

Skriuw de paden op. De âlde populaasje fertrout Alde Woartel A, dy't CA B útjoech, dy't it bled fan de tsjinner útjoech. De nije populaasje fertrout de selsûndertekene CA B direkt. Beide B-sertifikaten drage deselde kaai en itselde subject, en dêrom krekt sjocht immen dy't in subjectrigel lêst ien CA wêr't de klient twa sjocht.

De krússûndertekene kopy moat ek in echte CA-sertifikaat wêze, mei basic constraints en key usage dy't ûndertekenjen tastean.

Kontrôle 2: fergelykje de AKI-fjilden, net allinnich de kaai

De útjouwernamme fan it bled moat oerienkomme mei it subject fan B, en dat part hâldt meastal. It Authority Key Identifier is wêr't de twa kopyen útinoar geane, want it kin in kaai-identifikaasje, in útjouwerssertifikaat en in searjenûmer drage. De kaai-identifikaasje komt mei beide kopyen oerien, om't de kaai identyk is. De fjilden útjouwer en searje komme mei krekt ien oerien, en dêrom kin in keatling dy't tsjin de selsûndertekene kopy boud wurdt, tsjin de krússûndertekene mislearje.

Undersykje it bled ynstee fan te rieden: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Fergelykje dan beide kandidaten mei openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", en itselde kommando tsjin de selsûndertekene kopy.

As it bled útjouwer en searje draacht, foltôget allinnich it sertifikaat dat dy wearden beskriuwe de keatling, hokker kopy in klient ek laden hat.

Kontrôle 3: feroarje útjeftebelied, nea ûndertekene bytes

Utwreidings libje binnen de hantekening. Ien tafoegje, fuorthelje of bewurkje op in besteand bled is gjin reparaasje, it is in oar sertifikaat, en it freget om opnij útjaan. De feroaring heart by it útjeftebelied: authorityKeyIdentifier = keyid,issuer:always lit nije bleden de sertifikaatspesifike bining drage, wylst keyid allinnich de losser foarm hâldt dy't past by in bewuste krússûndertekeningsoergong. Beslis hokker jo PKI wol foardat de folgjende bondel ûndertekene wurdt.

It bewurkjen fan in dield sjabloan feroaret ek elk takomstich sertifikaat, net allinnich de tsjinner foar jo.

Kontrôle 4: ferifiearje elke fertrouwenspopulaasje apart

Test it âlde paad en it nije paad as aparte rinnen. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem oefenet de krússûndertekene rûte, en itselde kommando mei de nije woartel en sûnder untrusted-triem oefenet de selsûndertekene rûte. It mingen fan beide woartels yn ien bondel ferstoppet hokker keatling keazen waard. Werhelje it dêrnei mei echte klanten, want in VPN-backend kin in keatling foarkar jaan of in sertifikaat fêstsette op manieren dy't openssl net docht.

Leverje it tuskenlizzende sertifikaat fia de tsjinstkonfiguraasje dy't de klient echt lêst, net fia in wikisy.

Kontrôle 5: hâld it âlde paad op in ôftanklok

Krússûndertekening hâldt in âld fertrouwenspaad libben by ûntwerp, wat likegoed it doel as it risiko is. It ferhelpt gjin kompromittearre âlde woartel, en it hellet dy woartel net út ien klient. Skriuw op wannear't it âlde paad gjin fertrouwen mear jout, en befêstigje dat dy dei echt komt.

As elke klient de nije woartel nimme kin foardat de bleden bewege, is in gewoane útrol mei dûbele fertrouwen ienfâldiger as krússûndertekening, en it lit ien ding minder oer om ôf te tankjen.