TLS: Die ID für Domain Names, Teil 2: Validierungsformen und Zweck der Zertifizierungsstellen
Im ersten Teil unserer Blogserie zu TLS-Zertifikate wurde beschrieben, was diese sind und welche Art aspectra normalerweise verwendet. Die weiteren Möglichkeiten und kritischen Punkte werden in diesem Beitrag beleuchtet.
In bestimmten Fällen, in welchen dies durch den Kunden vorgegeben oder durch die Art der Verwendung notwendig wird, nutzen wir «Extended Validation» Zertifikate. Diese werden durch einen weltweit standardisierten Authentifizierungsprozess (aktuell: EV Guidelines Version 1.6.1) geprüft und ausgestellt. Die Anforderungen dafür sind:
- Die Identität und Geschäftsadresse des Antragsstellers müssen ausgewiesen werden
- Der Antragssteller muss der Eigentümer der angefragten Domain sein
- Der Handelsregistereintrag muss übereinstimmen mit dem Eigentümer sowie mit dem Namen der Domain
- Teilweise werden auch telefonische Überprüfungen durchgeführt
Im Unterschied zu den gewöhnlichen TLS-Zertifikaten gehört dieses der spezifischen Unternehmung und der Firmenname wird links von der Domain hervorgehoben.
Wenn wir einen Certificate Signing Request (CSR) erstellen, bleibt der Key dazu immer innerhalb der aspectra und verlässt diese nicht. In der CSR-Datei stehen alle benötigten Angaben (Registrierungsinformationen sowie der Public Key) für die Zertifizierungsstelle, damit diese das Zertifikat ausstellen kann.
Risiko: Zertifizierungsstellen
Der Sinn und Zweck einer Zertifizierungsstelle (Certificate Authority, CA) ist, dass der Besitzer des Zertifikates sowie der Benutzer, der das Zertifikat für die Überprüfung verwendet (bzw. sein Computer/Browser), dieser vertraut, genauso wie man einem Pass-Büro vertraut, wenn man sich einen neuen Pass ausstellen lässt. Die CA erstellt gemäss dem CSR ein Zertifikat und gibt dieses an dessen Ersteller zurück, der es dann auf seinem Server konfiguriert.
Der Schweizer Pass wird weltweit akzeptiert. Mit ihm können wir in beinahe jedes Land ohne grössere Probleme einreisen. Es gibt jedoch Länder, in denen unbedruckte, sogenannte Blanko -Pässe mitsamt Passmaschinen gestohlen wurden. Dort besteht das Risiko, dass nun falsche Pässe ausgestellt werden, was wiederum ein Sicherheitsrisiko bedeutet. Bei den Zertifizierungsstellen gibt es ähnliche Probleme. In letzter Zeit sind mehrere CA negativ in die Schlagzeilen geraten: Ob wegen unzureichender Überprüfung ihrer Partner und dem faktischen Verlust der Kontrolle über die Zertifizierungsinfrastruktur (Symantec), für die Ausstellung von Zertifikaten für die sie keine Berechtigungen hatten (Trustwave, Verisign, Symantec) oder betreffend Hackerattacken auf die Zertifizierungsstelle (Diginotar, Comodo). Im nächsten Blogeintrag gehen wir näher auf die Zertifizierungsstelle Let’s Encrypt ein.
Blogserie zu TLS-Zertifikate:
- Teil1, TLS: Die ID für Domain Names
- Teil3, «Let’s Encrypt»
Quellen:
- Google takes Symantec to the woodshed for mis-issuing 30,000 HTTPS certs
- Google Security Blog: Improved Digital Certificate Security / Symantec
- TLS-Zertifikate: Google greift gegen Symantec durch
- Gefälschte Zertifikate: Diginotar darf keine Signaturen mehr ausstellen
- Zertifikate: Grobe Sicherheitsmängel bei Diginotar
- Verisign, Inc. breach update: Symantec not compromised
- Trustwave issued a man-in-the-middle certificate
- TLS-Zertifikate: Comodo stellt fälschlicherweise Microsoft-Zertifikat aus
- SSL-Zertifikate: Weitere Einbrüche bei Comodo-Partnern
- SSL-Zertifikate: Noch ein Einbruch bei einem Comodo-Partner