Certificate Pinning für mobile und API-Clients

1. Das Bedrohungsmodell: MITM mit einem gültigen, aber falschen Zertifikat

Die normale TLS-Validierung prüft, ob ein Zertifikat von einer der im Betriebssystem oder Browser hinterlegten vertrauenswürdigen Zertifizierungsstellen signiert wurde und ob es zum aufgerufenen Hostnamen passt. Diese Prüfung schützt zuverlässig gegen selbstsignierte oder abgelaufene Zertifikate, versagt aber, wenn ein Angreifer über ein technisch korrekt signiertes Zertifikat verfügt, das dennoch nicht vom eigentlichen Betreiber stammt.

Solche Zertifikate können aus mehreren Quellen stammen: einer kompromittierten oder zur Ausstellung gezwungenen Zertifizierungsstelle, einem versehentlich fehlausgestellten Zertifikat, oder einem auf dem Gerät installierten zusätzlichen Root-Zertifikat, wie es Unternehmens-MITM-Proxys, manche Antivirenprogramme oder bösartige Konfigurationsprofile einsetzen. In all diesen Fällen erscheint die Verbindung dem Betriebssystem gegenüber vollständig legitim, obwohl der Datenverkehr tatsächlich mitgelesen oder manipuliert wird.

2. Wie Certificate Pinning funktioniert

Certificate Pinning ergänzt die normale TLS-Validierung um eine zusätzliche, hart in der App hinterlegte Erwartung: Neben der regulären Kettenprüfung vergleicht die App das empfangene Zertifikat oder dessen öffentlichen Schlüssel mit einer vorab festgelegten, in der App gespeicherten Liste. Stimmt keiner der hinterlegten Pins mit dem tatsächlich empfangenen Wert überein, bricht die App die Verbindung ab, selbst wenn das Zertifikat aus Sicht des Betriebssystems vollständig vertrauenswürdig wäre.

Auf Android erfolgt die Konfiguration deklarativ über die Network Security Config, auf iOS üblicherweise über Bibliotheken wie TrustKit oder die systemeigene URLSession-Delegate-Methode für die Zertifikatsprüfung. Beide Ansätze verlagern die Vertrauensentscheidung von der systemweiten Zertifikatsliste in die App selbst, wodurch die App unabhängig davon wird, welche zusätzlichen Root-Zertifikate auf dem jeweiligen Gerät installiert sind.

<!-- res/xml/network_security_config.xml (Android) -->
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">api.mironsoft.de</domain>
        <pin-set expiration="2027-01-01">
            <!-- Aktueller Public Key (SPKI-Hash) -->
            <pin digest="SHA-256">k3rz9QcMH42ZMv/hHtP9Vt+u6+9Uv2wOX2Xr8pmqCbo=</pin>
            <!-- Backup-Pin für die nächste geplante Rotation -->
            <pin digest="SHA-256">9y5uK4iKz4Q4gCkH8Yjrl1J9Y4gU3nDy2sHwLxwvTuI=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

3. Zertifikat-Pinning vs. Public-Key-Pinning

Beim klassischen Zertifikat-Pinning hinterlegt die App einen Fingerabdruck des kompletten Zertifikats. Das ist einfach umzusetzen, hat aber einen entscheidenden Nachteil: Sobald das Zertifikat regulär erneuert wird, etwa nach Ablauf der Gültigkeit, ändert sich der Fingerabdruck vollständig, selbst wenn derselbe private Schlüssel weiterverwendet wird. Jede Zertifikatserneuerung erfordert dann zwingend ein App-Update mit dem neuen Pin, was bei kurzen Zertifikatslaufzeiten schnell zur betrieblichen Belastung wird.

Public-Key-Pinning umgeht dieses Problem, indem nicht das Zertifikat selbst, sondern der SPKI-Hash, der Subject-Public-Key-Info-Fingerabdruck des öffentlichen Schlüssels, hinterlegt wird. Solange derselbe Schlüsselpaar bei einer Zertifikatserneuerung weiterverwendet wird, bleibt der Pin gültig, unabhängig davon, wie oft das umgebende Zertifikat selbst erneuert wird. Aus diesem Grund gilt Public-Key-Pinning heute als die deutlich praxistauglichere Variante gegenüber reinem Zertifikat-Pinning.

4. Warum reines Zertifikat-Pinning bei Zertifikatswechseln bricht

Der Bruch bei einer Zertifikatserneuerung ist keine Randbedingung, sondern der Normalfall: TLS-Zertifikate haben typischerweise eine Laufzeit von wenigen Monaten bis maximal einem Jahr und müssen regelmäßig erneuert werden. Wer den kompletten Zertifikat-Fingerabdruck pinnt, muss diesen Zyklus exakt mit dem App-Release-Zyklus synchronisieren, was bei App-Store-Review-Zeiten von mehreren Tagen bis Wochen ein enges und fehleranfälliges Zeitfenster erzeugt.

Selbst bei perfekter Planung bleibt das Risiko, dass Nutzer alte App-Versionen länger im Einsatz behalten als erwartet, etwa weil automatische Updates deaktiviert sind oder das Gerät längere Zeit offline war. Diese Nutzer verlieren mit einem reinen Zertifikat-Pin nach jeder Zertifikatserneuerung schlagartig die Verbindung zum Backend, ein Effekt, der sich mit Public-Key-Pinning und langfristig stabilen Schlüsselpaaren deutlich seltener zeigt.

5. Backup-Pins: Die Versicherung gegen geplante und ungeplante Rotation

Ein einzelner Pin ist ein Single Point of Failure: Muss der zugrunde liegende Schlüssel unerwartet gewechselt werden, etwa nach einem Verdacht auf Kompromittierung, bricht jede Verbindung ab, bis eine neu App-Version mit aktualisiertem Pin ausgerollt und von allen Nutzern installiert wurde. Deshalb gehört mindestens ein Backup-Pin zu jeder soliden Pinning-Konfiguration, im Idealfall der öffentliche Schlüssel eines bereits generierten, aber noch nicht aktiven nächsten Zertifikats.

Der Backup-Pin sollte für einen Schlüssel stehen, der komplett unabhängig vom aktuell genutzten Schlüssel aufbewahrt wird, etwa offline oder in einem separat gesicherten Schlüsselspeicher, damit ein Angreifer, der den aktiven Schlüssel kompromittiert, nicht automatisch auch den Backup-Schlüssel erlangt. Ohne diese Trennung verliert der Backup-Pin einen großen Teil seines Sicherheitswerts, da beide Schlüssel im Ernstfall gemeinsam betroffen wären.

6. Die Geschichte von HPKP und warum Browser das Konzept aufgegeben haben

Für klassische Webseiten existierte mit HTTP Public Key Pinning, kurz HPKP, ein Header-basiertes Gegenstück zum mobilen Pinning, das Browser um 2015 einführten. Ein Server konnte per Header festlegen, welche Public-Key-Pins für zukünftige Verbindungen erwartet werden, cachbar über mehrere Wochen. In der Praxis führte das jedoch wiederholt zu genau jenem Lockout-Problem, das Pinning eigentlich verhindern sollte: Fehlkonfigurationen oder Serverprobleme sperrten Nutzer dauerhaft aus, ohne einfache Möglichkeit zur Korrektur.

Wegen dieses hohen Risikos bei vergleichsweise geringem zusätzlichem Schutz gegenüber Certificate Transparency und modernen CA-Kontrollen wie CAA-Records entfernten alle großen Browser HPKP wieder aus ihren Implementierungen. Für mobile Apps gilt diese Einschätzung nur bedingt, weil dort Pinning gezielter, unter direkter Kontrolle des App-Entwicklers und mit klar definiertem Backend eingesetzt wird, statt browserweit für beliebige, dem Nutzer unbekannte Webseiten.

7. Implementierung in mobilen Apps: iOS und Android im Vergleich

Auf Android lässt sich Pinning vollständig deklarativ über die bereits gezeigte Network Security Config umsetzen, ohne eigenen Code für die Zertifikatsprüfung schreiben zu müssen, was Fehlerquellen reduziert. Alternativ bieten Netzwerkbibliotheken wie OkHttp einen eigenen CertificatePinner, der sich programmatisch konfigurieren lässt und zusätzliche Flexibilität bietet, etwa für dynamisch nachgeladene Pin-Sets.

Auf iOS übernimmt häufig die Bibliothek TrustKit diese Aufgabe, die eine vergleichbare deklarative Konfiguration über die Info.plist der App anbietet und zusätzlich Reporting-Funktionen mitbringt, die fehlgeschlagene Pin-Validierungen an ein Backend melden können. Wer ohne zusätzliche Bibliothek auskommen möchte, kann die Prüfung auch direkt in der URLSession-Delegate-Methode für die Server-Trust-Validierung implementieren, was mehr Kontrolle, aber auch mehr Verantwortung für korrekte Fehlerbehandlung bedeutet.

8. Das Lockout-Risiko: Wenn Pinning die eigene App unbenutzbar macht

Das größte praktische Risiko von Certificate Pinning ist nicht ein übersehener Angriff, sondern ein selbst verursachter Ausfall. Weil Pins fest in der ausgelieferten App verankert sind, lässt sich eine fehlerhafte oder veraltete Konfiguration nicht einfach per Server-Update korrigieren, sondern erfordert ein vollständiges App-Update samt Store-Review und, entscheidend, samt tatsächlicher Installation durch die Nutzer. Bis dahin verlieren betroffene Nutzer jede Verbindung zum Backend.

Besonders gefährlich wird es bei einer ungeplanten Notfall-Rotation, etwa nach einem Verdacht auf Schlüsselkompromittierung, wenn kein passender Backup-Pin vorhanden ist. In diesem Fall steht das Entwicklungsteam vor der Wahl, entweder Pinning temporär serverseitig zu deaktivieren, was den ursprünglichen Sicherheitsgewinn zunichtemacht, oder Nutzer bis zum nächsten App-Update vollständig auszusperren, was besonders bei sicherheitskritischen Apps, etwa im Banking-Umfeld, geschäftskritisch werden kann.

9. Best Practices für ein sicheres Pinning-Konzept in der Praxis

Ein tragfähiges Pinning-Konzept pinnt bevorzugt den öffentlichen Schlüssel eines Intermediate- oder gar Root-Zertifikats der genutzten Zertifizierungsstelle statt des Leaf-Zertifikats, da diese Schlüssel deutlich seltener wechseln und damit die Rotationsfrequenz der App-eigenen Pins reduzieren. Zusätzlich sollten mindestens zwei unabhängige Backup-Pins hinterlegt werden, idealerweise für bereits vorbereitete, aber noch inaktive Schlüssel unterschiedlicher Herkunft.

Sicherheits- und Mobile-Teams sollten Pin-Rotationen gemeinsam planen und vor jedem produktiven Rollout in einer Testumgebung mit realistischen Zertifikatswechseln durchspielen, statt sich auf die Theorie zu verlassen. Ein serverseitiger Fallback-Mechanismus, der im Notfall eine kontrollierte, zeitlich begrenzte Deaktivierung des Pinnings erlaubt, etwa über ein Remote-Konfigurations-Flag, verhindert im Ernstfall einen dauerhaften Lockout, ohne die Schutzwirkung im Regelbetrieb zu schwächen.

10. Zusammenfassung

11. FAQ: Certificate Pinning: Das Wichtigste auf einen Blick