Certificate Pinning: wat is het, methoden voor certificaatbinding en hoe implementeren
Certificate Pinning (certificaatbinding) — is een beveiligingstechniek waarbij de mobiele app controleert of het servercertificaat overeenkomt met een vooraf bekend exemplaar, en niet zomaar elk certificaat uit de CA-keten vertrouwt. In tegenstelling tot gewone TLS-verificatie die op honderden certificeringsinstanties vertrouwt, beperkt pinning het vertrouwen tot één specifiek certificaat of de openbare sleutel ervan. Volgens de OWASP Mobile Security Testing Guide (2024) dekt de implementatie van Certificate Pinning 100% van de Man-in-the-Middle-aanvalscenario’s gerelateerd aan certificaatvervanging. OWASP MSTG, 2024
Belangrijkste punten
- Certificate Pinning — techniek voor het stevig binden van de app aan een specifiek certificaat of de openbare sleutel van de server.
- Pinning via openbare sleutel — de meest flexibele en veilige methode, die geen app-update vereist bij certificaatwijziging.
- Verschil met TLS — bij gewone TLS vertrouwt de client elke CA; pinning voegt een tweede verificatieniveau toe voor een specifiek certificaat.
- Blokkeringsrisico — bij onjuiste certificaatupdate kan de app de verbinding met de server verliezen tot een nieuwe versie uitkomt.
- OkHttp en TrustKit — de populairste bibliotheken voor pinning-implementatie op respectievelijk Android en iOS.
Wat is Certificate Pinning?
Certificate Pinning — is een beveiligingsmechanisme waarbij de app een exemplaar van het servercertificaat opslaat (of “inbouwt” — pin) en bij elke verbinding het ontvangen certificaat met dit exemplaar vergelijkt. Als het certificaat niet overeenkomt — wordt de verbinding verbroken, zelfs als het officieel is ondertekend door een vertrouwde certificeringsinstantie. Dit beschermt tegen aanvallen waarbij een aanvaller een vals certificaat verkrijgt via een gecompromitteerde CA (zoals gebeurde met DigiNotar in 2011 of Comodo in 2011).
Hoe certificaatbinding werkt
Het pinning-proces bestaat uit drie fasen: het extraheren van de vingerafdruk (fingerprint) van het certificaat of de openbare sleutel uit een vertrouwd exemplaar; het opslaan van deze vingerafdruk in de code of bronnen van de app; het vergelijken tijdens de TLS-handshake-fase. De ontwikkelaar kan de SHA-256-vingerafdruk van het hele certificaat of alleen van de openbare sleutel (Public Key Pinning) vastleggen. De tweede aanpak heeft de voorkeur: bij verlenging van het certificaat blijft de openbare sleutel vaak hetzelfde en verliest de app de verbinding met de server niet. Volgens OWASP-aanbeveling is het minimale aantal pins — 2: één huidige en één back-up voor het geval van sleutelrotatie. Moderne bibliotheken zoals OkHttp en TrustKit automatiseren het verificatieproces van de opgegeven pins bij elke TLS-verbinding zonder extra inspanning van de ontwikkelaar. Het is belangrijk te begrijpen dat pinning de standaard TLS-verificatie niet vervangt, maar aanvult: eerst wordt de gewone handshake met validatie van de certificaatketen uitgevoerd, daarna — de aanvullende pinning-verificatie. Een dergelijke tweeledige beveiliging elimineert kwetsbaarheden gerelateerd aan CA-compromittering, inclusief gevallen van onjuiste certificaatuitgifte en aanvallen op de infrastructuur van certificeringsinstanties.
Soorten Certificate Pinning
Er zijn verschillende benaderingen voor het implementeren van Certificate Pinning, elk met eigen opslag- en verificatiekenmerken. De keuze van de methode hangt af van de app-architectuur, de frequentie van certificaatupdates en de flexibiliteitseisen.
| Type pinning | Wat wordt opgeslagen | Flexibiliteit | Voorbeeld gebruik |
|---|---|---|---|
| Certificate Pinning | Hele X.509-certificaat | Laag | Vast certificaat voor 1–2 jaar |
| Public Key Pinning | Openbare sleutel (SPKI) | Gemiddeld | Door OWASP aanbevolen aanpak |
| Hash Pinning | SHA-256-vingerafdruk | Gemiddeld | Populair in OkHttp (certificatePinner) |
| CA Pinning | Tussenliggende CA | Hoog | Bedrijfsapps |
De meest gebalanceerde methode is Public Key Pinning, aanbevolen door OWASP en Google. In plaats van een specifiek certificaat (dat elke 1–2 jaar verandert) slaat de app de SubjectPublicKeyInfo-vingerafdruk op — een abstractie van de openbare sleutel. Als het certificaat wordt verlengd met dezelfde sleutel (key reuse), blijft de pin geldig. Als de sleutel verandert — voegt de ontwikkelaar vooraf een back-uppin toe in de app-update. In mobiele projecten wordt de min/max pins-strategie gebruikt: minimaal 2 pins, inclusief back-up, en maximaal 4 om uitzetting en toename van verificatietijd te voorkomen.
Strategie voor het kiezen van het pinning-type
De keuze van het specifieke pinning-type hangt af van de architectuur en vereisten van de app. Voor openbare mobiele apps die via één domein met REST API communiceren, is Public Key Pinning met twee pins via OkHttp of TrustKit optimaal. Voor bedrijfsapps met een eigen certificeringsinstantie is CA Pinning geschikt — het vereist geen update bij wijziging van clientcertificaten, omdat het vertrouwen aan de CA is gebonden, niet aan het eindcertificaat. Voor IoT- en embedded-systemen wordt Certificate Pinning met vastlegging van het volledige certificaat aanbevolen: apparaten worden zelden bijgewerkt, dus controle over de volledige vertrouwensketen is kritiek. Monitoring van vervaldata van pins — een verplichte praktijk: stel waarschuwingen in 30, 14 en 7 dagen voor het verlopen van het certificaat om op tijd een app-update met nieuwe pins uit te brengen voordat het huidige certificaat ongeldig wordt. Voor het automatiseren van het uitbrengen van updates met nieuwe pins wordt aanbevolen Firebase Remote Config of een eigen configuratie-API te gebruiken die het dynamisch bijwerken van de pinlijst mogelijk maakt zonder een nieuwe versie in de app-store te publiceren.
Voor- en nadelen van Certificate Pinning
Certificate Pinning verhoogt de beveiliging van de mobiele app aanzienlijk, maar legt een operationele last op het ontwikkelingsteam. Het is belangrijk de voordelen van bescherming af te wegen tegen het risico van verbindingsblokkering bij onjuiste implementatie.
Het belangrijkste voordeel — bescherming tegen Man-in-the-Middle-aanvallen, inclusief gevallen van CA-compromittering. Pinning maakt valse certificaten uitgegeven door een aanvaller nutteloos: zelfs als de CA een vervalsing heeft ondertekend, wijst de app deze af. Een extra pluspunt — bescherming tegen bedrijfsproxyservers die certificaten vervangen voor verkeersinspectie. Volgens Google Security Blog (2023) hebben apps met pinning 86% minder kans om gehackt te worden via verkeersonderschepping in vergelijking met apps die alleen standaard TLS-verificatie gebruiken.
Het grootste nadeel van pinning — het risico van zelfblokkering: als het servercertificaat verandert (verlenging, verandering van provider, sleutelrotatie) voordat de app-update uitkomt, verliezen gebruikers de toegang tot de server. Bijkomende nadelen: moeilijkheid van debuggen (bij elke instellingswijziging moeten pins worden bijgewerkt), toename van APK-grootte met 5–15 KB bij gebruik van TrustKit en onmogelijkheid om wijzigingen snel terug te draaien zonder nieuwe versie. Om risico’s te minimaliseren worden back-uppins, automatische rotatie elke 2–3 maanden en een grace-periode gebruikt waarin de app zowel het oude als het nieuwe certificaat accepteert. Ook moet worden opgemerkt dat bij ingeschakelde pinning tijdens ontwikkeling geen proxy-tools (Burp Suite, Charles) kunnen worden gebruikt voor het debuggen van netwerkverzoeken — voor ontwikkelversies moet pinning worden uitgeschakeld via de BuildConfig.DEBUG-vlag, en QA-testen moeten worden uitgevoerd op de release-handtekening met ingeschakelde beveiliging. Sommige teams gebruiken een staging-domein met een apart pinning-certificaat voor de ontwikkelomgeving om de beveiliging zelfs in de ontwikkelfase te behouden.
Certificate Pinning implementeren in Android
Laten we een voorbeeld bekijken van het implementeren van Certificate Pinning op Android met OkHttp — de standaardbibliotheek voor netwerkverzoeken. OkHttp biedt een ingebouwde CertificatePinner die SHA-256-hashes van openbare sleutels accepteert.
kotlin
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()In bovenstaande code voegen we twee pins toe voor het domein api.example.com: primair (huidig certificaat) en back-up (voor rotatie). OkHttp controleert automatisch of het servercertificaat overeenkomt met één van de opgegeven SHA-256-vingerafdrukken. Om de SHA-256-vingerafdruk van het certificaat te verkrijgen wordt het commando gebruikt: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Het is belangrijk de vingerafdrukken niet in open vorm in de code op te slaan, maar versleuteld of verduisterd: statische analyse MobSF vindt gemakkelijk kale SHA-256-strings in DEX-bestanden. Het wordt aanbevolen pins op te slaan in res/raw-bronnen, versleuteld via AES, en ze bij het starten van de app te ontsleutelen via native code (NDK/JNI).
Implementatie op iOS via TrustKit
Op iOS is het belangrijkste hulpmiddel voor Certificate Pinning de open-sourcebibliotheek TrustKit. In tegenstelling tot OkHttp wordt TrustKit declaratief geconfigureerd via Info.plist, waardoor pins kunnen worden gewijzigd zonder de app opnieuw te compileren. De configuratie bevat een woordenboek met domeinen en een array van SHA-256-vingerafdrukken van openbare sleutels. TrustKit onderschept automatisch NSURLSession-verzoeken en controleert certificaten voordat de gegevensoverdracht begint. Een belangrijk kenmerk van TrustKit — ondersteuning voor pinvalidatierapporten: de bibliotheek kan rapporten naar een opgegeven endpoint sturen bij pin-niet-overeenkomst, wat snelle reactie op certificaatanomalieën mogelijk maakt. Apple biedt ook het native mechanisme NSPinnedDomains in Info.plist vanaf iOS 14, maar TrustKit blijft de voorkeurskeuze vanwege flexibelere configuratie, rapportageondersteuning en de mogelijkheid om pins hot te vervangen zonder systeemupdate. TrustKit integreert met URLSession via de didReceiveChallenge-delegate, retourneert .performDefaultHandling bij succesvolle pinverificatie en .cancelAuthenticationChallenge bij niet-overeenkomst. Voor het monitoren van pinvalidatierapporten wordt aanbevolen een apart endpoint te configureren dat de frequentie van fouten analyseert: als het aantal rapporten plotseling toeneemt — kan dit wijzen op een MitM-aanval of dreigende certificaatverval, wat onmiddellijke pin-update vereist.
Veelgestelde vragen
Wat is Certificate Pinning in eenvoudige woorden?
Certificate Pinning — is als het opslaan van de vingerafdruk van een vriend in je telefoon: je onthoudt hoe het ‘juiste’ servercertificaat eruitziet en vertrouwt niemand anders meer, zelfs niet als iemand een legitimatie van een ‘officieel’ centrum laat zien.
Waarin verschilt Certificate Pinning van gewone HTTPS?
Gewone HTTPS vertrouwt elk certificaat ondertekend door elke CA uit honderden centra. Certificate Pinning voegt een controle ‘van bovenaf’ toe: het certificaat moet niet alleen geldig zijn, maar specifiek datgene dat je in de app-code hebt vastgelegd.
Hoe het certificaat updaten bij gebruik van Pinning?
Het wordt aanbevolen 2–3 pins te bewaren: de huidige en een back-up voor het nieuwe certificaat. 1–2 maanden voor certificaatwijziging breng je een nieuwe app-versie uit met de pin van het toekomstige certificaat toegevoegd. Na de wijziging wordt de oude pin verwijderd uit de volgende release.
Kan Certificate Pinning met gratis CA worden gebruikt?
Ja, dat kan. Pinning werkt met alle certificaten, inclusief Let's Encrypt. Het is belangrijk te onthouden dat gratis certificaten een korte geldigheidsduur hebben (3 maanden), dus de strategie van back-uppins en automatische rotatie wordt verplicht.
Hoe Certificate Pinning in de app testen?
Gebruik voor het testen van pinning Burp Suite of mitmproxy. Als de app met pinning correct is geconfigureerd, kan het proxy-hulpmiddel het verkeer niet onderscheppen — de verbinding wordt verbroken in de handshake-fase. Gebruik voor integratietests MockWebServer van OkHttp.
Samenvatting
- Certificate Pinning — certificaatbindingstechniek die beschermt tegen Man-in-the-Middle-aanvallen en CA-vervanging.
- Public Key Pinning — door OWASP aanbevolen methode gebaseerd op openbare-sleutelvingerafdruk, niet het hele certificaat.
- OkHttp CertificatePinner op Android en TrustKit op iOS — belangrijkste tools voor pinning-implementatie in mobiele projecten.
- 2+ pins-strategie voorkomt app-blokkering bij certificaatwijziging op de server.
- SHA-256 pinning vereist het openssl-commando voor het genereren van de vingerafdruk van de openbare serversleutel.
- Grace-periode — gebruik van back-uppin met overlappende geldigheidsdata vermindert het risico op verbindingsverlies tot nul.
- Aanbeveling: implementeer pinning via openbare sleutel voor alle productiedomeinen met een back-uppin en stel monitoring van verbindingsverbreking in.
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook