Qu'est-ce que le Mutual TLS (mTLS) ? Authentification par certificat client

En HTTPS classique, seul le serveur prouve son identité avec un certificat. Le client (navigateur) est anonyme — le serveur ne sait pas qui se connecte.

Le Mutual TLS (mTLS) ajoute une seconde étape : le client présente également un certificat. Les deux côtés s’authentifient mutuellement. Le serveur vérifie le certificat du client auprès d’une CA de confiance, et le client vérifie celui du serveur — d’où le terme « mutual » (mutuel).

TLS classique vs Mutual TLS

Quand utiliser mTLS

Communication service-à-service

Des microservices qui communiquent entre eux sur le réseau. mTLS garantit que seuls les services autorisés peuvent se connecter — pas n’importe qui connaissant l’URL.

Service A ←──mTLS──→ Service B
Les deux vérifient : "Es-tu bien celui que tu prétends être ?"

Architecture Zero Trust

En zero trust, aucune connexion réseau n’est considérée comme fiable par défaut — même à l’intérieur du réseau d’entreprise. mTLS remplace la confiance au niveau réseau (pare-feux, VPN) par la confiance au niveau identité (certificats).

Sécurité des APIs

Protégez les APIs sensibles au-delà des simples clés API. Une clé API volée peut être utilisée par n’importe qui. Un certificat client est lié à une clé privée spécifique — plus difficile à voler et à utiliser.

Authentification des appareils IoT

Les appareils se connectent à un backend avec des certificats clients provisionnés lors de la fabrication. Le serveur sait qu’il communique avec un appareil authentique, pas un appareil usurpé.

Comment fonctionne mTLS

1. Le client se connecte et initie le handshake TLS (identique au TLS classique)
2. Le serveur envoie son certificat — le client le vérifie (identique au TLS classique)
3. Le serveur demande le certificat du client — envoie un message CertificateRequest
4. Le client envoie son certificat — le serveur le vérifie auprès d’une CA de confiance
5. Les deux côtés calculent les clés de session et la communication chiffrée commence

Les étapes 3–4 sont ce qui rend le TLS « mutual » (mutuel).

Configuration mTLS Nginx

server {
    listen 443 ssl;
    server_name api.example.com;

    # Certificat serveur (identique au HTTPS classique)
    ssl_certificate     /etc/ssl/server-fullchain.pem;
    ssl_certificate_key /etc/ssl/server-privkey.pem;

    # Vérification du certificat client
    ssl_client_certificate /etc/ssl/client-ca.pem;  # CA ayant signé les certificats clients
    ssl_verify_client on;                            # Exiger le certificat client

    # Optionnel : transmettre les infos du certificat client à votre application
    proxy_set_header X-Client-DN $ssl_client_s_dn;
    proxy_set_header X-Client-Verify $ssl_client_verify;
}

mTLS vs autres méthodes d’authentification

mTLS et GetHTTPS

GetHTTPS émet des certificats serveur — les certificats que votre serveur web utilise pour prouver son identité. Ce sont les certificats SSL standards utilisés par tous les sites HTTPS.

Les certificats clients pour mTLS sont généralement émis par une CA privée (la CA interne de votre organisation), pas par une CA publique comme Let’s Encrypt. Let’s Encrypt n’émet pas de certificats clients — ils ne délivrent que des certificats serveur pour les domaines publics.

Questions fréquentes

Puis-je utiliser Let’s Encrypt pour mTLS ?

Pour le certificat serveur : oui. Pour les certificats clients : non. Les certificats clients doivent être émis par une CA privée que vous contrôlez — afin que vous décidiez quels clients sont autorisés. Des outils comme openssl, cfssl ou step-ca peuvent servir de CA privée.

mTLS est-il la même chose que l’« authentification par certificat client » ?

Oui. « Mutual TLS », « mTLS », « TLS bidirectionnel » et « authentification par certificat client » désignent tous la même chose — les deux côtés présentent des certificats pendant le handshake TLS.

mTLS remplace-t-il les clés API ?

Il peut le faire, mais ils servent des objectifs différents. mTLS prouve l’identité au niveau transport (quel service se connecte). Les clés API/JWT prouvent l’identité au niveau applicatif (quel utilisateur/quelle permission). De nombreux systèmes utilisent les deux ensemble pour une défense en profondeur.

Où mTLS est-il couramment utilisé ?

Kubernetes (service mesh avec Istio/Linkerd), Cloudflare Access, AWS API Gateway (Mutual TLS), BeyondCorp de Google, et la plupart des implémentations zero trust en entreprise.