Anmerkung des Herausgebers: Dieser Blog wurde ursprünglich im April 2021 veröffentlicht. Er wurde seitdem aktualisiert, um neue Termine für die ICA-Rotation und die Abschaffung des OU-Feldes zu nennen und um zusätzliche Informationen über die Änderungen bei der Verwendung von ECC-Schlüsseln und den dahinter stehenden Gedankengang bereitzustellen.
Das CA/Browser Forum und die Root-Programme legen Anforderungen fest, die CAs einhalten und gegen die sie geprüft werden müssen, um einheitliche Anforderungen für alle CAs zu schaffen und Website-Besucher zu schützen. Sie legen wichtige Compliance- und Sicherheitsanforderungen fest. Sie alle wissen, dass die maximale Gültigkeit für TLS-Zertifikate von 5 Jahren auf 3 Jahre, 825 Tage und erst letzten September auf 397 Tage (ca. 13 Monate) reduziert wurde. In diesem Beitrag möchten wir Sie über einige der bevorstehenden Änderungen informieren, die von den Root-Programmen und/oder dem CA/B-Forum vorgeschrieben wurden.
Die CA DARF Domain-Namen und IP-Adressen nicht mehr als 398 Tage vor der Ausstellung des Zertifikats verifizieren
Datum des Inkrafttretens: 1. Oktober 2021
Im vergangenen September hat Apple eine maximale Gültigkeitsdauer von 398 Tagen vorgeschrieben, aber die Wiederverwendungsdauer der Domain- und Unternehmensvalidierung blieb bei 825 Tagen. Dies ist die zweite Stelle, wo der Schuh bei dieser Änderung drückt. Diese Verkürzung der Wiederverwendungsdauer von Domains wurde erwartet und wird wahrscheinlich nicht die letzte sein. Dies ergibt sich aus mehreren Studien, die herausgefunden haben, dass in bestimmten Fällen bei Domain-Besitzwechseln die bestehenden Zertifikate weiterhin von der vorherigen CA ersetzt/neu ausgestellt werden können. Eine Möglichkeit, hier Abhilfe zu schaffen, ist die Verkürzung des Zeitraums für die Wiederverwendung der Domain-Validierung.
Gehen wir einen Schritt zurück und betrachten wir die Situation auf diese Weise:
- Bis zur von Apple vorgeschriebenen Reduzierung der maximalen Gültigkeitsdauer betrug die Zeit zwischen der Domänenvalidierung und dem Ablauf des Zertifikats 825 + 825 Tage oder etwa 4 1/2 Jahre. Das ist eine lange Zeit!
- Mit Apples Reduzierung der maximalen Gültigkeit beträgt der Unterschied 825+398 Tage, was immer noch mehr als 3 Jahre sind
- Mit dieser neuesten Änderung beträgt der maximale Unterschied 398+398 oder etwas mehr als 2 Jahre.
- Zum Vergleich: Die CA, die die meisten Zertifikate pro Jahr ausstellt, Let's Encrypt, stellt Zertifikate mit einer maximalen Gültigkeit von 90 Tagen aus und sie verwenden die Domain-Validierung wieder für maximal 30 Tage, oder maximal 4 Monate zwischen Validierung und Ablauf des Zertifikats.
Es ist zu erwarten, dass sich die Branche auf die Let's Encrypt-Basiswerte zubewegt und diese eventuell sogar noch kürzer ausfallen werden.
Verbot der HTTP-Domain-Validierungsmethode für die Ausstellung von Subdomains und Wildcards
Datum des Inkrafttretens: 1. Dezember 2021
Die HTTP-Domain-Validierungsmethode (offiziell bekannt als Methode 6, Agreed-Upon Change to Website) wird häufig verwendet, um die Domain-Kontrolle zu überprüfen. Wenn Sie eine Datei in einem bestimmten Verzeichnis der Website ablegen können, "beweist" dies die Kontrolle über diese Domain. Im Gegensatz zu DNS haben Websites nicht die gleichen Kontrollmöglichkeiten, bei denen es eine formale Delegation von Berechtigungen von der Domain an Subdomains gibt. Wenn example.com also gehackt wurde oder sein Besitzer bestimmte böswillige Tendenzen hatte, können sie example.com genehmigen und dann Zertifikate an Subdomains ausstellen. Aber diese Subdomains könnten andere Entitäten sein, und wiederum, da es nicht die gleiche Ebene der formalen Delegation der Kontrolle gibt, schreibt Mozilla vor, dass die Ausstellung von Zertifikaten, die mit der HTTP-Methode validierte Domains enthalten, auf die Ausstellung genau der validierten Domain beschränkt ist. Mit anderen Worten: Wildcards und Subdomain-SANs werden für Domains, die mit der HTTP-Methode validiert wurden, verboten sein.
Dies wird Auswirkungen auf die Kunden haben, da es sich um eine gängige Methode zur Durchführung der Domain-Validierung handelt, und wenn Sie diese Methode weiterhin verwenden möchten, müssen Sie jedes SAN:DNSName einzeln validieren.
Dies wird Auswirkungen auf die Kunden haben, da es sich um eine gängige Methode zur Durchführung der Domain-Validierung handelt, und wenn Sie diese Methode weiterhin verwenden möchten, müssen Sie jedes SAN:DNSName einzeln validieren.
Rotation von ICAs in kürzeren Intervallen
Zeitrahmen: 13. Juli 2021 und 2022 dann vierteljährlich
GlobalSign wird mit der planmäßigen Rotation unserer Atlas TLS CAs beginnen, um eine gute Sicherheit und Agilität des Ökosystems zu fördern. In der Vergangenheit haben wir CAs eingerichtet und viele Jahre lang verwendet, aber es gibt viele Gründe, dieses Zeitintervall zu reduzieren. Durch die Reduzierung der Nutzungsdauer von CAs erzielen wir folgende Vorteile:
- Dies begrenzt die Anzahl der von einer einzelnen CA ausgestellten Zertifikate und des entsprechenden privaten Schlüssels, was unsere eigene Krypto-Agilität verbessert.
- Dies begrenzt die Auswirkungen, wenn es ein Integritäts-, Compliance- oder Sicherheitsproblem mit der CA gibt.
- Dies reduziert die Größe der CRLs, was die Validierungsleistung erhöht.
- Dies schult unseren Kundenstamm darin, einen sofortigen CA-Austausch zu erwarten und zu planen, was ihre Krypto-Agilität erhöht.
- Unser endgültiger Plan sieht vor, dass alle GlobalSign Atlas TLS CAs vierteljährlich und alle kundenbezogenen Atlas TLS CAs jährlich rotiert werden.
- Die erste Rotation der GlobalSign Atlas TLS CA für 2021 findet am 13. Juli 2021 statt.
- Ab 2022 werden wir die GlobalSign Atlas TLS CAs vierteljährlich am zweiten Montag des Quartals und jedes Jahr im Januar die kundenbezogenen Atlas TLS CAs updaten.
Auswirkungen und Empfehlungen:
- Kunden sollten immer darauf vorbereitet sein, neue CAs zu akzeptieren, wenn sie neue TLS-Zertifikate installieren. Die ausstellende CA ist in der API verfügbar und sollte beim Herunterladen des Zertifikats verwendet werden, damit die aktuelle CA immer mit dem ausgestellten Zertifikat versehen ist.
- Kunden MÜSSEN kein Public Key Pinning für CA-Zertifikate anwenden, und wir raten dringend davon ab, Public Key Pinning überhaupt anzuwenden, da dies den Zweck der Krypto-Agilität zunichtemacht.
- Wir empfehlen unseren Kunden, agile Praktiken für ausstellende CAs zu befolgen und immer die bereitgestellte ICA herunterzuladen und zu installieren, wenn sie neue Zertifikate erhalten.
- Bitte melden Sie sich hier für die GlobalSign Statusseite für wichtige Updates an - https://status.globalsign.com/
Weitere Informationen finden Sie auf unserer https://support.globalsign.com/atlas/atlas-tls
Änderungen bei der ECC-Schlüsselverwendung
Datum des Inkrafttretens: 26. Juli 2021
Wir werden die Schlüsselverwendung in unseren ECC-TLS-Zertifikaten ändern, um sie an die Best Practices der Branche und die laufenden Änderungen der CA/B Forum Baseline Requirements anzupassen. Derzeit schließen wir sowohl die digitale Signatur als auch die Schlüsselvereinbarung ein, aber ab diesem Datum werden wir dies ändern und nur die digitale Signatur einschließen.
Unser Public Trust TLS wird von Browsern und Webservern verwendet, um TLS-Sitzungen zum Schutz der Endnutzer zu unterstützen. Wir werden bei unseren Überlegungen zur Erstellung neuer Profile oder zur Ausstellung von CAs stets die Sicherheit der Nutzer dieser Zertifikate im Vordergrund halten. Es wurde beschlossen, dass die Notwendigkeit einer Schlüsselvereinbarung bei der Verwendung von ECC-Zertifikaten innerhalb eines TLS-Zertifikats nicht mehr erforderlich ist und gleichzeitig potenzielle Sicherheitsprobleme für die Endbenutzer mit sich bringt, da der Signierschlüssel und der Verschlüsselungsschlüssel innerhalb einer TLS-Sitzung getrennte Schlüssel sein sollten. Aus diesen Gründen wurde die Erweiterung aus unserem allgemeinen TLS-Angebot gestrichen. Kunden, die benutzerdefinierte Profile für Tools und Systeme außerhalb der Grenzen herkömmlicher Browser-zu-Server-TLS-Sitzungen benötigen, sollten unbedingt private Vertrauensangebote in Betracht ziehen.
Verbot der Verwendung des OU-Felds
Zeitrahmen: Aug 31, 2022
Google ist seit langem besorgt darüber, wie das OU-Feld in TLS-Zertifikaten validiert wird. Die Baseline Requirements haben klare Anforderungen für alle Subject-Felder (C, S, L, Org, etc.), die erfordern, dass die Daten von einem Business Repository bezogen werden; die Anforderung für das OU-Feld bleibt jedoch wie folgt:
Die CA WIRD einen Prozess implementieren, der verhindert, dass ein OU-Attribut einen DBA-Namen, Handelsnamen, eine Marke, eine Adresse, einen Standort oder einen anderen Text enthält, der sich auf eine bestimmte natürliche oder juristische Person bezieht, sofern die CA diese Information nicht geprüft hat.
Dies ermöglicht es Kunden, nicht validierte und möglicherweise irreführende Informationen bereitzustellen, auf die man sich (versehentlich) verlassen kann. Daher plädiert Google nachdrücklich für die Entfernung dieses Feldes.
Dieses Feld wird häufig von Unternehmen verwendet, um ihnen bei der Verwaltung der Zertifikate zu helfen, indem die Abteilung angegeben wird, zu der das Zertifikat gehört. Zertifikatsberichte helfen dem Unternehmen bei der Zuordnung von Erneuerungen und Ersetzungen auf der Grundlage dieses Feldes; der Zweck der Daten in Zertifikaten ist jedoch für vertrauende Parteien, d. h. diejenigen, die die Website besuchen und eine Entscheidung treffen möchten, ob sie der Website vertrauen sollen oder nicht, und nicht für die Zertifikatsverwaltung des Unternehmens.
Kunden müssen sich dieser bevorstehenden Änderung bewusst sein und mit der Planung für die Abschaffung des OU-Feldes beginnen. Obwohl noch kein Datum festgelegt wurde, werden wir die allgemeine Verwendung des OU-Feldes in den kommenden Monaten auslaufen lassen und für die Root-Programme Input sammeln, warum einige das OU-Feld weiterhin benötigen.
Haben Sie noch Fragen? Besuchen Sie unsere Support-Website für weitere Informationen und Möglichkeiten zur Kontaktaufnahme.
