Kettenhierarchie und Zwischenzertifikate

Die öffentlichen Wurzeln von Sectigo genießen in der Branche das gleiche Vertrauen wie alle anderen. Tatsächlich übersteigt Sectigos Root-Ubiquität 99,99% der heute verwendeten Systeme und beträgt 100% für moderne Browser, Mobilgeräte und Betriebssysteme.

Als ein Rebrand des Unternehmens, das früher als Comodo CA bekannt war, besitzt und betreibt Sectigo alle alten Comodo-Wurzeln.

Im Januar 2019 haben wir unser Sectigo-Intermediate auf unserer alten USERTrust-Wurzel eingeführt. Dieses Stammverzeichnis hat sich seit diesem Datum in der Produktion als zuverlässig erwiesen und verfügt über eine allgegenwärtige Browserkompatibilität.

Unternehmenskunden haben die Wahl, die neue Wurzel der Marke Sectigo oder die alte Wurzel der Marke Comodo auf unbestimmte Zeit zu verwenden.

Was ist Root? Was ist Mittelstufe?

Ein «Root» -Zertifikat ist im Allgemeinen ein Zertifikat, das selbst signiert ist (derselbe Betreff und derselbe Aussteller), das jedoch auch von einem Anbieter in einem vertrauenswürdigen Root-Speicher enthalten ist.
Wir sprechen allgemein von 3 Stammzertifikaten (5, wenn Sie die ECC-Varianten von COMODO CA und USERTRUST einschließen, die ich hier nicht angegeben habe):

AddTrust External CA-Stamm:
https://crt.sh/?id= 1
Verwendet sha1WithRSAEncryption. Läuft im Mai 2020 ab.

USERTrust RSA-Zertifizierungsstelle:
https://crt.sh/?id=1199354
Verwendet sha384WithRSAEncryption. Läuft im Januar 2038 ab.

COMODO RSA CA:
https://crt.sh/?id=1720081
Verwendet sha384WithRSAEncryption. Läuft im Januar 2038 aus.

Das AddTrust-Zertifikat ist im Besitz von Sectigo und wurde vor vielen Jahren erworben. COMODO und USERTrust wurden von Sectigo (damals Comodo) erstellt.
AddTrust ist in einigen Root-Programmen schon länger enthalten als die neueren Wurzeln von SHA-2 COMODO / USERTrust.

Obwohl die Anzahl der Plattformen sehr gering ist, gibt es immer noch einige Plattformen, die aus verschiedenen Gründen möglicherweise nicht die neueren SHA-2-Wurzeln haben. Da wir diese neueren Stammzertifikate generiert haben, haben wir auch Gegenzertifikate signiert, bei denen die AddTrust-Zertifizierungsstelle zum Signieren der einzelnen SHA-2-Zertifizierungsstellen verwendet wurde. Ein Beispiel für die von AddTrust signierte USERTrust RSA-Zertifizierungsstelle: https://crt.sh/?id=4860286

(Es ist zu beachten, dass die AddTrust-Zertifizierungsstelle selbst SHA-1 verwendet, diese jedoch kein Sicherheitsrisiko darstellt. Die Probleme mit SHA-1 bestanden in der Machbarkeit von Kollisionen, die vorab berechnet werden konnten, aber diese Risiken manifestieren sich sich selbst, wenn * neue * Zertifikate erstellt werden und nicht, wenn bereits ein Zertifikat mit SHA-1 erstellt und verteilt wurde. Aus diesem Grund haben die verschiedenen Stammprogramme von Microsoft, Mozilla, Apple und Google diese weiterhin berücksichtigt und keine Bedenken hinsichtlich einer Verkettung mit diesen (Ältere Wurzeln. Natürlich laufen viele von ihnen kurzfristig aus und werden daher bald nicht mehr verwendet.)

Jetzt mit diesen Gegenzertifikaten und dem im Mai 2020 auslaufenden AddTrust
Wir können mit Sicherheit sagen, dass moderne Clients von diesem Ablaufdatum nicht betroffen sind. Browser wählen einfach eine Kette direkt zum SHA-2-Stamm (COMODO oder USERTrust) und das Gegenzertifikat zurück zu AddTrust wird einfach ignoriert.
Die meisten Pathbuilder ignorieren dies aufgrund des Ablaufs. Außerdem müssen Clients in den TLS-RFCs nicht die Schachtelung der Ablaufdaten überprüfen, sodass ein End-Entity-Zertifikat nach dem Ablauf eines Zertifikats «weiter oben» abläuft. Die Kette ist nicht problematisch.

Die einzigen Clients, die Probleme hätten, wären diejenigen, die * nicht * die neueren Wurzeln enthalten, aber AddTrust haben. Ein Beispiel könnte eine
unglaublich alte EoL-Android-Version sein.

(Die Verwendung der AddTrust-Cross-Zertifikate setzt natürlich voraus, dass der Client das Zertifikat zwischengespeichert hat, AIA-URLs zum Abrufen abruft oder dass der
Server das Cross-Zertifikat im TLS-Handshake bereitstellt.)

Das dokumentierte Verhalten, wenn eine Endentität eine Gültigkeitsdauer hat, die größer als der Wert von ‹SHA1 ROOT› ist, wenn dies der Standardanker ist, der auf einer Maschine vorhanden ist.
Wenn AddTrust der «einzige» Anker ist, wird das End-Entity-Zertifikat nach Ablauf von AddTrust Ende Mai 2020 Fehler erzeugen. Vorher sollten Kunden keine Fehler haben, da TLS keine Überprüfungsanforderungen enthält. Aber es besteht natürlich die Möglichkeit, dass esoterischere Kunden die Spezifikation ignorieren und versuchen, sie zu überprüfen.

Die folgende Abbildung zeigt unsere Vertrauenskette.

Wichtige Notiz:Wenn unser AddTrust External CA Root abläuft, wird die Vertrauenskette A nicht mehr von Kunden verwendet, sondern über die Vertrauenskette B

verkettet. Die Überprüfung des Zertifizierungspfads erfolgt clientseitig automatisch und es sollten keine Änderungen am Kundenende erforderlich sein. *** Das Testen wird weiterhin empfohlen. Für weitere Informationen wenden Sie sich bitte an den Support. ***

Vertrauenskettenpfad A:
AddTrust Externer CA-Stamm [
Stamm ] USERTrust RSA-Zertifizierungsstelle (Intermediate) [Intermediate 2]
Sectigo RSA DV / OV / EV-Sicherheitsserver CA [Intermediate 1]
End-Entität [Leaf-Zertifikat]

Vertrauenskettenpfad B:
USERTrust RSA-Zertifizierungsstelle (Root-CA) [Root]
Sectigo RSA DV- / OV- / EV-Sicherheitsserver CA [Intermediate 1]
End-Entität [Leaf-Zertifikat]