Certificate Pinning : définition, mécanisme et méthodes de fixation

Qu’est-ce que le Certificate Pinning ?

Certificate Pinning est une technique de sécurité par laquelle une application stocke l’empreinte d’un certificat de confiance et l’utilise comme seul critère pour établir une connexion HTTPS. Dans le modèle TLS standard, le client vérifie que le certificat du serveur est signé par une CA racine de confiance — l’une des centaines d’autorités de certification préinstallées sur le système. Le Certificate Pinning remplace cette chaîne par une vérification directe : le certificat doit correspondre à l’échantillon stocké ou contenir la clé publique attendue.

Le problème du modèle standard est devenu évident après les incidents de compromission de CA — DigiNotar (2011), Comodo (2011), TrustCor (2022). Si une CA émet un certificat frauduleux pour votre domaine, le navigateur ou l’application l’accepte comme valide. Certificate Pinning empêche cette attaque : même un certificat frauduleux parfaitement signé sera rejeté car son empreinte ne correspond pas à celle fixée dans l’application.

Le terme pinning vient de pin — « broche » ou « fixateur » : le développeur fixe un certificat de confiance, et tout écart par rapport à celui-ci bloque la connexion. Selon l’étude de Mitre CWE-295, la validation inappropriée des certificats reste l’une des 10 erreurs de sécurité les plus dangereuses dans les applications mobiles, et le Certificate Pinning est une méthode directe pour la prévenir.

Histoire et évolution du Certificate Pinning

À l’origine, le Certificate Pinning était utilisé dans les navigateurs via le mécanisme HPKP (HTTP Public Key Pinning), normalisé dans la RFC 7469. Le développeur envoyait un en-tête HTTP Public-Key-Pins avec les hachages des clés attendues, et le navigateur les stockait pour une période déterminée. Cependant, HPKP s’est avéré dangereux : une seule erreur de configuration pouvait bloquer un site pendant des mois. En 2018, Chrome a cessé de prendre en charge HPKP, et la norme actuelle est devenue l’implémentation côté client — dans une application mobile ou une extension de navigateur.

Comment fonctionne le Certificate Pinning ?

Le processus de Certificate Pinning comprend trois étapes clés : calcul de l’empreinte, vérification de la connexion et gestion des erreurs. Lors de la préparation, le développeur obtient le hachage SHA-256 du certificat ou de la clé publique du serveur de production. Pour les applications conformes au RGPD et à la norme PCI DSS, il est également nécessaire de fixer les empreintes des CA intermédiaires dans la chaîne.

À chaque requête HTTPS, l’application intercepte le rappel d’authentification TLS, extrait le certificat du serveur et calcule son hachage SHA-256. Ce hachage est comparé à la liste stockée des empreintes de confiance. Si une correspondance est trouvée — la connexion continue. Sinon — l’application doit terminer la connexion et signaler l’erreur sans révéler les détails d’implémentation à l’attaquant.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

La fonction reçoit un objet X509Certificate du serveur et le hachage attendu. Elle extrait d’abord la clé publique du certificat, calcule le hachage SHA-256 et l’encode en Base64. Le résultat est comparé à l’empreinte attendue. En production, il convient d’ajouter la vérification contre un tableau de 2–3 empreintes pour prendre en charge la rotation.

Certificate Pinning vs Public Key Pinning

Lors de l’implémentation du pinning, il faut choisir quel objet cryptographique fixer. Le Certificate Pinning se lie au certificat X.509 lui-même — à son numéro de série, sa période de validité et toute la chaîne. Le Public Key Pinning ne fixe que la clé publique à l’intérieur du certificat, ignorant les autres champs. Ce choix a un impact significatif sur les coûts opérationnels.

Public Key Pinning est le choix préféré pour la plupart des projets. Les clés publiques des serveurs restent généralement inchangées lors de la réémission d’un certificat — l’entreprise signe simplement l’ancienne clé avec un nouveau certificat. Cela signifie que l’application ne nécessite pas de mise à jour après un changement de certificat si la paire de clés n’a pas changé. Le Certificate Pinning, en revanche, est recommandé pour les scénarios où le développeur contrôle totalement à la fois le serveur et le code client, comme dans les applications d’entreprise avec un cycle de mise à jour strict.

Trust On First Use (TOFU)

TOFU est une stratégie dans laquelle le Certificate Pinning n’est pas configuré à l’avance, mais mémorise le certificat lors de la première connexion au serveur. Cette approche est pratique pour les applications qui ne savent pas à l’avance à quel serveur elles vont se connecter. L’inconvénient est la vulnérabilité à une attaque initiale : si la première connexion est interceptée, un certificat frauduleux sera accepté comme de confiance. TOFU est utilisé dans les connexions SSH et certains protocoles P2P.

Implémentation sur iOS et Android

Sur les deux plateformes, le Certificate Pinning est implémenté en interceptant la connexion TLS au niveau de la pile réseau. Sur iOS, le délégué URLSession ou Alamofire ServerTrustManager est utilisé. Sur Android, la méthode préférée est OkHttp CertificatePinner, qui est intégré dans les clients HTTP populaires et prend en charge la configuration de plusieurs empreintes pour chaque domaine.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Dans la fonction Swift, la chaîne de certificats est extraite de serverTrust, un hachage SHA-256 est calculé pour chaque certificat, et le résultat est comparé à celui attendu. L’itération sur tous les certificats de la chaîne permet d’implémenter le pinning au niveau de la CA intermédiaire — si un certificat intermédiaire correspond, la connexion est acceptée. Cela offre une flexibilité lors de la rotation des certificats feuilles.

TrustManager personnalisé pour Android

Si l’application n’utilise pas OkHttp, le Certificate Pinning peut être implémenté via un X509TrustManager personnalisé. Cette méthode nécessite plus de code mais offre un contrôle total sur le processus de vérification. Le TrustManager remplace la méthode checkServerTrusted, où le développeur vérifie manuellement les certificats du serveur et décide de leur confiance. Elle est recommandée uniquement pour les scénarios spécifiques où la bibliothèque OkHttp n’est pas disponible.

Erreurs lors de l’implémentation du Certificate Pinning

L’erreur la plus courante est l’absence de backup pins. Le développeur inclut une seule empreinte de certificat, et lorsqu’elle expire, les utilisateurs perdent massivement la connexion. La configuration minimale acceptable est de deux empreintes : le certificat actuel et une de secours. Idéalement trois : l’actuel, un de secours et l’empreinte de la CA racine comme solution de repli.

La deuxième erreur est le stockage des pins en texte clair dans le code. Un attaquant ayant accès à un APK ou IPA peut facilement extraire et remplacer les empreintes. L’obfuscation des hachages est recommandée : diviser la chaîne en parties, stocker dans des ressources cryptées ou calculer à l’exécution. Pour Android, ProGuard avec obfuscation des constantes de chaînes est efficace.

La troisième erreur est le pinning au niveau du certificat de développement. Les certificats de développement et de production sont généralement différents, mais les développeurs oublient souvent de changer les pins lors de la compilation d’une version release. Le résultat est que l’application de production ne peut pas se connecter au serveur. La solution est des configurations de pins séparées pour le debug et le release via BuildConfig ou des ressources spécifiques aux flavors.

• Ignorer la chaîne de certificats — vérifier uniquement le certificat feuille sans tenir compte des CA intermédiaires, ce qui interrompt la connexion lors de la rotation
• Dates codées en dur — dates d’expiration de certificats codées en dur qui ne changent pas après les mises à jour
• Absence de surveillance — absence d’alertes sur les erreurs de Certificate Pinning, les problèmes n’étant découverts que par les utilisateurs
• TOFU sans validation — utilisation de Trust On First Use sans vérification supplémentaire, permettant à la première attaque MITM de fixer un certificat frauduleux