Kreuzsignierte CA: Der Schlüssel passt, die AKI-Bindung nicht

Zwei CA-Zertifikate können denselben öffentlichen Schlüssel und dasselbe Subjekt tragen und trotzdem nicht austauschbar sein. Eines ist selbstsigniert, das andere von der alten Root kreuzsigniert, und ihre Ausstellernamen, Seriennummern und Signaturen unterscheiden sich. Ein Leaf kann sich über seinen Authority Key Identifier gezielt an eines davon binden. Diese Bindung bleibt unsichtbar, bis ein Client die falsche Kette wählt und der Handshake ohne erkennbaren Grund scheitert.

Arbeiten Sie diese fünf Prüfungen der Reihe nach ab: jede schließt eine andere Fehlerursache aus.

Prüfung 1: Beide Ketten zeichnen, bevor die Vorlage angefasst wird

Schreiben Sie die Pfade auf. Die alte Population vertraut Alte Root A, die CA B ausgestellt hat, die das Server-Leaf ausgestellt hat. Die neue Population vertraut der selbstsignierten CA B direkt. Beide B-Zertifikate tragen denselben Schlüssel und dasselbe Subjekt, und genau deshalb sieht jemand, der eine Subjektzeile liest, eine CA, wo der Client zwei sieht.

Die kreuzsignierte Kopie muss ebenfalls ein echtes CA-Zertifikat sein, mit basic constraints und key usage, die Signieren erlauben.

Prüfung 2: Die AKI-Felder vergleichen, nicht nur den Schlüssel

Der Ausstellername des Leafs muss zum Subjekt von B passen, und dieser Teil hält meist. Der Authority Key Identifier ist die Stelle, an der die beiden Kopien auseinandergehen, denn er kann eine Schlüsselkennung, einen Aussteller sowie eine Seriennummer tragen. Die Schlüsselkennung passt zu beiden Kopien, da der Schlüssel identisch ist. Die Felder Aussteller und Seriennummer passen zu genau einer, weshalb eine Kette, die gegen die selbstsignierte Kopie baut, gegen die kreuzsignierte scheitern kann.

Sehen Sie im Leaf nach, statt zu raten: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Vergleichen Sie dann beide Kandidaten mit openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" und denselben Befehl gegen die selbstsignierte Kopie.

Trägt das Leaf Aussteller und Seriennummer, vervollständigt nur das Zertifikat die Kette, das diese Werte beschreibt, welche Kopie ein Client auch geladen hat.

Prüfung 3: Ausstellungsrichtlinie ändern, niemals signierte Bytes

Erweiterungen liegen innerhalb der Signatur. Eine auf einem bestehenden Leaf hinzuzufügen, zu entfernen oder zu bearbeiten ist keine Reparatur, es ist ein anderes Zertifikat und erfordert eine Neuausstellung. Die Änderung gehört in die Ausstellungsrichtlinie: authorityKeyIdentifier = keyid,issuer:always lässt neue Leafs die zertifikatsspezifische Bindung tragen, während keyid allein die lockerere Form beibehält, die zu einem bewussten Kreuzsignierungsübergang passt. Entscheiden Sie, welche Ihre PKI will, bevor der nächste Batch signiert wird.

Das Bearbeiten einer gemeinsamen Vorlage ändert auch jedes künftige Zertifikat, nicht nur den Server vor Ihnen.

Prüfung 4: Jede Vertrauenspopulation getrennt verifizieren

Testen Sie den alten und den neuen Pfad als getrennte Läufe. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem übt die kreuzsignierte Route, und derselbe Befehl mit der neuen Root und ohne untrusted-Datei übt die selbstsignierte Route. Beide Roots in einem Bundle zu mischen verdeckt, welche Kette ausgewählt wurde. Wiederholen Sie es danach mit echten Clients, denn ein VPN-Backend kann eine Kette bevorzugen oder ein Zertifikat pinnen auf Arten, die openssl nicht kennt.

Liefern Sie das Zwischenzertifikat über die Dienstkonfiguration aus, die der Client tatsächlich liest, nicht über eine Wiki-Seite.

Prüfung 5: Den alten Pfad auf einer Abschaltuhr halten

Kreuzsignierung hält einen alten Vertrauenspfad konstruktionsbedingt am Leben, was zugleich der Zweck und das Risiko ist. Sie behebt keine kompromittierte alte Root und entfernt diese Root aus keinem Client. Schreiben Sie auf, wann der alte Pfad kein Vertrauen mehr vergibt, und stellen Sie sicher, dass dieser Tag tatsächlich kommt.

Wenn jeder Client die neue Root übernehmen kann, bevor die Leafs wechseln, ist ein einfaches Dual-Trust-Rollout einfacher als Kreuzsignierung, und es bleibt eine Sache weniger abzuschalten.