Certificate Pinning einfach erklärt: HPKP und Pinning in Apps

Normalerweise akzeptiert ein Browser jedes gültige Zertifikat, das zu einer vertrauenswürdigen Root führt, egal von welcher der vielen Zertifizierungsstellen. Certificate Pinning schränkt das ein: Ein Programm akzeptiert für einen bestimmten Server nur ein festgelegtes Zertifikat oder einen festgelegten Schlüssel. Das schützt gegen falsch ausgestellte Zertifikate, kann aber eine Website oder App auch komplett lahmlegen. Dieser Artikel erklärt, wie Pinning funktioniert, warum der Web-Standard HPKP wieder abgeschafft wurde und wie Apps heute pinnen.

Was Pinning bedeutet

Ohne Pinning vertraut ein Programm jeder CA im Root Store; siehe Root Stores einfach erklärt. Stellt eine dieser CAs fälschlich ein Zertifikat für Ihre Domain aus, wird es akzeptiert. Beim Pinning hinterlegt man vorab, was erwartet wird:

das Endzertifikat selbst; ändert sich bei jeder Erneuerung,
den öffentlichen Schlüssel des Servers; bleibt gleich, solange der Schlüssel bei der Erneuerung wiederverwendet wird,
den Schlüssel eines Zwischen- oder Stammzertifikats; dann wird jedes Zertifikat dieser CA akzeptiert, aber keines einer anderen.

Gespeichert wird meist kein ganzes Zertifikat, sondern der SHA-256-Hash des öffentlichen Schlüssels (SPKI-Hash), Base64-kodiert. Für das Zertifikat von techuni.de lautete er im November 2026 2bfGpkOcywQtgZ/zMEMviVx+iFDMFApPA4+A8NHccI4=, für das Zwischenzertifikat YE1 von Let’s Encrypt brzvtCELCIZUo4sD/qPX0ccRtPsd3DY6RfmxpOU9oB4=. Berechnen lässt er sich so:

openssl x509 -in zertifikat.pem -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Drei Zeilen: Pin auf das Endzertifikat ist sehr fehleranfällig, Pin auf den Serverschlüssel hält bei Wiederverwendung, Pin auf eine CA erlaubt alle Zertifikate dieser CA. — Die drei Ebenen des Pinnings.

Statische Pins: wie DigiNotar aufflog

Chrome hat seit 2011 fest eingebaute Pins für Google-Domains. Genau diese Pins deckten im selben Jahr den Einbruch bei der CA DigiNotar auf: Ein Nutzer im Iran bekam ein gefälschtes, aber formal gültiges Zertifikat für Gmail, und Chrome schlug Alarm, weil es nicht zu den hinterlegten Schlüsseln passte. Solche statischen Pins für einige große Websites gibt es in Chrome und Firefox bis heute. Mehr zu diesem Fall und den Folgen in Certificate Transparency einfach erklärt.

HPKP: Pinning für alle Websites

2015 wurde mit HTTP Public Key Pinning (HPKP, RFC 7469) ein Weg standardisiert, wie jede Website ihre Pins selbst festlegen kann. Der Server schickte einen Header wie diesen:

Public-Key-Pins: pin-sha256="2bfGpkOcywQtgZ/zMEMviVx+iFDMFApPA4+A8NHccI4="; pin-sha256="Sicherungsschlüssel..."; max-age=5184000

Der Browser merkte sich die Pins für die angegebene Zeit, hier 60 Tage, und lehnte danach jedes andere Zertifikat ab. Ein zweiter Sicherungs-Pin für einen noch unbenutzten Schlüssel war Pflicht.

Warum HPKP abgeschafft wurde

HPKP erwies sich als gefährlicher als nützlich:

Selbstaussperrung: Verlor ein Betreiber seine Schlüssel oder wechselte unbedacht die CA, war seine Website für alle Besucher bis zum Ablauf von max-age blockiert, und niemand konnte das rückgängig machen.
Erpressung: Ein Angreifer, der einen Server kurz übernahm, konnte eigene Pins setzen und die Website damit monatelang unbrauchbar machen.
Kaum genutzt: Nur ein Bruchteil der Websites setzte HPKP ein, oft fehlerhaft.

Chrome erklärte HPKP 2017 für veraltet und entfernte es mit Chrome 72 im Januar 2019. Safari hatte es nie unterstützt, Firefox gab es ebenfalls auf. An seine Stelle trat Certificate Transparency: Statt Zertifikate vorab festzulegen, werden alle öffentlich protokolliert, sodass falsch ausgestellte Zertifikate auffallen. Dazu kommen CAA-Einträge im DNS; siehe CAA, DNSSEC und DANE.

Zeitleiste: 2011 statische Pins in Chrome, 2015 HPKP als RFC 7469, 2017 für veraltet erklärt, Januar 2019 in Chrome 72 entfernt. — Die kurze Geschichte von HTTP Public Key Pinning.

Pinning in Apps heute

In Smartphone-Apps lebt Pinning weiter, vor allem bei Banken, Bezahldiensten und Messengern. Die App spricht nur mit den Servern ihres Herstellers und kann die erwarteten Schlüssel mitbringen:

Android bietet in der Network Security Configuration ein pin-set mit Ablaufdatum: Nach diesem Datum ignoriert die App die Pins, statt den Dienst zu blockieren.
iOS kennt seit Version 14 den Eintrag NSPinnedDomains in der App-Konfiguration.
Bibliotheken wie OkHttp für Android erlauben Pins direkt im Code.

Pinning in Apps erschwert auch das Mitlesen des eigenen Datenverkehrs, etwa durch Sicherheitsforscher mit einem Analyse-Proxy. Das ist manchmal gewollt, ersetzt aber keine sichere Programmierung.

Zwei Spalten: Mit Ablaufdatum ignoriert die App veraltete Pins und läuft weiter, ohne Ablaufdatum scheitert die Verbindung bis zum App-Update. — Warum Pins ein Ablaufdatum brauchen.

Risiken und gute Praxis

Die Gefahr ist dieselbe wie bei HPKP: Ändert sich der Schlüssel und die App kennt den neuen nicht, funktioniert sie nicht mehr, bis Nutzer ein Update installieren. Mit immer kürzeren Laufzeiten bis hinunter zu 47 Tagen wird das wahrscheinlicher; siehe Zertifikatslaufzeit einfach erklärt. Die Android-Dokumentation verlangt deshalb ausdrücklich einen Sicherungsschlüssel, sonst stellt nur ein App-Update die Verbindung wieder her. Wer pinnt:

immer mindestens zwei Pins, davon einen Sicherungsschlüssel, der offline liegt,
auf Schlüssel pinnen, die man selbst kontrolliert, oder auf mehrere CAs, nicht auf ein einzelnes Zwischenzertifikat einer fremden CA, das jederzeit wechseln kann. Let’s Encrypt wechselt seine Zwischenzertifikate regelmäßig, zuletzt auf die 2025 erzeugte Generation mit YE1 und YR1,
ein Ablaufdatum setzen, damit alte App-Versionen nicht für immer blockieren; danach schützen die Pins allerdings nicht mehr,
den Schlüsselwechsel vorab planen und die neuen Pins mit einem App-Update verteilen, bevor sie gebraucht werden.

Häufige Fragen

Soll ich für meine Website Pinning einrichten? Nein. Für Websites gibt es keinen Standard mehr, und das Risiko überwiegt. Certificate Transparency, CAA und kurze Laufzeiten schützen besser.

Warum funktioniert eine App im Firmennetz nicht, der Browser aber schon? Viele Firmen untersuchen verschlüsselten Verkehr mit einer eigenen Root. Der Browser vertraut dieser Root, eine App mit Pinning dagegen nicht.

Ist Pinning dasselbe wie DANE? Ähnlich in der Idee, aber anders umgesetzt: Bei DANE stehen die erwarteten Schlüssel im DNS, beim Pinning im Programm.

Was passiert, wenn eine App wegen Pinning ausfällt? Sie kann keine Verbindung aufbauen und zeigt oft nur einen allgemeinen Netzwerkfehler. Abhilfe schafft erst ein Update mit neuen Pins.

Fazit

Certificate Pinning legt fest, welche Schlüssel ein Programm für einen Server akzeptiert, und schützt so vor falsch ausgestellten Zertifikaten. Für Websites ist der Standard HPKP gescheitert und seit Chrome 72 abgeschafft, weil Betreiber sich damit selbst aussperren konnten. In Apps wird weiter gepinnt, sollte aber mit Sicherungs-Pins und Ablaufdatum abgesichert werden. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.