Cas d’utilisation de PKI : HTTPS, S/MIME et signature de code

L'infrastructure à clé publique (PKI) est l'épine dorsale invisible des communications numériques sécurisées. Les certificats et les CA que vous avez étudiés sont appliqués chaque jour dans des dizaines de situations concrètes. L'examen Security+ évalue votre capacité à reconnaître les cas d'utilisation de la PKI, à comprendre quel type de certificat convient à chacun et à déterminer quelle protection la PKI fournit dans chaque contexte. Les trois cas d'utilisation les plus importants à l'examen sont HTTPS/TLS (sécurité web), S/MIME (sécurité des courriels) et la signature de code (intégrité des logiciels).

HTTPS (HTTP sur TLS) est le cas d'utilisation le plus visible de la PKI. Lorsque vous vous connectez à https://bank.com, votre navigateur : (1) reçoit le certificat TLS du serveur, (2) vérifie que la chaîne de certificats remonte jusqu'à une CA racine approuvée, (3) compare le nom d'hôte aux champs SAN, (4) vérifie que le certificat n'est pas révoqué et (5) utilise la clé publique pour un échange de clés Diffie-Hellman afin d'établir une session chiffrée. L'icône de cadenas dans votre navigateur indique que toutes ces vérifications ont réussi. Un certificat manquant ou invalide entraîne un avertissement du navigateur qui dissuade la plupart des utilisateurs de poursuivre.

S/MIME (Secure/Multipurpose Internet Mail Extensions) utilise des certificats PKI pour fournir deux services de sécurité aux courriels. Chiffrement : l'expéditeur chiffre le corps du courriel avec la clé publique du destinataire, de sorte que seul celui-ci puisse le déchiffrer — ce qui protège la confidentialité même si le courriel est intercepté pendant son transfert ou stocké sur un serveur compromis. Signatures numériques : l'expéditeur signe avec sa clé privée, ce qui prouve au destinataire que le courriel provient bien de l'expéditeur et n'a pas été modifié — garantissant l'intégrité et la non-répudiation. S/MIME exige que chaque utilisateur dispose de son propre certificat émis par une CA.

La signature de code utilise la PKI pour signer numériquement les logiciels — exécutables, scripts, pilotes et programmes d'installation — afin que les utilisateurs puissent vérifier qu'ils proviennent d'un éditeur de confiance et n'ont pas été altérés. L'éditeur signe son code avec une clé privée provenant d'un certificat de signature de code émis par une CA de confiance. Lorsqu'un utilisateur exécute le logiciel, le système d'exploitation vérifie la signature à l'aide de la clé publique de l'éditeur issue de la chaîne de certificats. Windows SmartScreen, macOS Gatekeeper et les boutiques d'applications iOS/Android s'appuient tous sur la signature de code pour établir la provenance des logiciels. Les logiciels non signés peuvent être bloqués ou déclencher des avertissements de sécurité.

L'authentification par certificat client (également appelée TLS mutuel ou mTLS) étend le modèle TLS standard en exigeant que le client présente lui aussi un certificat. Avec TLS standard, seul le serveur est authentifié par certificat ; avec mTLS, les deux parties sont authentifiées mutuellement. Cette méthode est utilisée pour : l'authentification VPN (cartes à puce ou certificats client à la place des mots de passe), l'authentification des API (authentification de machine à machine lorsque le client est un service et non une personne) et l'accès administrateur privilégié (obligation pour les administrateurs d'utiliser des jetons matériels contenant des certificats).

SSH utilise la cryptographie à clé publique à deux fins : l'authentification du serveur et l'authentification du client. Authentification du serveur : lorsque vous vous connectez pour la première fois à un serveur SSH, celui-ci présente sa clé d'hôte (clé publique). Votre client SSH l'enregistre dans ~/.ssh/known_hosts. Lors des connexions suivantes, si la clé d'hôte change (ce qui peut indiquer une attaque MITM ou la reconstruction du serveur), SSH vous avertit. Authentification du client : au lieu de mots de passe, les administrateurs utilisent des paires de clés — la clé publique est ajoutée au fichier authorized_keys du serveur et la clé privée (qui n'est jamais envoyée) prouve l'identité. Les clés d'hôte SSH sont distinctes des certificats PKI, mais remplissent la même fonction de confiance.

La PKI permet la signature numérique juridiquement contraignante des documents dans de nombreuses juridictions. Les signatures de PDF Adobe, DocuSign et les systèmes gouvernementaux de signature électronique utilisent tous des certificats PKI pour signer les documents. L'horodatage est un complément essentiel à la signature de documents : une autorité d'horodatage de confiance (TSA) contresigne le hachage du document avec une heure fiable, prouvant que le document existait à un moment précis. L'horodatage est également essentiel pour la signature de code : sans horodatage, les signatures de code deviennent invalides lorsque le certificat de signature expire, même pour les logiciels distribués avant cette expiration.

À mesure que les appareils IoT se multiplient, la PKI fournit un moyen de les authentifier à grande échelle. Chaque appareil reçoit un certificat unique lors de sa fabrication (processus appelé provisionnement de l'identité de l'appareil), ce qui permet aux serveurs d'authentifier individuellement les appareils grâce à leurs certificats. Cela permet notamment à un compteur intelligent de prouver son identité au serveur du fournisseur d'énergie, à un dispositif médical de s'authentifier auprès du réseau d'un hôpital ou à une flotte de véhicules de s'authentifier auprès du système dorsal d'un constructeur. La PKI pour l'IoT doit gérer des millions d'appareils aux ressources limitées, ce qui favorise l'adoption des certificats ECC en raison de leur petite taille et de leur vérification rapide.

L'authentification VPN basée sur des certificats est nettement plus sécurisée que l'authentification VPN basée sur un mot de passe. Chaque utilisateur ou appareil VPN reçoit un certificat client émis par la CA interne de l'organisation. Lors de la connexion, la passerelle VPN vérifie le certificat client (en s'assurant qu'il a été émis par la CA interne de confiance, qu'il est encore valide et qu'il n'a pas été révoqué via CRL/OCSP). Lorsqu'un employé quitte l'organisation, la révocation de son certificat empêche immédiatement l'accès au VPN — une méthode plus fiable que d'espérer qu'il n'a pas partagé son mot de passe avec d'autres personnes.

Les professionnels de la sécurité doivent être capables de diagnostiquer les erreurs courantes liées aux certificats. Certificat expiré : la date notAfter est dépassée — renouvelez le certificat. Nom d'hôte non concordant : le SAN du certificat ne correspond pas au nom d'hôte demandé — vérifiez les CN et les SAN ; un certificat générique ou un certificat à plusieurs SAN peut être nécessaire. Certificat autosigné : aucune CA ne garantit ce certificat — ajoutez-le au magasin de confiance local ou remplacez-le par un certificat signé par une CA. Chaîne incomplète : le certificat de la CA intermédiaire n'est pas fourni par le serveur — configurez le serveur pour envoyer la chaîne complète. Certificat révoqué : la CRL ou OCSP indique une révocation — une réponse immédiate à la compromission de la clé est nécessaire.

Deux types de certificats permettent de gérer plusieurs noms d'hôte. Un certificat générique couvre tous les sous-domaines de premier niveau d'un domaine : *.example.com couvre www.example.com, mail.example.com et api.example.com, mais PAS sub.api.example.com (deux niveaux). Un seul certificat et une seule clé privée pour tous les services : c'est pratique, mais risqué si la clé est compromise (tous les services sont touchés). Un certificat à plusieurs SAN répertorie explicitement plusieurs domaines précis dans l'extension SAN (par exemple example.com, www.example.com et api.example.com). Cette solution est plus granulaire, mais le certificat doit être mis à jour lorsque de nouveaux domaines sont ajoutés.

Testez votre compréhension des notions de CompTIA Security+ (SY0-701) abordées dans cette leçon.

Dans cette leçon, vous avez appris que les certificats HTTPS/TLS chiffrent le trafic web et authentifient les serveurs ; les certificats S/MIME permettent de signer et de chiffrer les courriels ; les certificats de signature de code prouvent l'intégrité des logiciels et l'identité de leur éditeur ; et les certificats client permettent l'authentification mutuelle pour les VPN et les API. Nous allons maintenant étudier les stratégies de mots de passe et l'authentification multifacteur.