Atelier réécrit le 24 octobre 2026. Lina doit livrer un portail HTTPS interne. Nous allons créer son autorité de laboratoire, émettre son certificat, démarrer le serveur, provoquer deux erreurs puis renouveler le certificat et vérifier celui réellement servi.
Le rejeu de cet atelier a été confirmé avec succès par Kenawek le 24 octobre 2026. Les sorties présentées restent illustratives ; elles ne sont pas des captures du rejeu. Adaptez les commandes à votre environnement et consignez les écarts.
En résumé
- Le laboratoire construit une racine locale puis un certificat pour service.example.test.
- Le serveur HTTPS écoute sur 127.0.0.1:8443 et le client utilise une confiance explicite.
- Le mauvais nom et l’absence de racine sont testés séparément, sans retirer la validation.
- Le renouvellement est contrôlé sur le certificat réellement présenté après redémarrage.
- Un PFX et une signature de fichier complètent le scénario, avec protection des clés et arrêt du service.
- Autorité localeca.key.pem signe ; ne rejoint pas le serveur
- Serveur127.0.0.1:8443, certificat service.example.test
- Clients_client et ca.pem, sans modifier la confiance système
1. Préparer deux terminaux Bash
Utilisez une VM Debian/Ubuntu, Bash et deux terminaux dans le même dossier. Les commandes suivantes ne sont pas du PowerShell. Le dossier doit être neuf ; ne poursuivez pas si mkdir indique qu’il existe déjà.
sudo apt update
sudo apt install openssl ca-certificates
openssl version -a
umask 077
mkdir labo-openssl
cd labo-openssl
pwdumask 077 réserve les nouveaux fichiers à votre utilisateur. Notez la version. Les commandes de sortie peuvent écraser des fichiers : utilisez uniquement ce dossier de laboratoire.
2. Créer la racine de confiance
Dans le terminal A, générez une clé d’autorité chiffrée puis son certificat autosigné. Saisissez une phrase secrète fictive à l’invite.
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -aes-256-cbc -out ca.key.pem
openssl req -new -x509 -key ca.key.pem -sha256 -days 30 -subj "/CN=Kenawek Lab CA" -addext "basicConstraints=critical,CA:TRUE,pathlen:0" -addext "keyUsage=critical,keyCertSign,cRLSign" -addext "subjectKeyIdentifier=hash" -out ca.pem
openssl x509 -in ca.pem -noout -subject -dates -ext basicConstraintsCA:TRUE autorise la fonction d’autorité ; keyCertSign autorise la signature de certificats. pathlen:0 interdit les intermédiaires sous cette racine. Notre chaîne courte racine → serveur facilite l’exercice ; cette micro-PKI ne remplace pas une autorité de production.
3. Émettre le certificat du portail
Le serveur reçoit sa propre clé. Elle n’est pas chiffrée dans ce laboratoire pour permettre le démarrage sans invite ; le dossier reste privé. En production, choisissez la protection de clé avec le mécanisme de démarrage et de stockage des secrets.
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out serveur.key.pem
openssl req -new -key serveur.key.pem -subj "/CN=service.example.test" -out serveur.csr
openssl req -in serveur.csr -noout -verify
cat > serveur.ext <<'EOF'
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectAltName=DNS:service.example.test
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF
openssl x509 -req -in serveur.csr -CA ca.pem -CAkey ca.key.pem -CAcreateserial -days 7 -sha256 -extfile serveur.ext -out serveur.pem
openssl x509 -in serveur.pem -noout -subject -issuer -serial -dates -ext subjectAltNameLe SAN fixe le nom à vérifier ; serverAuth limite l’usage prévu. Le fichier ca.srl conserve le compteur de série utilisé pour l’émission. La vérification de la CSR contrôle sa signature, pas la propriété du nom.
4. Vérifier la clé, le nom et la chaîne
Avant de démarrer, comparez les clés publiques puis validez le certificat.
openssl pkey -in serveur.key.pem -check -noout
openssl pkey -in serveur.key.pem -pubout -out cle-publique.pem
openssl x509 -in serveur.pem -pubkey -noout -out certificat-publique.pem
openssl pkey -pubin -in cle-publique.pem -outform DER -out cle.der
openssl pkey -pubin -in certificat-publique.pem -outform DER -out certificat.der
openssl dgst -sha256 cle.der certificat.der
openssl verify -CAfile ca.pem -purpose sslserver -verify_hostname service.example.test serveur.pemLes empreintes DER doivent correspondre. Le dernier résultat attendu est serveur.pem: OK. Cela vérifie les fichiers, pas encore le serveur réseau.
5. Démarrer HTTPS
Dans le terminal A, laissez ce serveur au premier plan. -www sert une page de diagnostic. La liaison à 127.0.0.1 évite une publication sur le réseau.
openssl s_server -accept 127.0.0.1:8443 -cert serveur.pem -key serveur.key.pem -www -min_protocol TLSv1.2Dans le terminal B, placez-vous dans labo-openssl puis poursuivez. Si le port est occupé, identifiez le processus et choisissez un port libre dans toutes les commandes ; n’arrêtez pas arbitrairement un service existant.
6. Valider une connexion et lire HTTP
Le client se connecte à une IP tout en demandant et vérifiant le nom du certificat. Aucun changement DNS ou hosts n’est nécessaire.
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile ca.pem -brief </dev/null
printf 'GET / HTTP/1.0
Host: service.example.test
' | openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile ca.pem -quiet-servername envoie le SNI, -verify_hostname contrôle l’identité et -verify_return_error impose l’arrêt sur erreur. Le fichier ca.pem fournit la confiance pour cette commande uniquement. La réponse HTTP doit arriver après la négociation.
7. Provoquer deux échecs et vérifier TLS 1.2/1.3
Lina doit savoir distinguer une erreur de nom d’une racine inconnue. Exécutez les commandes séparément et observez immédiatement leur code de retour.
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname autre.example.test -verify_return_error -CAfile ca.pem -brief </dev/null
echo "Code mauvais nom : $?"
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -no-CAfile -no-CApath -no-CAstore -brief </dev/null
echo "Code sans confiance : $?"
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile ca.pem -tls1_2 -brief </dev/null
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile ca.pem -tls1_3 -brief </dev/nullLes deux premières commandes doivent échouer pour les raisons prévues. Un port fermé n’est pas un contre-test de certificat réussi. Les deux suivantes mesurent explicitement les protocoles selon la compilation utilisée ; ne supprimez pas la validation pour obtenir artificiellement un succès.
8. Exporter et renouveler
Le PFX contient la clé privée : saisissez un mot de passe d’export de laboratoire. L’alerte à 30 jours est attendue puisque notre certificat ne dure que sept jours.
openssl pkcs12 -export -inkey serveur.key.pem -in serveur.pem -certfile ca.pem -name portail-labo -out portail.p12
openssl pkcs12 -in portail.p12 -info -noout
openssl x509 -in serveur.pem -noout -checkend 2592000
echo "Alerte expiration : $?"
openssl x509 -req -in serveur.csr -CA ca.pem -CAkey ca.key.pem -CAserial ca.srl -days 14 -sha256 -extfile serveur.ext -out serveur-renouvele.pem
openssl verify -CAfile ca.pem -purpose sslserver -verify_hostname service.example.test serveur-renouvele.pem
openssl x509 -in serveur-renouvele.pem -noout -serial -datesNous réutilisons la clé pour isoler le changement de certificat. Une clé compromise devrait être remplacée. Arrêtez le serveur du terminal A avec Ctrl+C, puis relancez la commande de l’étape 5 en remplaçant serveur.pem par serveur-renouvele.pem.
9. Vérifier le certificat réellement servi
Le renouvellement n’est terminé que lorsque le client reçoit le nouvel objet.
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile ca.pem -showcerts </dev/null > connexion-apres.txt 2> validation-apres.txt
echo "Code TLS : $?"
cat validation-apres.txt
openssl x509 -in connexion-apres.txt -noout -serial -fingerprint -sha256
openssl x509 -in serveur-renouvele.pem -noout -serial -fingerprint -sha256Les séries et empreintes doivent correspondre. Sinon, vérifiez le processus et le point de terminaison. Un fichier correct sur disque ne prouve pas un déploiement réussi.
10. Signer la recette, puis arrêter le labo
La clé serveur du laboratoire sert ici à illustrer une signature de fichier ; une production séparerait les usages selon sa politique.
printf 'Recette TLS fictive
' > recette.txt
openssl dgst -sha256 -sign serveur.key.pem -out recette.sig recette.txt
openssl dgst -sha256 -verify cle-publique.pem -signature recette.sig recette.txt
cp recette.txt recette-modifiee.txt
printf 'Modification
' >> recette-modifiee.txt
openssl dgst -sha256 -verify cle-publique.pem -signature recette.sig recette-modifiee.txtLa première vérification doit réussir et celle du fichier modifié échouer. Arrêtez le serveur avec Ctrl+C. Ne joignez aucune clé ni PFX au rapport. Retirez les fichiers privés suivant votre procédure de laboratoire ; aucune racine n’a été installée dans le système.
Approfondir : mécanismes, limites, FAQ et sources
1. OpenSSL : bibliothèque et boîte à outils
OpenSSL fournit des bibliothèques cryptographiques et un programme en ligne de commande. Une application peut utiliser les bibliothèques sans appeler la commande openssl. La version affichée dans votre terminal ne prouve donc pas quelle bibliothèque utilise un serveur, un conteneur ou un équipement.
TLS protège les communications. « SSL » reste dans le nom du projet et certains usages historiques ; cela ne constitue pas une recommandation d’activer les anciens protocoles SSL.
openssl version -aConservez cette sortie avec le système, le paquet installé et la date de mesure. Elle aide à identifier la compilation et les chemins de configuration. Utilisez un canal de distribution maintenu et contrôlez les composants réellement chargés par les applications. Mettre à jour la commande ne renouvelle pas les certificats et ne redémarre pas automatiquement les services.
2. Clé privée, certificat et CSR : les distinguer
| Objet ou contrôle | Rôle | Limite |
|---|---|---|
| Clé privée | Permet les opérations réservées au détenteur, notamment des signatures. | Ne jamais la transmettre avec une simple demande de certificat. |
| Clé publique | Permet notamment de vérifier une signature correspondante. | Son association à une identité doit être établie. |
| CSR | Demande de certificat contenant une clé publique et des informations demandées. | Ce n’est pas un certificat émis. |
| Certificat X.509 | Associe une clé publique à des identités et usages, avec une signature. | Vérifier nom, dates, extensions et chaîne. |
| Autorité de certification | Émet des certificats selon une politique. | La confiance résulte d’un choix contrôlé, pas du fichier reçu seul. |
Un certificat contient une clé publique, jamais la clé privée correspondante. Le fichier qui le transporte peut toutefois contenir d’autres objets. L’extension .pem ne garantit donc pas qu’un fichier est public.
Le serveur prouve la possession du secret associé au certificat pendant l’authentification TLS. Les données sont protégées par les mécanismes négociés. Le certificat n’est pas une garantie générale sur la sécurité de l’application ou la bonne intention du site.
3. Comprendre la chaîne de confiance
- Certificat du serviceIdentité demandée et clé publique
- IntermédiaireSignature et contraintes de certification
- Racine approuvéeAncrage de confiance du client
- ValidationNom, dates, usages et politique
Le serveur présente généralement son certificat et les intermédiaires nécessaires. La racine est normalement déjà connue du client. Un intermédiaire reçu pendant une connexion chiffrée ne devient pas fiable simplement parce qu’il a été transmis.
Deux clients peuvent produire des résultats différents selon leurs magasins, versions et politiques. Un certificat autosigné peut être utile dans un laboratoire ou une infrastructure privée maîtrisée, mais il n’est pas automatiquement reconnu par un navigateur. Ajouter une racine au magasin système crée une confiance durable ; ce n’est pas un contournement anodin d’un message d’erreur.
4. Lire un certificat et anticiper son expiration
Le fichier serveur.pem désigne ici un certificat public de test. La commande x509 permet de le lire sans le modifier :
openssl x509 -in serveur.pem -noout -subject -issuer -dates -ext subjectAltNameLe sujet et l’émetteur aident à identifier les objets ; leurs libellés ne prouvent pas la confiance. Les dates sont des bornes de validité. L’extension Subject Alternative Name, ou SAN, contient les identités à examiner pour le service. Ne vous contentez pas du Common Name affiché dans le sujet.
openssl x509 -in serveur.pem -noout -fingerprint -sha256
openssl x509 -in serveur.pem -noout -checkend 2592000La première commande produit l’empreinte du certificat. La seconde examine l’expiration dans les 30 prochains jours, exprimés en secondes. Un code de sortie non nul peut signaler cette échéance ou une erreur de traitement : distinguez expiration proche, fichier absent et format invalide dans votre supervision. Ce contrôle ne valide ni le nom ni la chaîne.
5. Diagnostiquer TLS avec s_client
La commande s_client peut poursuivre malgré des erreurs de certificat si l’arrêt sur erreur n’est pas demandé. Voir une connexion établie ou une suite cryptographique ne suffit pas à valider le serveur.
Supposons un service TLS de laboratoire préparé sur 127.0.0.1:8443, un certificat pour service.example.test et sa racine approuvée pour l’exercice dans racine-labo.pem :
openssl s_client -connect 127.0.0.1:8443 -servername service.example.test -verify_hostname service.example.test -verify_return_error -CAfile racine-labo.pem -showcerts-connect fixe la destination ; -servername envoie le nom SNI pour sélectionner le service virtuel. -verify_hostname demande la validation de l’identité, tandis que -verify_return_error impose l’arrêt en cas d’erreur de validation. Le fichier de confiance ne s’installe pas dans le magasin système.
-showcerts affiche les certificats transmis, pas une preuve de validité. La commande peut rester interactive après la négociation : terminez-la après les observations prévues. En automatisation, gérez la fermeture de l’entrée, le délai maximal et le code de sortie avec les mécanismes de votre shell.
6. Vérifier une chaîne localement
Pour séparer un problème de fichiers d’un problème réseau, verify examine le certificat local. intermediaires.pem contient ici les intermédiaires publics et racine-labo.pem l’ancrage approuvé :
openssl verify -CAfile racine-labo.pem -untrusted intermediaires.pem -purpose sslserver -verify_hostname service.example.test serveur.pemFournir un intermédiaire pour construire une chaîne n’équivaut pas à le choisir comme racine de confiance : c’est la différence entre les deux paramètres de fichiers. Retirez -untrusted et son argument si votre laboratoire n’a pas d’intermédiaire.
Un résultat positif concerne les contrôles demandés et les informations disponibles. Il ne prouve pas que le service distant présente ce certificat, ni que toutes les politiques du navigateur sont satisfaites. CRL et OCSP demandent une politique de révocation adaptée ; cette commande ne réalise pas automatiquement une enquête complète en ligne.
7. Générer une clé et une CSR de laboratoire
Travaillez dans un nouveau dossier privé avec des noms inutilisés : les sorties peuvent écraser des fichiers existants. Protégez le dossier avec les permissions ou ACL du système. Les objets créés ici ne doivent pas remplacer des clés actives.
genpkey génère une clé RSA chiffrée par une phrase secrète saisie à l’invite. Le choix RSA 3072 est illustratif ; l’algorithme doit correspondre aux clients et à la politique du service.
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -aes-256-cbc -out labo-cle.pemNe placez pas la phrase secrète dans une commande partagée. Elle protège le fichier au repos, sans remplacer le contrôle des accès. Un service automatisé demande une gestion des clés appropriée, éventuellement matérielle ou fournie par une plateforme de secrets.
openssl req -new -key labo-cle.pem -out labo-demande.csr -subj "/CN=service.example.test" -addext "subjectAltName=DNS:service.example.test"
openssl req -in labo-demande.csr -noout -text -verifyLa commande req prépare puis examine une CSR. La signature de la demande ne prouve pas la possession du domaine : l’autorité réalise ses propres contrôles et décide des extensions acceptées. Vérifiez de nouveau le SAN dans le certificat réellement émis. Les exemples supposent un shell transmettant littéralement l’argument -subj ; certains environnements MSYS demandent une attention particulière à la conversion des chemins.
8. Comparer la clé et le certificat
Une erreur de déploiement peut associer un certificat à une mauvaise clé. Comparer leurs représentations publiques permet un contrôle sans afficher le secret. Utilisez des noms de sortie inutilisés :
openssl pkey -in labo-cle.pem -pubout -out cle-publique.pem
openssl x509 -in serveur.pem -pubkey -noout -out certificat-publique.pem
openssl pkey -pubin -in cle-publique.pem -outform DER -out cle-publique.der
openssl pkey -pubin -in certificat-publique.pem -outform DER -out certificat-publique.der
openssl dgst -sha256 cle-publique.der certificat-publique.derLa normalisation en DER évite de comparer seulement des mises en forme textuelles. Des empreintes identiques indiquent ici des représentations publiques identiques. Le certificat choisi doit correspondre à la CSR précédente ; sinon, une différence est attendue.
La documentation de pkey décrit ces transformations. Ce contrôle de correspondance ne valide pas le nom, la période ou la chaîne : il répond à une question précise avant déploiement.
9. PEM, DER, PFX et PKCS#12
| Objet ou contrôle | Rôle | Limite |
|---|---|---|
| PEM | Objets encodés en texte avec des en-têtes. | Peut contenir une clé privée, malgré son aspect lisible. |
| DER | Encodage binaire d’un objet ASN.1. | Indiquer le type et le format à la commande. |
| PKCS#12 / PFX | Conteneur pouvant réunir clé, certificat et chaîne. | Traiter comme secret tant que le contenu n’est pas établi. |
| CRT / CER / KEY | Extensions couramment utilisées. | Ne garantissent ni encodage ni protection. |
openssl x509 -in serveur.pem -outform DER -out serveur.der
openssl x509 -inform DER -in serveur.der -out serveur-relu.pemCes conversions changent la représentation du certificat, pas sa signature ou ses dates. Renommer une extension ne convertit pas le contenu.
openssl pkcs12 -in labo-identite.p12 -info -nooutCette commande inspecte un conteneur existant sans exporter ses objets. L’exemple suivant est une opération distincte de création : ne l’exécutez pas sur un fichier à préserver.
openssl pkcs12 -export -inkey labo-cle.pem -in serveur.pem -certfile intermediaires.pem -out labo-identite.p12Elle suppose une clé correspondante et une chaîne adaptée ; retirez -certfile et son argument si aucun intermédiaire n’est nécessaire. PKCS#12 utilise des paramètres dont la compatibilité varie entre logiciels. Diagnostiquez les algorithmes d’un ancien fichier avant d’activer un mode hérité. Ne modifiez pas globalement la sécurité du système pour un transfert ponctuel.
10. Empreintes, signatures et données aléatoires
Une empreinte compare un fichier à une référence, mais n’identifie pas l’auteur si la référence vient du même canal compromis. Une signature apporte une vérification supplémentaire si la clé publique de vérification a été obtenue de manière fiable.
openssl dgst -sha256 document-test.txt
openssl dgst -sha256 -sign labo-cle.pem -out document-test.sig document-test.txt
openssl dgst -sha256 -verify cle-publique.pem -signature document-test.sig document-test.txtCes exemples dgst supposent un document fictif et la paire RSA précédente. Pour le contre-test, modifiez une copie du document : sa vérification doit échouer. Cette signature n’embarque pas une politique complète de certificats ou d’horodatage.
openssl rand -hex 32rand demande ici 32 octets aléatoires, représentés par 64 caractères hexadécimaux. Si la sortie sert de secret, ne la placez pas dans les journaux ou un rapport. Base64 et hexadécimal sont des encodages, pas du chiffrement.
11. Chiffrement de fichiers : éviter une recette trompeuse
Le chiffrement doit traiter la confidentialité, mais aussi l’intégrité, la dérivation des clés, les nonces et la récupération. Une commande courte ne constitue pas automatiquement un format sûr.
La documentation de enc précise que cette commande ne prend pas en charge les modes authentifiés GCM et CCM. Ajouter PBKDF2 à une recette ne lui apporte pas, à lui seul, une protection d’intégrité.
Pour un échange ou une sauvegarde en production, choisissez un format et un outil maintenus qui gèrent l’ensemble des besoins, puis testez la restauration. Évitez de créer un protocole maison en assemblant des primitives. Comprendre ces primitives aide à poser les bonnes questions ; cela ne remplace pas la conception et la revue d’un système cryptographique.
12. TLS, STARTTLS et authentification mutuelle
Un service TLS direct attend une négociation immédiatement. Avec STARTTLS, le dialogue commence par le protocole applicatif avant le passage à TLS. Les confondre peut produire wrong version number sans prouver une version TLS obsolète. L’option -starttls de s_client doit correspondre au protocole réellement testé.
Le mTLS ajoute une authentification du client par certificat. Il faut examiner les deux chaînes et les usages permis, puis la façon dont le service transforme l’identité en permissions. Un certificat client accepté ne devrait pas ouvrir automatiquement toutes les ressources.
Distinguez version TLS négociée, suites disponibles et politique applicative. Les réglages de suites pour TLS 1.3 et les versions antérieures ne sont pas interchangeables. Une seule connexion réussie ne recense pas toutes les configurations acceptées. Pour approfondir l’exposition réseau et web, consultez le guide Nmap et Nikto.
13. Comprendre les erreurs sans retirer les contrôles
| Objet ou contrôle | Rôle | Limite |
|---|---|---|
| Unable to get local issuer certificate | Examiner intermédiaires et confiance locale. | Ne pas désactiver la validation. |
| Hostname mismatch | Comparer SAN, nom attendu et service virtuel. | SNI n’est pas la vérification du nom. |
| Certificate has expired | Vérifier certificat réellement servi et horloge. | Le fichier renouvelé sur disque ne suffit pas. |
| Wrong version number | Vérifier port, service en clair, proxy et STARTTLS. | Ne pas autoriser aveuglément des protocoles anciens. |
| Unsupported algorithm | Examiner version, fournisseurs et ancien format. | Éviter un abaissement global de sécurité. |
| Key values mismatch | Comparer les clés publiques. | Ne pas regénérer sans identifier les dépendances. |
OpenSSL 3 utilise notamment une architecture de fournisseurs cryptographiques, décrite dans le guide de migration. La disponibilité d’un algorithme dépend de la configuration. La présence d’un fournisseur FIPS ne prouve pas à elle seule la conformité d’une application entière.
Documentez le diagnostic avant de changer les paramètres. Toute exception doit être limitée, attribuée et revue. Réussir à se connecter après suppression des vérifications n’est pas une preuve de résolution.
14. Renouvellement, supervision et recette
- InventorierNom, responsable et dépendances
- ÉmettreClé, CSR et politique
- DéployerChaîne, permissions et rechargement
- VérifierCertificat effectivement servi
- SuperviserÉchéance et erreurs
Un frontal, un proxy et un serveur applicatif peuvent terminer TLS à des endroits différents. Conservez un inventaire par service et vérifiez les chemins réellement utilisés, y compris les communications internes concernées.
Préparez le rechargement, les permissions et les tests métier avant le changement. Un retour arrière peut restaurer une configuration, mais ne doit pas réintroduire une clé compromise ou un certificat révoqué. Ces situations nécessitent une remédiation adaptée.
La recette proposée comporte un cas positif, puis des contre-tests : bon nom et bonne racine, nom incorrect, racine non approuvée, enfin document signé modifié. Notez les versions, commandes, codes de sortie et résultats réels. Une erreur de fichier n’est pas le même résultat qu’un refus attendu de validation.
Après l’exercice, retirez les fichiers temporaires selon le plan prévu, protégez les clés conservées et vérifiez qu’aucune racine de test n’a été ajoutée durablement aux postes. Les exemples de ce guide ne demandent pas cette installation.
15. Questions fréquentes
Un certificat autosigné chiffre-t-il moins bien ?
Le caractère autosigné concerne la confiance dans l’identité, pas à lui seul la solidité du chiffrement négocié. Sans ancrage fiable, le client ne sait pas suffisamment à qui il parle.
Pourquoi mon navigateur et OpenSSL diffèrent-ils ?
Ils peuvent utiliser des magasins, politiques ou chemins réseau différents. Comparez le nom demandé, les certificats reçus et les contrôles effectués avant de conclure.
Faut-il remplacer la clé à chaque renouvellement ?
Suivez la politique de l’organisation et de l’autorité. Une compromission impose de traiter la clé et le certificat concernés ; ce n’est pas un simple renouvellement calendaire.
Peut-on partager un certificat ?
Le certificat est public, mais vérifiez que son fichier ne contient pas aussi une clé privée. Un export PFX demande davantage de précautions qu’un certificat seul.
Ces commandes sont-elles prêtes pour la production ?
Les fichiers et noms sont ceux d’un laboratoire. Vérifiez l’aide de votre version et rejouez les procédures avant un changement réel. Lecture, création de fichiers et connexion réseau ont des effets différents.
Sources et références
Documentation officielle consultée le 24 octobre 2026. Les pages « master » évoluent avec le projet : consultez aussi le manuel de votre version installée. Schémas pédagogiques et procédures dont le rejeu a été confirmé par Kenawek, sans publication des journaux bruts.