Validation des certificats
Vérifier l’identité du serveur
Validation des certificats est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.
Pourquoi valider les certificats ?
Le chiffrement seul ne suffit pas. Si vous chiffrez une connexion avec un attaquant, vous avez sécurisé la mauvaise conversation.
La validation des certificats garantit que vous communiquez bien avec le serveur prévu.
Ce que vérifie le client
Pendant la négociation, le client vérifie plusieurs éléments :
- La chaîne mène à une racine de confiance.
- Le certificat se trouve dans sa période de validité.
- Le certificat n’est pas révoqué.
- Le nom d’hôte correspond.
Correspondance du nom d’hôte
Le nom d’hôte auquel vous vous êtes connecté doit correspondre aux entrées Nom alternatif du sujet (SAN) du certificat.
Le champ Nom commun (CN) historique est obsolète à cette fin ; les clients modernes exigent SAN.
openssl x509 -in cert.pem -noout -ext subjectAltNameDates de validité
Chaque certificat possède des horodatages Pas avant et Pas après. En dehors de cette période, le certificat est rejeté.
openssl x509 -in cert.pem -noout -datesVérification de la chaîne de confiance
Le client parcourt la chaîne, du certificat feuille jusqu’à une racine de son magasin de confiance, en vérifiant chaque signature.
S’il n’existe aucun chemin vers une racine de confiance, la validation échoue même si le certificat semble correct.
Vérification de la révocation
Le client vérifie si le certificat a été révoqué prématurément à l’aide d’OCSP ou d’une CRL.
De nombreux navigateurs s’appuient sur l’agrafage OCSP ou sur des listes de révocation sélectionnées pour accélérer les vérifications.
Contraintes d’utilisation des clés
Les certificats déclarent les utilisations autorisées dans les extensions Utilisation de clé et Utilisation étendue de clé.
Un certificat de serveur doit inclure serverAuth ; un certificat CA doit avoir l’indicateur CA activé. Les certificats utilisés à mauvais escient sont rejetés.
Épinglage des certificats
L’épinglage inscrit en dur dans le client le certificat ou la clé publique attendu (ce qui est courant dans les applications mobiles).
Même un certificat valide, signé par une CA mais inattendu, est rejeté, ce qui protège contre les CA malveillantes ou compromises.
Échec de la validation
Les erreurs de validation courantes comprennent :
- NET::ERR_CERT_DATE_INVALID (expiré)
- NET::ERR_CERT_COMMON_NAME_INVALID (le nom d’hôte ne correspond pas)
- NET::ERR_CERT_AUTHORITY_INVALID (émetteur non fiable)
Le danger de sauter la validation
Désactiver la vérification des certificats (par exemple avec curl -k ou verify=False) supprime toute protection contre l’usurpation d’identité.
Vous ne devez jamais faire cela dans du code destiné à la production, car cela ouvre la porte aux attaques de l’intercepteur.
# DO NOT do this in production
curl -k https://example.comVérification depuis la ligne de commande
Vous pouvez exécuter une vérification complète de la validation sur un serveur en ligne.
openssl s_client -connect example.com:443 \
-verify_hostname example.com -verify_return_errorVérification rapide
Un développeur définit verify=False pour faire taire une erreur de certificat en production. Quel risque cela introduit-il ?
Récapitulatif
Vous avez appris comment les clients effectuent la validation des certificats.
- Les vérifications incluent la confiance dans la chaîne, les dates de validité, la révocation et le nom d’hôte (SAN).
- L’épinglage ajoute une protection contre les CA malveillantes.
- Ne désactivez jamais la validation en production.
Ensuite, nous examinerons les attaques courantes contre TLS.
Questions Fréquemment Posées
La leçon « Validation des certificats » est-elle gratuite ?
Oui — le texte complet de « Validation des certificats » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Validation des certificats » ?
Vérifier l’identité du serveur Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?
Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Validation des certificats » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?
Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- La négociation TLS
- Suites cryptographiques
- Validation des certificats
- Attaques TLS courantes