Cet article expliquera comment utiliser les certificats émis par une autorité de certification (CA) tierce, telle que Let's Encrypt, Comodo, Symantec, Digicert, etc. Il couvrira également le fonctionnement des certificats en général.
Synopsis
Les certificats ont deux objectifs principaux : chiffrer la communication entre deux entités et confirmer l'authenticité de l'entité. Le premier peut être accordé par un certificat dit auto-signé, mais pour authentifier l'entité, vous avez besoin d'un certificat de confiance mondiale émis par l'autorité de certification racine ou intermédiaire. Cet article explique comment les certificats réalisent généralement cette authentification, comment modifier le format du certificat pour qu'il fonctionne avec d'autres appareils, y compris nos pare-feu, comment importer le certificat sur votre pare-feu et comment les certificats doivent être gérés pour éviter les risques de sécurité.
Table des matières
- Comment fonctionne un certificat ?
- Certificats auto-signés
- Travailler avec des certificats
- Importation de certificats dans les pare-feu USG/ATP
- Sécurité du certificat
Comment fonctionne un certificat ?
Chaque certificat se compose de deux parties : le certificat (également appelé clé publique) et la clé privée. Le certificat peut être partagé publiquement et contient simplement des informations sur les fins pour lesquelles le certificat a été délivré et à quelle entité le certificat a été délivré - cela peut être votre FQDN, votre adresse e-mail ou une autre valeur.
Les certificats ont une période de validité limitée - cela aide dans les situations où un ancien certificat avec une clé privée est déterré quelque part après des décennies. Si la validité était infinie, le certificat pourrait toujours être utilisé à des fins malveillantes par toute personne qui mettrait la main dessus. A partir de 2021, il est recommandé de ne pas utiliser une période de validité supérieure à un an. Avec l'avènement des mécanismes de réémission automatique tels que CertBot, cette période peut devenir beaucoup plus courte pour améliorer encore la sécurité.
Les certificats peuvent être révoqués en cas de fuite de la clé privée - et par mesure de précaution, toute faille de sécurité qui compromet le matériel contenant des clés privées doit être suivie d'une révocation de certificat et d'une réémission ultérieure de nouveaux certificats.
Les certificats peuvent être délivrés à diverses entités, telles que FQDN, E-mail, même une adresse IP ou un prénom. Bien qu'il soit techniquement possible d'avoir des certificats FQDN génériques et que ceux-ci soient souvent préférés par les utilisateurs, gardez à l'esprit qu'en cas de fuite de clé privée d'un service spécifique, le certificat générique authentifie l'intégralité du FQDN - en conséquence, une fuite du La clé privée sur un serveur Web qui est utilisée pour la simple présentation de l'entreprise peut également être utilisée pour les attaques MITM entre le serveur Exchange ou le système CRM. Garder les certificats indépendants pour chaque sous-domaine permet d'atténuer l'impact de la fuite jusqu'à ce que le certificat soit révoqué.
Bien qu'il soit également possible d'émettre des certificats à l'adresse IP, cela est obsolète. La raison derrière cela est que les adresses IP peuvent être modifiées facilement par rapport au FQDN.
Le principe de base des certificats est assez simple. Dans un exemple, Alice veut accéder au serveur de Bob, mais le problème est qu'elle n'a jamais été là, donc ils n'ont jamais pu échanger un secret commun pour s'authentifier. Comment Alice peut-elle être sûre qu'elle se connecte réellement à Bob ? C'est là que Charlie entre en jeu. Alice connaît Charlie et a ajouté son certificat au référentiel de certificats racine. Par conséquent, Alice considère Charlie comme une entité de confiance. Si Bob a son propre certificat et sa propre clé privée émis par Charlie, il peut s'authentifier auprès d'Alice et peu importe qu'Alice n'ait jamais été en contact avec Bob auparavant, car Charlie a la confiance de Bob, et comme Alice fait confiance à Charlie, elle fait également confiance à Bob. . C'est ce qu'on appelle une chaîne de confiance.
Jetons un coup d'œil à la chaîne de confiance de notre certificat Web Support Campus :
Notez qu'il existe également une autre entité appelée R3. C'est ce qu'on appelle la CA intermédiaire, tandis que la CA racine DST X3 est la CA racine. Le certificat ne peut avoir qu'une seule autorité de certification racine, mais il peut y avoir plusieurs autorités de certification intermédiaires. L'AC intermédiaire est une entité qui a reçu l'autorisation d'émettre des certificats pour ses clients. Tant que votre PC a le certificat DST Root CA X3 dans la liste des certificats racines de confiance, il considérera support.zyxel.eu comme étant de confiance.
Certificats auto-signés
Par défaut, nos pare-feu (et de nombreux autres appareils) utilisent des certificats auto-signés pour établir une connexion TLS cryptée. Un tel certificat est signalé par un message d'erreur bien connu par le navigateur : 
Il y a deux raisons pour lesquelles cela se produit. La première raison est que le certificat est essentiellement un certificat CA racine qui n'est pas présent dans votre système. Mais le simple fait de l'installer en tant qu'autorité de certification racine sur votre ordinateur ne fera pas l'affaire, car le certificat n'est pas émis pour votre adresse IP ou votre domaine. Le certificat est cependant adapté à une connexion sécurisée, et son utilisation ne présente aucun risque de sécurité tant que sa clé privée n'est pas divulguée - le seul problème ici est que l'identité ne peut pas être confirmée.
Travailler avec des certificats
Au fil des ans, de nombreux formats de certificats ont été développés. Les certificats utilisent cependant toujours le même principe et tous les formats peuvent être convertis en d'autres formats.
Formats de certificat
Le format le plus ancien serait le PEM, qui contient la clé codée ASCII. La raison derrière cela est l'utilisation originale dans les e-mails cryptés, où le certificat binaire peut être malformé. Les PEM sont courants dans les systèmes Unix et il est probable que votre autorité de certification vous ait envoyé un certificat ainsi qu'une clé privée au format PEM. Utilise généralement l'extension de fichier .pem ou .cer.
DER est une forme binaire de certificat au format ASCII PEM. Tous les types de certificats et de clés privées peuvent être encodés au format DER. Ce format prend en charge le stockage d'un seul certificat et n'inclut pas de clé privée pour l'autorité de certification intermédiaire/racine. Ils ont l'extension .der ou .cer et sont le plus souvent utilisés sur les plateformes Java.
PKCS#7 est un format binaire qui permet de contenir des certificats ou toute la chaîne de confiance de certificats dans un seul fichier. Cependant, aucune clé privée ne peut être stockée dans ce format. Ce format est le plus souvent utilisé par les AC pour fournir une chaîne de confiance complète. Utilise l'extension .p7b.
PKCS#12, également connu sous le nom de PFX, est un format qui peut également contenir l'ensemble de la chaîne de confiance et la clé privée. Généralement, ce format est fourni par les autorités de certification, car il peut être sécurisé par un mot de passe. Utilise généralement l'extension .p12 ou .pfx.
Outils de certification
Windows a un utilitaire CLI système intégré certutil qui peut être utilisé pour convertir des certificats. Les plugins de gestion dans Microsoft Management Console permettent également la gestion des certificats.
L'utilitaire open source appelé OpenSSL est également capable de gérer et de convertir les certificats. Les binaires sont disponibles pour Windows, Linux et macOS (et de nombreuses autres plateformes)
Commandes certutil utiles :
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Commandes OpenSSL utiles :
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importation du certificat dans les pare-feu USG/ATP
La conception actuelle (à partir de juin 2021) est limitée à l'importation de certificats sans clés intermédiaires. Si le certificat contient une clé intermédiaire, le fichier sera analysé de manière incorrecte et la tentative d'utilisation d'un tel certificat peut entraîner l'indisponibilité du service (comme WebGUI). C'est une bonne idée d'obtenir le certificat au format .pem et de l'exporter au format .pfx en utilisant certutil ou OpenSSL. Le certificat peut être importé, ainsi que son mot de passe dans le menu suivant :
Configuration > Objects > Certificates > My Certificates
Sécurité du certificat
Chaque certificat a sa clé privée respective. Alors qu'un certificat est une information publique, la clé privée doit être traitée comme un secret - et ne doit être partagée par personne. Pas même avec nous chez Zyxel - le seul moyen valable est d'utiliser des outils d'assistance à distance tels que TeamViewer. Lors du stockage de la clé privée au format pem, vérifiez les autorisations d'accès à la clé privée pour éviter sa fuite. Utilisez toujours le cryptage par mot de passe au format pfx pour fournir au moins un certain degré de sécurité lors de l'exportation de certificats. Tout certificat contenant la clé privée divulguée doit être révoqué immédiatement.
AVERTISSEMENT:
Cher client, sachez que nous utilisons la traduction automatique pour fournir des articles dans votre langue locale. Tous les textes peuvent ne pas être traduits avec précision. S'il y a des questions ou des divergences sur l'exactitude des informations dans la version traduite, veuillez consulter l'article original ici : Version originale
Commentaires
0 commentaireVous devez vous connecter pour laisser un commentaire.