Zur Hauptnavigation springen Zum Inhalt springen

HPKP - Als Erweiterung von HTTP HTTP Public Key Pinning - Der Schutz vor angegriffenen Zertifizierungsstelle

Wie funktioniert das Public Key Pinning mittels HPKP?

Public Key Pinning, kurz HPKP, gehört zu den Verfahren, die die Sicherheit von SSL-Zertifikaten immens erhöhen können. Zweck von HPKP ist es, festzustellen, wann sich der öffentliche Schlüssel eines Zertifikats für einen bestimmten Host geändert hat. Dies kann ohne HPKP etwa dann passieren, wenn ein Angreifer eine Certification Authority (CA) dermaßen beeinträchtigt, dass gültige Zertifikate für beliebige Domains ausgegeben werden können. Ein recht prominentes Beispiel dafür war die Ausstellung falscher Microsoft-Zertifikate, über die wir in unserem Blog berichtet haben.

Ist eine TLS-Verbindung mit dem Server hergestellt, sucht der Browser bei der Verwendung von HPKP jede gespeicherte Pin für den jeweiligen Hostnamen heraus und prüft, ob einer der gespeicherten Pins mit denen des SPKI-Fingerprints (= Ergebnis der SHA256-Anwendung auf die Public Key-Info) in der Zertifikatskette übereinstimmt. Scheitert diese Pin-Verifizierung, so muss die Verbindung unter HPKP sofort abgebrochen werden. Ist serverseitig kein HPKP konfiguriert oder unterstützt der Browser HPKP nicht, kommt die Verbindung dennoch zustande. 

HPKP: Wie wird gepinnt? Step-by-step Anleitung für HPKP beim Apache Webserver

Private Schlüssel generieren (einen primären und einen backup Key)

openssl genrsa -out www.hpkp-faq.de.key1.key 2048
openssl genrsa -out www.hpkp-faq.de.key1.key 2048

CSRs erstellen (für beide private Keys)

openssl req -new -sha256 -key www.hpkp-faq.de.key1.key -out www.hpkp-faq.de.csr
openssl req -new -sha256 -key www.hpkp-faq.de.key2.key -out www.hpkp-faq.de.backup-csr.csr

SPKI Fingerprints von beiden öffentlichen Schlüsseln generieren

openssl req -pubkey openssl dgst -sha256 -binary | base64
hIBFVXDUBPQgeRapi9m71<wbr />27NhGkTc+QS4EHq2LyBA=
openssl req -pubkey -outform der | openssl dgst -sha256 -binary | base64
ZrYB07EvOX0HjbBTjJp3lt2<wbr />2nGJGqYDGU21ZnBzb8=

virtual Host Konfiguration anpassen

Header always set Public-Key-Pins-Report-Only: ‚max-age=5184000;
pin-sha256=“hIBFVXDUBPQgeRapi9mRB7<wbr />127NhGkTc+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt2<wbr />2nGJGqYDGU21ZnBzb8=“‘

Pinnen der beiden öffentlichen Schlüssel

Alternativ gibt es die Möglichkeit, vorab im Testmodus zu starten. Hierfür geben Sie "Header always set Public-Key-Pins-Report-Only" anstatt "Header always set Public-Key-Pins"an:

Header always set Public-Key-Pins-Report-Only: ‚max-age=5184000;
pin-sha256=“hIBFVXDUBPQgeRapi9mRB71<wbr />27NhGkTc+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22<wbr />nGJGqYDGU21ZnBzb8=“‘

Reporting anschalten

Beim HTTP Public Key Pinning (HPKP) gibt es die Möglichkeit, sich vom zugreifenden Browser, Fehlermeldungen anzeigen zu lassen. Allerdings wird dies erst mit der Chrome Version 46 unterstützt. Die persönliche URL wird mit dem Flag „report-uri“ ebenfalls in die virtual Host Konfiguration eingebaut:

Header always set Public-Key-Pins: ‚max-age=5184000;
pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGkTc+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“;
report-uri=“https://report-uri.io/report/559ec66014bc9434bab6626345a017f3“‘

Über Qualys ssllabs Test können Sie Ihre Konfiguration testen. Nutzen Sie
hierfür: https://www. ssllabs.com/ssltest/ oder 
vorzugsweise https://dev.ssllabs.com/ssltest/.

HTTP-Erweiterung HPKP: wie soll der Header aussehen?

Mittels curl – I https:// www.beispiel.de können Sie sich den Header auf der Konsole anzeigen lassen. 

Der HTTP Header bei HPKP kann wie folgt aussehen:

HTTP/1.1 200 OK
Date: Thu, 12 Nov 2015 10:45:37 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Public-Key-Pins: max-age=5184000; pin-sha256=“hIBFVXDUBPQgeRapi9mRB7127NhGGkT c+QS4EHq2LyBA=“;
pin-sha256=“ZrYB07EvOX0HjbBTjJp3lEMt22nGJGqYDGU21ZnBzb8=“;
report-uri=“https://report-uri.io/report/559ec66014bc9434bab6626345a017f3“
X-Powered-By: PHP/5.5.30 Content-Type: text/html; charset=UTF-8

Der Header spezifiziert für HPKP mindestens pin-sha256 Werte, d. h.: die Pins von zwei öffentlichen Schlüsseln. Dabei ist ein Pin der eines beliebigen öffentlichen Schlüssels, der sich in der aktuellen Zertifikatskette befindet, der andere ist der eines beliebigen öffentlichen Schlüssels, der sich nicht in der aktuellen Zertifikatskette befinden muss. Bei letzterem könnte es sich einen Backup-Schlüssel handeln, der beispielsweise dann zum Einsatz kommt, wenn Ihr Zertifikat abläuft oder zurückgezogen werden muss.

Welche Informationen enthält das HPKP-Zertifikat?

Senden Sie die Certificate Signing Request (CSR) mit Ihrem öffentlichen Schlüssel an eine Zertifizierungsstelle, stellt Ihnen diese ein gültiges Zertifikat aus. Dieses enthält den öffentlichen Schlüssel des RSA-Schlüsselpaars sowie ein Ablaufdatum. Sowohl der öffentliche Schlüssel als auch das Ablaufdatum werden von der Zertifizierungsstelle signiert, sodass jedwede Veränderungen an diesen beiden Komponenten das Zertifikat sofort ungültig werden lassen. X.509-Zertifikate enthalten auch andere Bereiche, um TLS-Verbindungen vernünftig zu authentifizieren, etwa den Hostnamen Ihres Servers sowie weitere Details.

Wie können RSA-Schlüssel für die Verwendung von HPKP erstellt werden?

Mit dem Befehl

openssl genrsa 2048

Erzeugen Sie einen 2.048-bit-RSA-Schlüssel und geben ihn auf der Konsole aus. Wenngleich es -----BEGIN RSA PRIVATE KEY----- heißt, wird nicht ausschließlich der private Schlüssel ausgegeben, sondern auch die ASN.1-Struktur, die ebenfalls einen öffentlichen Schlüssel enthält. So erzeugen Sie also ein RSA-Schlüsselpaar. Ein weit verbreiteter Irrtum in der Kryptographie besteht darin, dass der RSA-Schlüssel selbst für ein bestimmtes Zertifikat ablaufen kann. RSA-Schlüssel laufen jedoch nie ab – es sind letztlich nur Zahlen. Das Zertifikat jedoch, das den öffentlichen Schlüssel enthält, kann sehr wohl ablaufen. Deshalb kann auch nur das Zertifikat zurückgezogen werden. Die Schlüssel selbst laufen ab oder werden zurückgezogen, sobald es keine gültigen Zertifikate mehr gibt, die eben diesen öffentlichen Schlüssel verwenden, oder wenn Sie den Schlüssel vernichtet haben oder überhaupt aufgehört haben, diesen zu verwenden.

Was tun, wenn Sie Ihr Zertifikat ersetzen müssen?

Läuft Ihr Zertifikat für die Verwendung von HPKP ab oder wurde Ihr privater Schlüssel kompromittiert, müssen Sie Ihr Zertifikat womöglich zurückziehen, in jedem Fall aber ersetzen. Dies kann dazu führen, dass Ihr Pin ungültig wird: die Beschränkungen, die beim Kauf eines neuen gültigen Zertifikat existieren, sind dieselben, vor denen Angreifer stehen, die versuchen, Ihre Identität anzunehmen und Ihre TLS-Sitzung abzufangen.

Die Pin-Verifikation verlangt, dass sämtliche SPKI-Fingerprints aller Zertifikate einer Kette überprüft werden, und sie gelingt in dem Moment, in dem einer der öffentlichen Schlüssel zu einem der Pins passt. Nehmen wir an, Zertifizierungsstelle XY hat Ihr Zertifikat signiert und Sie haben ein weiteres Class 1- oder Class 2-Zwischenzertifikat sowie deren Root-Zertifikat in der Kette: der Browser vertraut ausschließlich dem Root-Zertifikat, jedoch werden die Zwischenzertifikate vom Root-Zertifikat signiert. Das Zwischenzertifikat wiederum signiert das auf den Server ausgelieferte Zertifikat. Dies nennt man Vertrauenskette. Haben Sie nun Ihr Zwischenzertifikat gepinnt, ist die einzige Option der Wiederherstellung der Backup-Key. Auf was auch immer dieser verweist, muss im neuen Zertifikat gespeichert sein, wenn Sie jene Benutzer auf Ihrem Server wieder zulassen möchten, die Ihren Pin aus vorherigen Sitzungen gespeichert haben.

Eine einfachere Lösung wäre sicherlich, wenn Sie den SPKI-Fingerprint aus dem Zwischenzertifikat Class 1 verfügbar machen. Um eine neue und gültige Zertifikatskette zu schaffen, bitten Sie Ihre Zertifizierungsstelle, ein neues Zertifikat für einen neuen oder Ihren aktuellen Schlüssel auszustellen. Mit einer etwas größeren Angriffsfläche zahlen Sie jedoch einen Preis dafür, denn jemand, der den privaten Schlüssel des Zwischenzertifikats gestohlen hat, wäre nun in die Lage versetzt, Ihre Seite zu imitieren und Key Pinning-Prüfungen erfolgreich zu durchlaufen.

Eine andere Option besteht darin, das Root-Zertifikat mittels HPKP zu pinnen. Jedes beliebige, durch die CA ausgestellte Zertifikat würde es Ihnen erlauben, eine neue gültige Zertifikatskette zu erstellen. Auch dadurch würde sich die Angriffsfläche dezent erhöhen, da jedes beeinträchtigte Zwischen- oder Root-Zertifikat es gestatten kann, Ihre Seite zu imitieren und Pinning-Checks zu bestehen.

Welcher Schlüssel soll gepinnt werden?

In Anbetracht all der genannten Szenarien fragen Sie sich vielleicht, welchen Schlüssel Sie am besten fürs Pinnen mit HPKP verwenden, und die Antwort kann nur lauten: Das kommt darauf an. Sie können einen oder alle öffentlichen Schlüssel in Ihrer Zertifikatskette pinnen, und das wird funktionieren. Die Spezifikation verlangt, dass Sie mindestens zwei Pins haben, sodass Sie den SPKI-Hash eines anderen Rootzertifikats einfügen müssen, ein anderes Zwischenzertifikat (eine andere Stufe Ihrer aktuellen CA würde auch funktionieren) oder ein anderes untergeordnetes Zertifikat. Die einzige Anforderung ist: Der Pin entspricht nicht dem Hashwert von irgendeinem Zertifikat innerhalb der aktuellen Kette. Der Browser kann nicht feststellen, ob Sie ihm ein gültiges, sinnvolles Backup bereitgestellt haben - weshalb er auch gerne Zufallswerte akzeptiert.

Beim Pinnen auf eine kleine Auswahl von CAs zurückzugreifen, bei denen Sie sich wohl und sicher fühlen, hilft Ihnen, das Risiko bei der Verwendung von HPKP weiter einzuschränken. Beim Pinnen nur Ihre untergeordneten Zertifikate zu verwenden, birgt ein erhöhtes Risiko, bietet jedoch mehr Sicherheit. Es ist ein bisschen wie Fahren ohne Gurt: Es funktioniert meistens, aber falls etwas schiefgeht, geht es in aller Regel so richtig schief. Und das wollen Sie sicherlich vermeiden.

Wenn Sie bei HPKP ausschließlich Ihre untergeordneten Zertifikate pinnen, besteht außerdem die Gefahr, dass Sie einen Backup-Schlüssel generieren, der an Uraltstandards festhält und vielleicht nicht mehr benutzt werden kann, wenn Sie Ihr aktuelles Zertifikat ersetzen müssen. Drehen wir die Uhr drei Jahre zurück. Ihr Backup-Key ist ein 1.024-Bit-RSA-Schlüsselpaar. Sie pinnen für ein Jahr, dann läuft das Zertifikat ab. Sie gehen zur CA und bitten um ein neues Zertifikat für Schlüssel A, die CA sagt jedoch, dass der Schüssel zu kurz und zu schwach ist. Sie fragen nach dem Backup-Schlüssel, der ebenfalls zurückgewiesen wird, weil er zu kurz ist. Ergebnis: Weil Sie beim Pinnen nur von Ihnen kontrollierte Schlüssel verwendet haben, sind sie nun quasi eingemauert bzw. sperren potenzielle Besucher Ihrer Website aus.

Das Ende von HPKP

HTTP Public Key Pinning hat seinen Dienst geleistet – doch langsam nähert sich die Technik für Zertifikats-Pinning dem Ende ihrer Amtszeit. HPKP hat erstmalig einen Schutzmechanismus geschaffen, der anderweitig nicht möglich war. Doch mit diesem Schutz gingen auch Möglichkeiten einher, diesen Sicherheitsmechanismus auszunutzen. Die Begriffe „HPKP Suicide“ und „Ransom HPKP“ geben bereits einen Eindruck darüber, was mit HPKP im negativen Sinne machbar ist. Ab einem gewissen Punkt war sichtbar, dass HPKP mehr Probleme kreierte, als es löste und somit entschieden sich nun Firefox und Chrome diesem Verfahren nicht mehr zu vertrauen. Da es mittlerweile kaum noch Browser gibt, die die HPKP-Reports senden, ist es für Sie nun an der Zeit, dass HPKP von Ihrer Webseite verschwindet. 

Maßnahmen zum Schutz gegen unberechtigt ausgestellte Zertifikate

Fragen/Problem CT (Certificate Transparency) CAA (Certificate Authority Authorization) Pinning

Fähigkeit, vor der Ausgabe von gefälschten Zertifikaten zu schützen

Nein

Eingeschränkt -abhängig von den CAA Geschäfts­bedingungen, Einhaltung durch alle CAs

Nein

Fähigkeit, gefälschte Zertifikate nach der Ausgabe zu erkennen

Hoch - aber nur, wenn der Eigentümer der Zieldomain alle CT-Logs überwacht (mögliche Verzögerung bis zur Entdeckung)

Nein

Hoch - Chrome's hard-coded PINs haben erfolgreich schwere Fälle von Ausgaben falscher Zertifikate erkannt

Fähigkeit, gefälschte Zertifikate nach der Ausgabe/Erteilung zu erkennen - in Ländern mit geschlossenem oder überwachtem DNS (Domain Name System)

Hoch - Zertifikat muss in mehreren öffentlichen Logs enthalten sein, andernsfalls werden die Browser die aufgerufene Seite nicht verschlüsselt aufrufen können

Nein

Eingeschränkt - Browser können die Seiten nicht verschlüsselt aufrufen, sind aber auch nicht in der Lage, den Fehler zu melden

Hard-Fail zum Schutz des Users?

Ja (wenn das Zertifikat nicht durch CT-Logs signiert wurde) - aber gefälschte Zertifikate, die durch das CT-Logs signiert wurden, werden als gültige Zertifikate behandelt, kein hard-fail

Nein

Ja - hard-fail, die Seite wird nicht verschlüsselt aufgerufen werden können

Widerrufbarkeit von gefälschten Zertifikaten

verbessert die Möglichkeit, die Ausgabe von falschen Zertifikaten zu erkennen, aber nur wenn der Domaininhaber die CT Logs überwacht

Keine Änderung des aktuellen Systems. Keine einfache Möglichkeit für den Besitzer oder den Nutzer, gefälschte Zertifikate zu erkennen.

HPKP (HTTP Public Key Pinning) (unter der Annahme eines hard-fail) entspricht einer Annullierung des nicht gepinnten Zertifikats - von der CA zurückgezogene Zertifikate

Potenzielle Verzögerung/Leistungs-Probleme

Nein - bezogen auf die Benutzer, aber die CT-Logs müssen hochverfügbar sein, sonst stellen die CAs keine Zertifikate aus (erzeugt eine neue Abhängigkeit)

Nein
Nein

DOS-Probleme

Mögliche Probleme - wenn die CT-Logs geblockt sind, können keine Zertifikate ausgegeben werden und die CT Logs können in den entscheidenen Momenten nicht überwacht werden - aber es existieren mehrere CT Logs

Nein
Nein

Skalierbarkeit­sprobleme

Signifikant - wenn Hochverfügbarkeits-Infrastruktur vorhanden ist, dann ist die Skalierbarkeit gegeben

Nein

Nein - HPKP kann derzeit PINs in Browsern wie Chrome festcodiert skalieren

Probleme bei der Privatspäre von Benutzern

Hoch - alle ausgestellten Zertifikate würden sofort für die Öffentlichkeit zugänglich und könnten kopiert werden

Niedrig - CA Voreinstellung für Domains sind in einem öffentlich zugänglichen DNS-Eintrag ersichtlich

Niedrig - Hashes von öffentlichen Schlüsseln der Websites sind im DNS-Record ersichtlich

Anforderungen an CAs

Hoch (Komplex, ungewisse Kosten, schafft externe Abhängigkeiten)

Mittel (abhängig von den vereinbarten Geschäftsregeln) zusätzliche Kundenkom­munikation wird benötigt, potenzieller Konkurrenzkampf

Niedrig - CAs müssen den Kunden vermitteln, wie sie mit den Auswirkungen beim Ändern von Zwischen- oder Stammzertifikaten umzugehen haben (wenn Zwischen- oder Stammzertifikate genutzt wurden)

Anforderungen an den Browser

Hoch (für den User-Agent des Browsers müssen die gewählten CT-Logs ausgewiesen werden, denen er vertraut. Diese Logs müssen geprüft werden und es muss sichergestellt werden, dass dieser Agent Zertifikate anhand der CT-Logs überwacht)

Nein

Eingeschränkt - Browser Benutzerprogramme müssen geändert werden, um den Benutzerschlüssel Hash mit dem Pinning Informationen im DNS, den gespeicherten PINs, Warnungsanzeigen oder hard-fail zu überprüfen

Anforderungen an Domain-Inhaber

Eingeschränkt (Eigentümer, die Wert darauf legen, ihre CT-Logs selber zu überwachen oder für den Überwachungs­service zu bezahlen. Alle Unternehmen müssen eine zentrale Aufzeichnung über alle gültigen Zertifikate ihrer Organisation haben) CT erfordert, dass alle DomainEigentümer durch die Auflistung ihrer Zertifikate in den öffentlichen CT-Logs teilnehmen

Eingeschränkt für teilnehmende Domain-Besitzer - es müssen alle erlaubten CAs in allen DNS-Einträgen aufgelistet sein

Hoch für teilnehmende Domain-Besitzer - Domain-Inhaber müssen alle Pinning-Aufzeichnungen für alle gültigen Zertifikate aktualisiert auf allen Servers bereithalten, sonst könnte der Zugang zur Webseite blockieren

Fähigkeit, vor der Ausgabe von gefälschten Zertifikaten zu schützen

CT (Certificate Transparency)
Nein
CAA (Certificate Authority Authorization)

Eingeschränkt -abhängig von den CAA Geschäfts­bedingungen, Einhaltung durch alle CAs

Pinning
Nein

Fähigkeit, gefälschte Zertifikate nach der Ausgabe zu erkennen

CT (Certificate Transparency)

Hoch - aber nur, wenn der Eigentümer der Zieldomain alle CT-Logs überwacht (mögliche Verzögerung bis zur Entdeckung)

CAA (Certificate Authority Authorization)
Nein
Pinning

Hoch - Chrome's hard-coded PINs haben erfolgreich schwere Fälle von Ausgaben falscher Zertifikate erkannt

Fähigkeit, gefälschte Zertifikate nach der Ausgabe/Erteilung zu erkennen - in Ländern mit geschlossenem oder überwachtem DNS (Domain Name System)

CT (Certificate Transparency)

Hoch - Zertifikat muss in mehreren öffentlichen Logs enthalten sein, andernsfalls werden die Browser die aufgerufene Seite nicht verschlüsselt aufrufen können

CAA (Certificate Authority Authorization)
Nein
Pinning

Eingeschränkt - Browser können die Seiten nicht verschlüsselt aufrufen, sind aber auch nicht in der Lage, den Fehler zu melden

Hard-Fail zum Schutz des Users?

CT (Certificate Transparency)

Ja (wenn das Zertifikat nicht durch CT-Logs signiert wurde) - aber gefälschte Zertifikate, die durch das CT-Logs signiert wurden, werden als gültige Zertifikate behandelt, kein hard-fail

CAA (Certificate Authority Authorization)
Nein
Pinning

Ja - hard-fail, die Seite wird nicht verschlüsselt aufgerufen werden können

Widerrufbarkeit von gefälschten Zertifikaten

CT (Certificate Transparency)

verbessert die Möglichkeit, die Ausgabe von falschen Zertifikaten zu erkennen, aber nur wenn der Domaininhaber die CT Logs überwacht

CAA (Certificate Authority Authorization)

Keine Änderung des aktuellen Systems. Keine einfache Möglichkeit für den Besitzer oder den Nutzer, gefälschte Zertifikate zu erkennen.

Pinning

HPKP (HTTP Public Key Pinning) (unter der Annahme eines hard-fail) entspricht einer Annullierung des nicht gepinnten Zertifikats - von der CA zurückgezogene Zertifikate

Potenzielle Verzögerung/Leistungs-Probleme

CT (Certificate Transparency)

Nein - bezogen auf die Benutzer, aber die CT-Logs müssen hochverfügbar sein, sonst stellen die CAs keine Zertifikate aus (erzeugt eine neue Abhängigkeit)

CAA (Certificate Authority Authorization)
Nein
Pinning
Nein

DOS-Probleme

CT (Certificate Transparency)

Mögliche Probleme - wenn die CT-Logs geblockt sind, können keine Zertifikate ausgegeben werden und die CT Logs können in den entscheidenen Momenten nicht überwacht werden - aber es existieren mehrere CT Logs

CAA (Certificate Authority Authorization)
Nein
Pinning
Nein

Skalierbarkeit­sprobleme

CT (Certificate Transparency)

Signifikant - wenn Hochverfügbarkeits-Infrastruktur vorhanden ist, dann ist die Skalierbarkeit gegeben

CAA (Certificate Authority Authorization)
Nein
Pinning

Nein - HPKP kann derzeit PINs in Browsern wie Chrome festcodiert skalieren

Probleme bei der Privatspäre von Benutzern

CT (Certificate Transparency)

Hoch - alle ausgestellten Zertifikate würden sofort für die Öffentlichkeit zugänglich und könnten kopiert werden

CAA (Certificate Authority Authorization)

Niedrig - CA Voreinstellung für Domains sind in einem öffentlich zugänglichen DNS-Eintrag ersichtlich

Pinning

Niedrig - Hashes von öffentlichen Schlüsseln der Websites sind im DNS-Record ersichtlich

Anforderungen an CAs

CT (Certificate Transparency)

Hoch (Komplex, ungewisse Kosten, schafft externe Abhängigkeiten)

CAA (Certificate Authority Authorization)

Mittel (abhängig von den vereinbarten Geschäftsregeln) zusätzliche Kundenkom­munikation wird benötigt, potenzieller Konkurrenzkampf

Pinning

Niedrig - CAs müssen den Kunden vermitteln, wie sie mit den Auswirkungen beim Ändern von Zwischen- oder Stammzertifikaten umzugehen haben (wenn Zwischen- oder Stammzertifikate genutzt wurden)

Anforderungen an den Browser

CT (Certificate Transparency)

Hoch (für den User-Agent des Browsers müssen die gewählten CT-Logs ausgewiesen werden, denen er vertraut. Diese Logs müssen geprüft werden und es muss sichergestellt werden, dass dieser Agent Zertifikate anhand der CT-Logs überwacht)

CAA (Certificate Authority Authorization)
Nein
Pinning

Eingeschränkt - Browser Benutzerprogramme müssen geändert werden, um den Benutzerschlüssel Hash mit dem Pinning Informationen im DNS, den gespeicherten PINs, Warnungsanzeigen oder hard-fail zu überprüfen

Anforderungen an Domain-Inhaber

CT (Certificate Transparency)

Eingeschränkt (Eigentümer, die Wert darauf legen, ihre CT-Logs selber zu überwachen oder für den Überwachungs­service zu bezahlen. Alle Unternehmen müssen eine zentrale Aufzeichnung über alle gültigen Zertifikate ihrer Organisation haben) CT erfordert, dass alle DomainEigentümer durch die Auflistung ihrer Zertifikate in den öffentlichen CT-Logs teilnehmen

CAA (Certificate Authority Authorization)

Eingeschränkt für teilnehmende Domain-Besitzer - es müssen alle erlaubten CAs in allen DNS-Einträgen aufgelistet sein

Pinning

Hoch für teilnehmende Domain-Besitzer - Domain-Inhaber müssen alle Pinning-Aufzeichnungen für alle gültigen Zertifikate aktualisiert auf allen Servers bereithalten, sonst könnte der Zugang zur Webseite blockieren

Wie funktioniert Certification Authority Authorization?

Wie funktioniert Certificate Transparency?

Sie haben Fragen? Unser technischer Support steht Ihnen bei weiteren Fragen gerne zur Verfügung!