SSD Nodes Learn Hosting plans →
Guides Matt ConnorPar Matt Connor

Certificat autosigné Ubuntu 24.04 avec Chrome

Créez un certificat TLS autosigné accepté par Chrome sur Ubuntu 24.04 : SAN, commande OpenSSL, nginx ou Apache, puis confiance client sans curl -k.

Ce que vous allez construire

Un certificat TLS autosigné que les navigateurs et clients modernes acceptent réellement, avec un champ subjectAltName correct, des permissions raisonnables pour la clé, et une intégration à nginx ou Apache. Vous verrez aussi l’étape que presque tous les guides omettent : faire correctement confiance à ce certificat sur vos clients, au lieu de contourner les avertissements et d’intégrer curl -k en dur dans les scripts pour toujours. À la fin, vous disposerez d’une autorité de certification privée créée en cinq commandes, utile lorsqu’un service interne devient six.

Commencez par le choix de la méthode, car un certificat autosigné est bien moins souvent le bon outil qu’on ne l’utilise. Si le service est accessible depuis Internet public avec un vrai nom DNS, arrêtez-vous ici et obtenez plutôt un certificat Let's Encrypt gratuit avec certbot sur nginx ou l’équivalent pour Apache. Il ne coûte rien, se renouvelle automatiquement et les navigateurs et systèmes d’exploitation courants lui font déjà confiance. Un certificat autosigné sur un site public habitue vos utilisateurs à contourner les avertissements de sécurité, ce qui est une moins bonne pratique que le HTTP en clair.

Un certificat autosigné est adapté lorsqu’Internet public n’est pas concerné : un panneau d’administration lié à une adresse de tunnel WireGuard sur votre VPS, un serveur de staging sur un réseau privé, le trafic entre services backend, un équipement de home lab ou le remplacement du certificat par défaut que Webmin génère pour lui-même sur le port 10000. Let's Encrypt ne peut de toute façon pas émettre de certificat pour 10.8.0.1 ou git.internal.lan ; aucune autorité de certification publique n’inscrira une adresse IP privée ou un TLD inventé dans un certificat. Pour ces noms, c’est vous qui êtes l’autorité de certification.

Tout ce qui suit s’exécute sur une machine Ubuntu 24.04 fraîchement installée, qui fournit OpenSSL 3.0.x (openssl version à confirmer). Rien ne nécessite un accès à Internet ; tout fonctionne dans un environnement isolé du réseau.

Pourquoi l’ancien one-liner produit des certificats rejetés par Chrome

La commande fournie par tous les tutoriels antérieurs à 2017 ressemble à ceci :

# Do not run this: shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

Elle pose une série de questions interactives, place votre nom d’hôte dans le champ Common Name et produit un certificat sans extension subjectAltName. Ce certificat est inutilisable immédiatement. Chrome a cessé de lire le Common Name dans la version 58, en avril 2017. La RFC 2818 avait déjà déprécié la vérification du CN en 2000. Firefox et Safari se comportent de la même manière. curl et le module ssl de Python utilisent encore le Common Name comme solution de repli lorsqu’un certificat ne contient aucune extension SAN. C’est pourquoi un certificat sans SAN peut réussir un test rapide avec curl, tout en échouant dans tous les navigateurs. Pour un navigateur, un certificat identifie son serveur par l’intermédiaire de l’extension SAN, ou ne l’identifie pas du tout. Le navigateur vous l’indique exactement avec ces mots :

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

Aucune modification du trust store ne corrige cette erreur, car le certificat ne contient réellement aucun nom. Si vous voyez actuellement NET::ERR_CERT_COMMON_NAME_INVALID, votre certificat ne contient aucun SAN, ou contient un SAN incorrect, et vous devez en générer un nouveau. Heureusement, la correction tient en une seule commande.

Créer un certificat accepté par les navigateurs : une seule commande

OpenSSL a ajouté l’option -addext dans la version 1.1.1. Vous n’avez donc plus besoin des manipulations complexes avec un fichier de configuration utilisées par les anciens guides pour injecter un SAN. Sous Ubuntu 24.04 :

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

Rôle de chaque option :

  • -x509 génère directement un certificat auto-signé au lieu d’une demande de signature.
  • -newkey rsa:4096 génère une nouvelle clé dans la même commande. RSA 4096 reste compatible avec les anciens clients. Si tous les clients sont modernes, -newkey ec -pkeyopt ec_paramgen_curve:P-256 produit une clé plus petite et plus rapide.
  • -noenc est la syntaxe OpenSSL 3.x correspondant à l’ancienne option -nodes : la clé n’a pas de phrase secrète. Les deux syntaxes fonctionnent. Avec une clé protégée par une phrase secrète, nginx reste bloqué en attendant une saisie à chaque démarrage. Pour une clé de serveur, utilisez donc cette option.
  • -days 730 définit une validité de deux ans. Ce nombre est expliqué plus loin dans la section consacrée à l’expiration.
  • -subj fournit les réponses aux questions interactives directement dans la commande. Le CN est désormais essentiellement décoratif, mais définissez-le malgré tout sur le nom principal ; certains outils l’affichent.
  • -addext "subjectAltName=..." est l’option essentielle. Indiquez chaque nom et chaque adresse IP que les clients utiliseront : les entrées DNS: pour les noms d’hôte, avec des wildcards comme DNS:*.internal.lan, et les entrées IP: pour les adresses IP. Si quelqu’un accède à https://10.8.0.1, l’entrée IP:10.8.0.1 doit être présente. Un SAN contenant uniquement un nom DNS provoquerait de nouveau l’erreur NET::ERR_CERT_COMMON_NAME_INVALID.

Vérifiez que le SAN a bien été intégré avant de configurer quoi que ce soit :

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

Sortie correcte :

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

Si la commande affiche plutôt No extensions in certificate, le certificat ne contient pas de SAN et les navigateurs le rejetteront. Générez-en un nouveau au lieu de poursuivre.

Sécurisez la clé

Une clé privée lisible par tous les utilisateurs du serveur n’est pas une clé privée. Sur une installation Ubuntu 24.04 standard, /etc/ssl/private est déjà 700 root:root. Seul root peut donc même la lister. Elle ne devient 710 root:ssl-cert que si un élément installe le paquet ssl-cert (apache2 le recommande). Dans tous les cas, définissez explicitement les permissions du fichier :

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

Nginx et Apache lisent tous deux les certificats avec les privilèges root avant d’abandonner ces privilèges. Le mode root:root 600 leur convient donc. Si la clé est destinée à un service qui s’exécute avec son propre utilisateur et charge lui-même la clé, par exemple une application Node, Gitea ou un daemon Python, attribuez-la plutôt à l’utilisateur de ce service avec chown, toujours en mode 600. Ne faites jamais ceci : mode 644, copie dans un dépôt git ou copie dans /tmp.

Configurer nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
sudo nginx -t && sudo systemctl reload nginx

nginx -t doit afficher syntax is ok et test is successful avant que le rechargement n’effectue quoi que ce soit. S’il affiche plutôt SSL_CTX_use_PrivateKey_file() failed ... key values mismatch, le certificat et la clé proviennent de deux générations différentes ; consultez la section consacrée aux modes d’échec.

Configurez Apache

sudo a2enmod ssl proxy proxy_http

ssl ne suffit pas ici : le vhost ci-dessous utilise ProxyPass, et sans mod_proxy ni mod_proxy_http, le test de configuration échoue avec Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. Enregistrez le vhost dans /etc/apache2/sites-available/git-internal.conf :

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>
sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest doit répondre à Syntax OK. Testez maintenant depuis une machine cliente :

curl -v https://git.internal.lan/

Vous obtiendrez une erreur :

curl: (60) SSL certificate problem: self-signed certificate

Ce n’est pas un bug. C’est TLS qui fonctionne : curl ne connaît pas votre certificat et refuse de communiquer avec un serveur qu’il ne peut pas authentifier. La section suivante apporte la véritable correction, et ce n’est pas la méthode utilisée par une grande partie d’Internet à cet instant précis.

Faire confiance au certificat côté client et éviter les mauvaises pratiques

Commençons par les mauvaises corrections, en les appelant par leur nom. curl -k (ou --insecure) intégré dans un script, verify=False dans Python requests ou NODE_TLS_REJECT_UNAUTHORIZED=0 dans Node ne rendent pas votre certificat fiable. Ils désactivent la vérification du certificat. Le client communique alors volontiers avec n’importe quel serveur présentant n’importe quel certificat, y compris un certificat placé sur le chemin par un attaquant. Vous conservez le coût de TLS, mais vous perdez l’authentification qui justifie son utilisation. Pire encore, ces options se propagent : elles sont copiées dans une tâche cron, puis dans un script de déploiement et enfin dans le code de production, jusqu’à ce que plus personne ne sache quelles connexions étaient censées être temporaires. Si un verify=False subsiste après la session de débogage qui l’a introduit, la conception est incorrecte.

La bonne correction consiste à indiquer à l’OS de chaque client que ce certificat est une autorité de certification racine approuvée. Sur les clients Ubuntu et Debian :

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

La ligne importante de la sortie (un bloc Running hooks in /etc/ca-certificates/update.d... la suit) est la suivante :

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Deux pièges se cachent dans ces lignes. Le fichier doit se terminer par .crt. Une extension .pem est ignorée silencieusement et vous obtenez 0 added sans message d’erreur. Le contenu doit aussi être au format PEM : le fichier commence par -----BEGIN CERTIFICATE-----. Convertissez d’abord un fichier binaire DER avec openssl x509 -inform der -in file.der -out file.crt. Ajouter directement le certificat auto-signé comme racine fonctionne, car un certificat auto-signé est sa propre racine.

Après cela, curl, wget, git, apt et tout autre client qui utilise OpenSSL avec le bundle système font confiance au serveur sans aucune option. Certains clients utilisent leur propre magasin de certificats et nécessitent une configuration particulière :

  • Chrome/Chromium sous Linux lit une base NSS, et non le magasin système : sudo apt install libnss3-tools, puis certutil -d sql:$HOME/.local/share/pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt pour chaque utilisateur. Ce chemin est celui utilisé par défaut par Chrome depuis la version 146. Si l’utilisateur possède encore un ancien ~/.pki/nssdb provenant d’une installation précédente, Chrome continue de lire celui-ci. Il faut donc définir -d sur sql:$HOME/.pki/nssdb sur ces machines.
  • Firefox possède son propre magasin : Paramètres → Vie privée et sécurité → Certificats → Importer. Sous Windows et macOS, vous pouvez aussi définir security.enterprise_roots.enabled sur true dans about:config afin qu’il lise le magasin de l’OS. Mozilla documente cette préférence pour Windows et macOS, mais pas pour Linux. Sur Ubuntu, utilisez donc l’importation.
  • Python requests fournit son propre bundle d’autorités de certification (certifi) et ignore le magasin système : passez verify="/usr/local/share/ca-certificates/git.internal.crt" ou exportez REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
  • Node.js utilise par défaut ses propres racines intégrées : exportez NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt, ou demandez-lui de lire le magasin système que vous venez de mettre à jour avec l’option --use-system-ca (Node 23.9 et versions ultérieures sous Linux) ou NODE_USE_SYSTEM_CA=1 (Node 24.6 et versions 22.19 et ultérieures).

Sur les clients Windows, double-cliquez sur .crt et installez-le dans Autorités de certification racines de confiance. Sur macOS, ajoutez-le au trousseau Système dans Trousseaux d’accès et définissez-le sur Toujours approuver.

Une seule racine pour plusieurs services : une petite AC privée

La gestion de la confiance certificat par certificat atteint immédiatement ses limites : six services multipliés par quatre machines clientes représentent vingt-quatre installations de certificats de confiance, et chaque nouveau service en ajoute d’autres. La solution consiste à utiliser une AC privée : les clients font confiance à une seule racine, qui signe le certificat de chaque service.

L’option la plus simple est mkcert, disponible dans les dépôts Ubuntu 24.04. Elle gère les magasins NSS (Firefox, ainsi que Chrome avec une réserve indiquée ci-dessous), contrairement à update-ca-certificates :

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install crée une racine et l’enregistre dans le magasin système, dans les magasins NSS des navigateurs qu’il trouve et dans le magasin Java lorsque JAVA_HOME est défini. Node ne lit pas le magasin système sans instruction explicite. Lancez donc les applications Node avec --use-system-ca (ou NODE_USE_SYSTEM_CA=1), comme ci-dessus, ou exportez NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem". La troisième commande génère git.internal.lan+2.pem et git.internal.lan+2-key.pem, prêts à être ajoutés aux extraits de configuration nginx ou Apache ci-dessus. Sa conception part du principe qu’il s’agit d’une machine de développement. La clé racine reste sur la machine qui a exécuté -install. L’outil convient donc parfaitement à un portable de développement, mais pas à un parc de serveurs.

La réserve, en octobre 2026, est la suivante : mkcert recherche la base NSS de Chrome uniquement à l’ancien emplacement ~/.pki/nssdb, et non à ~/.local/share/pki/nssdb, que Chrome utilise par défaut depuis la version 146. Sur une machine dépourvue de l’ancienne base, ajoutez vous-même la racine pour Chrome avec la commande certutil de la section précédente, en utilisant -i "$(mkcert -CAROOT)/rootCA.pem".

Pour les serveurs, OpenSSL suffit pour créer toute l’AC en cinq commandes :

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

Le piège se trouve dans la dernière commande : par défaut, openssl x509 -req supprime toutes les extensions de la CSR, notamment le SAN que vous avez ajouté avec soin. -copy_extensions copy (une option d’OpenSSL 3.x, donc compatible avec 24.04) les conserve. Si vous l’omettez, le certificat signé n’a aucun SAN et Chrome vous affiche de nouveau NET::ERR_CERT_COMMON_NAME_INVALID. Vérifiez le résultat avec le même contrôle openssl x509 -noout -ext subjectAltName qu’auparavant.

Distribuez lab-ca.crt aux clients en suivant les étapes précédentes d’ajout au magasin de confiance, une seule fois par machine. Protégez lab-ca.key comme une clé extrêmement sensible : utilisez le mode 600 et conservez idéalement cette clé sur une machine qui ne fait pas partie des serveurs pour lesquels elle signe des certificats. Toute personne qui la détient peut en effet créer un certificat pour n’importe quel nom accepté par vos clients.

Expiration et rotation

La durée de validité des certificats d’une AC publique diminue rapidement. Le CA/Browser Forum a limité à 200 jours la durée des certificats nouvellement émis et approuvés publiquement en mars 2026, contre 398 auparavant. Cette durée passera à 100 jours en 2027, puis à 47 jours en mars 2029. Ces règles s’appliquent toutefois aux AC approuvées publiquement. Votre AC privée n’est pas concernée, et les navigateurs ne les imposent pas aux certificats racine installés manuellement. Une contrainte concrète s’applique néanmoins : les plateformes Apple refusent tout certificat de serveur TLS valide plus de 825 jours, quel que soit son émetteur. Si des iPhone ou des Mac doivent se connecter, limitez donc les certificats leaf à deux ans. -days 730 respecte cette limite partout. Une racine valable dix ans avec des certificats leaf valables deux ans constitue une configuration interne confortable.

Les certificats à longue durée de validité échouent d’une seule manière : silencieusement, tous en même temps, à une date que personne ne se souvient avoir choisie. Vérifiez ce dont vous disposez :

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

Inscrivez le renouvellement dans un véritable calendrier ou laissez cron vous rappeler l’échéance 30 jours à l’avance. openssl x509 -checkend 2592000 -in cert.crt renvoie un code différent de zéro lorsque l’expiration se trouve à moins de ce nombre de secondes. Si vous utilisez déjà Uptime Kuma pour surveiller l’état, ses monitors HTTPS signalent gratuitement l’approche de l’expiration des certificats.

La rotation avec une AC privée est agréablement simple : réexécutez les commandes de création et de signature du CSR, remplacez les fichiers, puis rechargez le serveur web. La racine n’a pas changé, donc aucun client ne remarque quoi que ce soit.

Modes d’échec et messages affichés

NET::ERR_CERT_AUTHORITY_INVALID, c’est l’état attendu avant l’installation de l’ancre de confiance, et non un défaut du certificat. Si le problème persiste après l’installation du certificat racine : sous Linux, Chrome utilise NSS plutôt que le magasin système (voir l’étape certutil), et depuis Chrome 146, cette base se trouve dans ~/.local/share/pki/nssdb sauf si un ancien fichier ~/.pki/nssdb existe ; un certificat racine ajouté dans l’autre chemin n’est donc jamais détecté. Il est aussi possible que le fichier copié ne se termine pas par .crt et que update-ca-certificates affiche 0 added. Enfin, le serveur présente peut-être un certificat différent de celui auquel vous avez accordé votre confiance. Comparez les empreintes avec openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID, le certificat ne contient aucun SAN, ou le SAN ne couvre pas le nom affiché dans la barre d’adresse. Le cas classique est le suivant : le SAN contient DNS:git.internal.lan, mais l’utilisateur ouvre https://10.8.0.1. Les modifications du magasin de certificats ne peuvent pas corriger ce problème. Réémettez le certificat avec l’entrée manquante.

curl: (60) SSL certificate problem: self-signed certificate, curl n’accorde pas sa confiance au certificat. La variante self-signed certificate in certificate chain signifie la même chose pour un certificat signé par votre autorité de certification privée. Correction ponctuelle : curl --cacert lab-ca.crt https://.... Correction permanente : le magasin de certificats. Pas -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (ou Expecting: CERTIFICATE REQUEST, ou no start line), problème de format PEM. Vous avez fourni à OpenSSL le mauvais type de fichier : une clé ou une CSR alors qu’il attendait un certificat, ou un fichier binaire DER alors qu’il attendait du PEM. head -1 filename indique ce que vous avez réellement fourni ; un certificat commence par -----BEGIN CERTIFICATE-----. Pour le format DER, convertissez le fichier avec openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch), le certificat et la clé ne correspondent pas, généralement parce que la commande de génération a été exécutée deux fois et que les fichiers ont été mélangés. Vérifiez avec openssl x509 -in git.internal.crt -noout -pubkey | sha256sum et openssl pkey -in git.internal.key -pubout | sha256sum ; des hachages identiques indiquent une paire correspondante. S’ils diffèrent, régénérez les deux fichiers ensemble.

FAQ

Pourquoi Chrome affiche-t-il toujours « Non sécurisé » après la création d’un certificat autosigné ?

Si l’erreur est NET::ERR_CERT_AUTHORITY_INVALID, le certificat est correct, mais Chrome n’a pas encore de raison de lui faire confiance. Installez-le, ou installez la racine de votre autorité de certification privée, dans le trust store du client. Sous Linux, Chrome utilise la base NSS via certutil, dans ~/.local/share/pki/nssdb depuis Chrome 146, ou dans un ancien ~/.pki/nssdb s’il existe, et non le store système. Si l’erreur est NET::ERR_CERT_COMMON_NAME_INVALID, le certificat ne contient pas de Subject Alternative Name correspondant à l’URL. Vous devez le réémettre avec -addext "subjectAltName=...".

Comment faire pour que curl approuve un certificat autosigné sans utiliser -k ?

Copiez le certificat au format PEM, avec l’extension .crt, dans /usr/local/share/ca-certificates/, puis exécutez sudo update-ca-certificates. La sortie doit indiquer 1 added. Ensuite, curl le vérifiera comme n’importe quel certificat public. Pour une requête ponctuelle sans modifier le système, curl --cacert /path/to/cert.crt effectue la vérification uniquement avec ce fichier. -k désactive entièrement la vérification et ne doit figurer dans aucun script.

Combien de temps un certificat autosigné peut-il rester valide ?

Techniquement, aussi longtemps que vous le souhaitez. Les limites du CA/Browser Forum, de 200 jours actuellement à 47 jours d’ici 2029, s’appliquent aux autorités de certification approuvées publiquement, et non à la confiance privée. En pratique, limitez les certificats des serveurs à 825 jours, car les appareils Apple refusent toute durée supérieure, quel que soit l’émetteur. Une racine privée valable dix ans, avec des certificats leaf valables deux ans (-days 730), constitue une valeur par défaut raisonnable. Planifiez toutefois le renouvellement, car un certificat interne expiré peut interrompre silencieusement tous les services à une date que personne ne se rappelle.

Dois-je utiliser un certificat autosigné ou Let's Encrypt ?

Si le service possède un nom DNS public et est accessible depuis Internet, utilisez toujours Let's Encrypt : cette autorité est gratuite, automatisée et déjà approuvée par la plupart des navigateurs et des systèmes d’exploitation. Consultez la liste de compatibilité de Let's Encrypt si de très anciens appareils doivent se connecter. Un certificat autosigné, ou une autorité de certification privée, sert aux cas où Let's Encrypt ne peut pas émettre de certificat : adresses IP privées, noms d’hôte internes comme .lan, réseaux isolés et services volontairement masqués derrière un VPN. La décision dépend de l’accessibilité et du nommage, pas du niveau de sécurité. La cryptographie est identique.

Pourquoi mon certificat est-il rejeté même après son ajout dans /usr/local/share/ca-certificates ?

Vérifiez trois points. Le fichier doit se terminer par .crt. Une extension .pem est ignorée silencieusement, et update-ca-certificates indique 0 added. Le contenu doit être du texte PEM commençant par -----BEGIN CERTIFICATE-----, et non un fichier binaire DER. Enfin, l’application doit réellement utiliser le store système. Chrome sous Linux, Firefox, Python requests, Node.js, sauf s’il est lancé avec --use-system-ca, et Java utilisent chacun leur propre trust store. Le certificat doit donc être ajouté séparément dans chacun d’eux.

#openssl#tls#self-signed#ubuntu#sécurité