Dans les projets web comme dans l’IoT, la génération d’un certificat SSL finit tôt ou tard par arriver sur la table. Pour un environnement de test, un démonstrateur chez un client ou un petit serveur interne, attendre un certificat émis par une autorité tierce ralentit inutilement les choses.
C’est là qu’OpenSSL devient l’outil de base pour produire une clé privée, une demande de signature (CSR) et, au besoin, un certificat auto-signé avec SAN bien paramétrés. La mécanique n’est pas complexe, mais elle pardonne rarement les erreurs de copier-coller.
Beaucoup de pannes « invisibles » en HTTPS viennent d’un simple décalage entre le nom de domaine servi par le serveur et ce qui a été mis dans le certificat, en particulier dans l’extension Subject Alternative Name. D’autres problèmes apparaissent lorsque la clé privée est mal protégée ou partagée à la légère entre environnements.
Entre un POC bricolé et une plate-forme industrielle exposée à Internet, le geste technique reste le même, mais les exigences de sécurité et de traçabilité changent du tout au tout. Ce texte suit ce fil : partir de la commande OpenSSL brute pour arriver à une démarche reproductible et maîtrisée.
- Comprendre en bref la différence entre certificat auto-signé, CSR et certificat émis par une autorité.
- Savoir générer une clé privée, un CSR et un certificat SSL avec OpenSSL, en ligne de commande, sans script magique.
- Utiliser correctement SAN pour éviter les alertes de navigateur et les erreurs côté client.
- Organiser les fichiers (clé, CSR, certificats) pour un déploiement propre sur un serveur web ou un équipement IoT.
- Éviter les pièges courants qui plombent les démos le lundi matin : mauvais CN, dates, algos obsolètes.
Créer un certificat SSL auto-signé avec OpenSSL pour un environnement de test
Pour démarrer, beaucoup d’équipes ont le même scénario que la société « SensorX », qui veut sécuriser un tableau de bord interne connecté à ses capteurs. Budget limité, délai court, réseau fermé : un certificat SSL auto-signé suffit.
À condition de garder en tête que ce type de certificat ne fournit aucune garantie d’identité, uniquement du chiffrement entre le client et le serveur.
La première brique est la clé privée. Sans elle, pas de certificat, pas de TLS. Sur une machine Linux ou sur Windows avec OpenSSL installé (voir par exemple le tutoriel installer OpenSSL sous Windows), la commande de base ressemble à ceci :
openssl genrsa -out server.key 2048
Cette commande génère une clé RSA 2048 bits, largement suffisante pour un usage courant. En production, beaucoup passent à 3072 bits, voire à ECDSA pour des raisons de performance, mais 2048 reste acceptable dans bien des cas. Le fichier server.key devient un actif sensible, à protéger comme un mot de passe maître. Sur le terrain, chaque fois qu’une clé privée traîne dans un dépôt Git ou sur un partage réseau ouvert, c’est une alerte immédiate.
Deuxième étape : produire en une seule commande la clé privée et un certificat SSL auto-signé valable un an, par exemple pour un serveur de test accessible via « dev.sensorx.local » :
openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -days 365 -nodes -subj « /CN=dev.sensorx.local »
Cette ligne fait plusieurs choses. Elle crée une nouvelle clé, produit un certificat au format X.509, le signe avec cette même clé (c’est le sens de « auto-signé ») et définit un Common Name (CN) qui devra correspondre au nom utilisé par les clients pour joindre le serveur. Sans SAN, les navigateurs modernes s’appuient principalement sur cette extension alternative, ce qui conduit déjà à un premier compromis : pour un test rapide, certains se contentent du CN, mais dès qu’on vise une compatibilité large, SAN devient incontournable.
Dans les ateliers IoT, ce certificat SSL auto-signé sert souvent à sécuriser un panel d’administration Nginx ou Apache sur un réseau d’usine. Les opérateurs doivent simplement accepter une exception de sécurité dans leur navigateur, une seule fois. C’est acceptable pour un intranet maîtrisé, beaucoup moins pour des clients externes. Dès que la cible sort du périmètre interne, un certificat signé par une autorité de confiance s’impose.
Du point de vue de la configuration serveur, un certificat auto-signé s’emploie de la même façon qu’un certificat émis par une autorité. Sur Nginx par exemple, dans un bloc vhost adapté (voir l’article sur les hôtes virtuels Nginx), la directive « ssl_certificate » pointe vers server.crt et « ssl_certificate_key » vers server.key. C’est souvent à cette étape que les erreurs de chemin ou de permissions bloquent le démarrage du service, d’où l’intérêt d’une petite commande « nginx -t » ou équivalent avant de relancer.
Pour un environnement de test correctement isolé, un certificat auto-signé bien généré fait le travail. Le piège, c’est la tentation de le réutiliser, tel quel, sur des serveurs exposés à Internet. Du coup, la frontière entre bac à sable et production devient floue, et la dette de sécurité s’accumule en silence.
Générer une CSR (Certificate Signing Request) avec OpenSSL pour un certificat signé
Dès que SensorX veut exposer son portail de données à un client externe via un nom public du type « portal.sensorx.fr », la question de la confiance côté navigateur arrive immédiatement. Un certificat SSL auto-signé déclenche une alerte, ce qui envoie un très mauvais signal au client. La réponse passe par une demande de signature, ou CSR, envoyée à une autorité de certification (CA).
La mécanique commence encore par une clé privée, souvent générée séparément pour la production, afin de ne pas réutiliser celle des environnements de test. Un exemple classique :
openssl genrsa -out portal_sensorx.key 3072
Cette clé restera sur le serveur ou dans un coffre-fort numérique, mais ne doit jamais quitter le contrôle de l’entreprise. La CSR, elle, peut circuler vers le fournisseur de certificat. La commande type pour générer la CSR combine la clé et un jeu de champs d’identité :
openssl req -new -key portal_sensorx.key -out portal_sensorx.csr -subj « /C=FR/ST=Hauts-de-France/L=Lille/O=SensorX SAS/CN=portal.sensorx.fr »
On retrouve ici quelques champs essentiels : pays (C), état ou région (ST), ville (L), organisation (O) et surtout le Common Name (CN). Pour un certificat de type « single-domain », le CN correspond au FQDN principal du serveur. Les CA vérifient ces données selon des procédures plus ou moins strictes selon le niveau de validation (DV, OV, EV). Pour la plupart des PME industrielles, un DV (Domain Validation) suffit largement.
L’intérêt de passer par une CSR plutôt que d’utiliser un certificat SSL auto-signé tient à cette chaîne de confiance : le navigateur du client connaît l’autorité de certification et peut vérifier la signature du certificat. Concrètement, l’utilisateur n’a plus de message d’alerte, et des services annexes comme HTTP/2 ou TLS 1.3 sont souvent plus simples à déployer proprement avec un certificat reconnu. Les guides sur la sécurisation TLS 1.3 avec Nginx et HTTPS illustrent bien ces gains.
Une fois la CSR générée, elle est fournie au prestataire (Let’s Encrypt, fournisseur commercial, PKI interne d’un grand groupe). Celui-ci renvoie un certificat signé et parfois une chaîne intermédiaire. Il reste alors à assembler les fichiers selon les attentes du serveur web ou du reverse proxy. Un paquet Debian ou une image Docker Nginx bien préparée facilite cette étape, mais l’habitude reste de vérifier à la main les chemins de fichiers au moins une fois.
Un point régulièrement négligé concerne la réutilisation de clés privées. Par facilité, certains conservent la même clé sur plusieurs serveurs ou certificats. C’est une mauvaise idée. Si un serveur est compromis, toute l’infrastructure qui partage cette clé se retrouve potentiellement exposée. Mieux vaut générer une clé par certificat significatif, quitte à documenter cette règle dans une petite checklist interne.
Dans les projets IoT, la CSR ne sert pas seulement à des serveurs web. Des équipements peuvent eux aussi embarquer des certificats signés pour l’authentification mutuelle TLS. Les CSR sont alors générées en amont, dans une chaîne de production ou un outil de provisioning, puis signées par une PKI interne. Le principe reste identique, même si le volume et l’automatisation changent d’échelle.
Une CSR proprement conçue est donc une pièce d’identité contrôlée. C’est elle qui alimente la chaîne de confiance, à condition de la lier à une clé privée bien gardée et à un processus de renouvellement documenté. Sans cette discipline, certaines infrastructures retombent très vite dans la logique du certificat SSL auto-signé bricolé « temporairement ».
Pour ceux qui découvrent la ligne de commande, regarder ce type de démonstration vidéo une fois, puis rejouer les commandes sur un environnement Linux minimal, aide vraiment à ancrer les réflexes.
Configurer correctement SAN (Subject Alternative Name) dans vos certificats OpenSSL
Les premières générations de certificats TLS s’appuyaient surtout sur le Common Name. Les navigateurs modernes, eux, scrutent désormais le champ SAN pour déterminer si le certificat SSL correspond bien au nom demandé. Un CN correct sans SAN adapté peut donc produire un avertissement, ce qui entretient une impression de « bug incompréhensible » pour les équipes moins familières du sujet.
Reprenons SensorX. Le portail doit répondre à « portal.sensorx.fr », mais aussi « api.sensorx.fr » et, pour des raisons historiques, « www.sensorx.fr ». L’idée de multiplier les certificats sur le même serveur ne fait pas rêver l’équipe. Une extension SAN bien utilisée permet de couvrir ces trois noms dans un même certificat. Avec OpenSSL, la méthode propre passe par un fichier de configuration dédié.
Un exemple minimaliste de fichier « san.cnf » pourrait contenir :
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
[ v3_req ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = portal.sensorx.fr
DNS.2 = api.sensorx.fr
DNS.3 = www.sensorx.fr
On appelle ensuite OpenSSL avec cette configuration pour générer une CSR incluant SAN :
openssl req -new -key portal_sensorx.key -out portal_sensorx.csr -subj « /CN=portal.sensorx.fr » -config san.cnf
La CSR contient alors l’extension SAN indiquant explicitement les noms alternatifs. La CA reprend ces informations pour émettre le certificat final, que le navigateur du client saura interpréter. Sur le terrain, beaucoup de problèmes disparaissent dès qu’un tel fichier de configuration devient standard dans l’équipe. Cela évite les erreurs manuelles de saisie, surtout quand le nombre de noms augmente.
Les cas plus avancés incluent aussi des adresses IP dans SAN, souvent pour des API internes ou des équipements IoT accessibles directement. On trouve alors des lignes de type « IP.1 = 192.168.10.5 ». Attention toutefois : l’usage d’IP publiques dans SAN doit être réfléchi, car un changement d’adresse rend le certificat obsolète. Dans les environnements industriels, mieux vaut souvent travailler avec des noms de domaine internes, gérés par un DNS local.
La même logique s’applique quand on veut sécuriser un front Nginx agissant comme répartiteur de charge. Un certificat SAN peut couvrir « app1 », « app2 » et « api », tous pointant vers le même reverse proxy, lui-même distribuant le trafic vers un load balancer Nginx ou un cluster applicatif. Les clients n’ont pas besoin de connaître la topologie interne : ils voient un certificat cohérent avec le nom qu’ils appellent.
Pour clarifier les différents scénarios, un petit tableau aide souvent les équipes à choisir la bonne stratégie de SAN :
| Cas d’usage | Type de certificat | Configuration SAN recommandée | Remarque opérationnelle |
|---|---|---|---|
| Un seul domaine public | Single-domain | DNS.1 = domaine unique | SAN simple, gestion aisée |
| Plusieurs sous-domaines ciblés | Multi-domain | DNS.1, DNS.2, DNS.3… | Idéal pour portail + API + admin |
| Nombre élevé de sous-domaines | Wildcard (*.domaine) | Souvent sans liste DNS détaillée | Souple, mais plus sensible en cas de fuite de clé privée |
| IP internes pour banc de test | Certificat interne | DNS.x + IP.x | À réserver à l’intranet ou à une PKI privée |
Un point souvent sous-estimé concerne l’impact de SAN sur la durée de vie des certificats. Plus un même certificat couvre de noms, plus sa rotation devient délicate. Les équipes se retrouvent parfois à repasser en urgence un samedi parce qu’un renouvellement a été oublié. Documenter explicitement qui porte la responsabilité des SAN et du renouvellement limite ces épisodes assez désagréables.
En résumé, SAN n’est pas un détail exotique. C’est un élément clé pour que le certificat SSL colle au réel. Bien utilisé, il simplifie la vie des développeurs et des admins, tout en réduisant la friction côté utilisateur.
Une démonstration vidéo de configuration SAN, même courte, aide souvent à arrêter de subir les messages d’erreur obscurs des navigateurs et des librairies HTTP.
Clé privée, certificat et serveur : structurer le déploiement et les bonnes pratiques
La génération d’un certificat SSL avec OpenSSL n’est que la première moitié du travail. L’autre moitié se joue lors de l’intégration sur le serveur, du rangement des fichiers et des droits, et plus globalement de la politique de sécurité. Là-dessus, les petites structures commettent souvent les mêmes erreurs que les grands groupes, simplement à plus petite échelle.
Reprenons encore SensorX. Une fois le certificat signé en main (par exemple « portal_sensorx.crt ») et la chaîne intermédiaire fournie par la CA, l’équipe les dépose sur un Nginx frontal. Une structure de répertoires simple mais réfléchie, du type « /etc/ssl/private » pour les clés et « /etc/ssl/certs » pour les certificats, évite beaucoup de confusions. Les permissions doivent être strictes : lecture seule pour l’utilisateur du serveur web sur les clés privées, et accès plus large possible sur les certificats publics.
Du côté de la configuration, un bloc server Nginx minimal pourrait ressembler à ceci :
server {
listen 443 ssl;
server_name portal.sensorx.fr;
ssl_certificate /etc/ssl/certs/portal_sensorx_fullchain.crt;
ssl_certificate_key /etc/ssl/private/portal_sensorx.key;
}
La variable « fullchain » désigne souvent le certificat + la chaîne intermédiaire concaténés. Une vérification de configuration (« nginx -t » ou via un outil comme celui décrit dans ce guide de test de configuration Nginx) vaut largement le détour avant de redémarrer en pleine journée. Chez certains clients, des incidents de quelques minutes sur un frontal HTTPS suffisent à bloquer des opérateurs logistiques, voire des lignes de production.
Pour les équipes IoT, le sujet ne s’arrête pas aux serveurs HTTP. Les certificats TLS interviennent dans MQTT, AMQP, gRPC et toute une panoplie de protocoles. Les passerelles ou brokers se retrouvent parfois configurés avec des certificats expirés, car moins visibles que les portails web. Un inventaire simple, mis à jour, des certificats déployés et de leurs dates d’expiration permet déjà de réduire ce risque. Certains scripts Ansible ou bash se contentent de scanner les fichiers « *.crt » et d’afficher les dates, ce qui suffit pour installer un rappel dans le calendrier.
La question de la sécurité globale dépasse évidemment le seul certificat SSL. Dans des contextes sensibles, comme des sites classés Seveso, la chaîne TLS fait partie d’un tout avec la segmentation réseau, la journalisation et les contrôles d’accès. Les réflexions autour des risques sécurité IoT et des données critiques rappellent que le chiffrement sans gouvernance reste un trompe-l’œil.
Du coup, pour structurer un déploiement propre, beaucoup d’équipes se dotent d’une petite liste de contrôle centrée sur trois axes : génération, déploiement, rotation. Un exemple de liste utile dans le quotidien :
- Génération : clé privée séparée par environnement, algorithme actuel (RSA 2048+ ou ECDSA), configuration SAN documentée.
- Déploiement : répertoires dédiés, permissions restreintes, test de configuration serveur, validation via un client (curl, navigateur, script).
- Rotation : inventaire des certificats, dates d’expiration dans un calendrier partagé, procédure de renouvellement écrite.
Au fil des projets, un constat revient souvent : l’outil OpenSSL n’est pas le goulot d’étranglement. Ce qui bloque, ce sont les habitudes approximatives autour des fichiers et de leur cycle de vie. Le jour où ces points sont clarifiés, la génération de certificat, qu’il soit auto-signé ou signé via une CSR, devient presque un réflexe routinier, ce qui est plutôt bon signe.
Éviter les erreurs fréquentes avec OpenSSL : du poste développeur au cluster de production
Les commandes OpenSSL paraissent simples, mais la moindre faute de frappe ou une option oubliée peut créer des problèmes discrets, qui ne se révèlent que plus tard. Certains bugs ne se manifestent que sur un navigateur ou un client IoT spécifique. L’expérience montre que les mêmes bourdes reviennent souvent, quels que soient la taille de l’entreprise et le nombre de serveurs.
Un premier classique consiste à générer un certificat pour « sensorx.local » et à accéder ensuite au serveur via son adresse IP ou un alias DNS différent. Côté navigateur, cela produit une alerte de nom non valide. Côté développeur, la tentation est grande de « cliquer sur avancer quand même ». En environnement industriel ou B2B, normaliser la manière dont les services sont accédés (nom canonique unique) limite ce type de confusion. À ce stade, SAN joue son rôle, à condition d’avoir été configuré dès le départ.
Autre source de problèmes : les dates. Une horloge système décalée de quelques heures ou jours peut rendre un certificat « non encore valide » ou déjà expiré. Dans un cluster Kubernetes ou sur des systèmes embarqués, un mauvais NTP ou une RTC non configurée provoque des pannes TLS très difficiles à comprendre pour les non-spécialistes. Un simple contrôle de la date système fait gagner un temps fou avant de remettre en question toute la chaîne TLS.
Les scripts de génération automatisés peuvent eux aussi être à double tranchant. SensorX, par exemple, a mis en place un script bash pour générer des certificats auto-signés sur des bancs de test. La première version du script réutilisait la même clé privée partout, par commodité. Avec un peu de recul, l’équipe a fini par distinguer les cas où l’uniformisation est acceptable (banc de tests isolé) et ceux où chaque instance doit avoir sa propre identité. Tout ce qui touche à la production, surtout pour des objets connectés sur le terrain, relève de cette deuxième catégorie.
Enfin, certains mélangent certificat SSL et chaînes intermédiaires. Le serveur renvoie alors un certificat incomplet. Sur certains navigateurs récents, cela fonctionne grâce à des mécanismes de récupération, mais sur des clients plus anciens, la connexion échoue. La bonne pratique consiste à conserver des fichiers explicites : « site.crt » pour le certificat, « chain.crt » pour la chaîne intermédiaire et « fullchain.crt » pour les deux assemblés, en les mentionnant clairement dans la configuration du serveur.
Ces erreurs récurrentes montrent que la maîtrise d’OpenSSL ne se joue pas seulement dans la syntaxe des commandes. Elle se construit aussi via des habitudes solides de diagnostic : vérifier le nom, la date, la chaîne de certificats, la clé privée, le SAN. Sur ce point, les commandes OpenSSL de base s’apprennent vite, puis deviennent des réflexes comparables aux commandes Linux de base pour naviguer dans un système.
Autrement dit, gérer correctement une clé privée, une CSR et un certificat SSL, avec ou sans SAN, relève autant de la culture d’équipe que de la technique brute. Les projets qui investissent quelques heures dans cette culture au début économisent souvent des journées entières de debug à la suite.
Quelle différence entre un certificat SSL auto-signé et un certificat signé par une autorité ?
Un certificat SSL auto-signé est généré et signé avec sa propre clé privée. Il permet de chiffrer la connexion, mais ne fournit aucune garantie d’identité, d’où les alertes des navigateurs. Un certificat signé par une autorité de certification repose sur une chaîne de confiance reconnue par les systèmes et navigateurs, ce qui supprime ces alertes et convient aux services exposés publiquement.
Pourquoi utiliser une CSR (Certificate Signing Request) avec OpenSSL ?
La CSR contient la clé publique et les informations d’identité (domaine, organisation, etc.) nécessaires à l’émission d’un certificat signé. Elle est transmise à l’autorité de certification, alors que la clé privée reste sous votre contrôle. C’est le passage obligé pour obtenir un certificat reconnu par les navigateurs et les systèmes clients.
À quoi sert le champ SAN dans un certificat SSL ?
Le champ SAN (Subject Alternative Name) liste les noms de domaine et adresses IP que le certificat couvre. Les navigateurs modernes s’appuient surtout sur SAN, plus que sur le Common Name. Sans SAN correctement configuré, un certificat peut déclencher des avertissements même si le CN semble correct.
Faut-il protéger la clé privée par un mot de passe ?
Pour une clé privée stockée sur un serveur automatisé (web, reverse proxy), un mot de passe complique parfois le redémarrage non supervisé. Beaucoup d’équipes préfèrent une clé non chiffrée mais fortement protégée par les droits d’accès système. Pour des usages plus sensibles (PKI racine, clé hors ligne), le chiffrement de la clé par mot de passe reste recommandé.
Comment vérifier le contenu d’un certificat généré avec OpenSSL ?
La commande openssl x509 -in certificat.crt -text -noout permet d’inspecter un certificat. On peut y vérifier les dates de validité, le CN, les SAN, l’algorithme utilisé et la chaîne de confiance. C’est un réflexe utile avant tout déploiement en production.