ERR_SSL_KEY_USAGE_INCOMPATIBLE : 7 solutions en 2026

L’erreur ERR_SSL_KEY_USAGE_INCOMPATIBLE signifie que Chrome ou un autre navigateur basé sur Chromium refuse le certificat présenté par le serveur, car l’usage autorisé de sa clé publique ne correspond pas à l’opération cryptographique demandée pendant la connexion TLS.

Un cas courant concerne un certificat RSA qui possède Key Usage: Key Encipherment, mais pas Digital Signature, alors que la négociation moderne attend une signature. La correction durable consiste donc à réémettre le certificat avec les extensions adaptées, puis à l’installer sur le bon service et à vérifier la chaîne complète.

Si vous êtes simple visiteur, commencez par tester le site sur un autre appareil et un autre réseau. Si l’erreur apparaît partout, vous ne pouvez pas réparer le certificat : prévenez le propriétaire du site et n’essayez pas de contourner l’alerte. Si elle touche uniquement votre ordinateur, vérifiez la date, mettez Chrome et le système à jour, puis recherchez un antivirus, un proxy ou un équipement d’entreprise qui intercepte le HTTPS.

Si vous administrez le site, ne perdez pas de temps à vider le cache avant d’avoir inspecté le certificat réellement servi. Contrôlez Key Usage, Extended Key Usage, le nom DNS, les dates, la chaîne intermédiaire et le certificat associé au port 443. Une incompatibilité d’usage de clé est un défaut de configuration, pas un problème de cookies.

Table de matières

ERR_SSL_KEY_USAGE_INCOMPATIBLE : que signifie exactement ce code ?

HTTPS protège la connexion grâce à TLS. Au début de la session, le serveur présente un certificat X.509 qui associe un nom de domaine à une clé publique. Le navigateur vérifie notamment l’autorité émettrice, les dates de validité, le nom demandé et les extensions qui limitent l’usage de la clé.

Deux extensions sont souvent confondues. Key Usage décrit des opérations cryptographiques : digitalSignature, keyEncipherment, keyAgreement ou encore keyCertSign. Extended Key Usage décrit un objectif applicatif : par exemple serverAuth pour l’authentification d’un serveur Web. Lorsqu’elles sont présentes, ces extensions constituent des restrictions ; elles ne sont pas de simples étiquettes.

Un certificat RSA ancien peut avoir été créé uniquement avec keyEncipherment. Cette configuration convenait à d’anciennes suites TLS où RSA servait directement à transporter un secret. Les suites modernes ECDHE_RSA et TLS 1.3 utilisent, elles, la clé RSA du certificat pour signer des éléments de la négociation. Si digitalSignature est absent alors que Key Usage est déclaré, Chromium peut interrompre la connexion avec ERR_SSL_KEY_USAGE_INCOMPATIBLE.

Ce mécanisme évite qu’une clé soit utilisée dans un contexte que l’émetteur n’a pas autorisé et réduit le risque d’attaques entre protocoles. Désactiver le contrôle dans le navigateur n’est donc pas une réparation acceptable.

Diagnostic rapide : le problème vient-il du visiteur ou du serveur ?

Avant de modifier quoi que ce soit, effectuez quatre tests simples.

Ouvrez l’adresse sur un téléphone connecté au réseau mobile. Une erreur identique indique généralement un problème côté site.
Testez Chrome et un second navigateur à jour. Un échec limité à une famille de navigateurs peut révéler une règle de validation plus stricte, mais ne rend pas le certificat correct pour autant.
Essayez plusieurs pages HTTPS connues. Si de nombreux sites échouent sur un seul appareil, examinez l’antivirus, le proxy, le filtrage parental ou l’inspection TLS du réseau.
Demandez au serveur ce qu’il présente réellement, au lieu d’inspecter uniquement le fichier stocké sur le disque.

Sous Linux, macOS, WSL ou Git Bash avec OpenSSL installé :

openssl s_client -connect exemple.com:443 -servername exemple.com -showcerts </dev/null

Dans PowerShell, utilisez la commande sans redirection POSIX, puis interrompez-la avec Ctrl+C après l’affichage de la chaîne :

openssl s_client -connect exemple.com:443 -servername exemple.com -showcerts

Pour afficher les extensions du certificat de tête :

openssl s_client -connect exemple.com:443 -servername exemple.com </dev/null 2>/dev/null | openssl x509 -noout -text

Recherchez X509v3 Key Usage, X509v3 Extended Key Usage, Subject Alternative Name, Not Before, Not After et l’émetteur. Pour un certificat RSA de serveur utilisé avec des suites modernes, Digital Signature doit normalement apparaître lorsque l’extension Key Usage est présente ; l’EKU doit autoriser l’authentification serveur (TLS Web Server Authentication ou serverAuth).

L’option -servername est indispensable sur un hébergement qui utilise SNI. Sans elle, le serveur peut renvoyer le certificat d’un autre site et fausser tout le diagnostic.

Solution 1 : réémettre le certificat avec les bons usages de clé

C’est la solution prioritaire lorsque le certificat servi ne contient pas digitalSignature, ou lorsque son EKU n’autorise pas serverAuth. Un certificat X.509 signé ne peut pas être modifié après émission : changer une option locale ou renommer le fichier ne réécrit pas ses extensions.

Il faut créer une nouvelle paire de clés ou une nouvelle demande de signature, faire émettre un nouveau certificat, l’installer puis recharger le service.

Avec une autorité publique et un panneau d’hébergement, utilisez la fonction de renouvellement ou de réémission. Évitez de recopier une ancienne CSR si elle provient d’un modèle défectueux. Vérifiez que le produit demandé est bien un certificat TLS serveur, que tous les noms figurent dans le SAN et que la clé privée correspond.

Pour une PKI interne, corrigez le modèle de certificat plutôt que chaque serveur isolément. Le modèle doit produire un certificat d’entité finale (CA:FALSE), autoriser la signature numérique selon l’algorithme et inclure l’usage étendu d’authentification serveur. Les valeurs exactes dépendent de votre PKI et du logiciel TLS ; faites valider le profil par la personne responsable de l’autorité de certification.

Après émission, inspectez le nouveau fichier avant le déploiement :

openssl x509 -in nouveau-certificat.pem -noout -text

Contrôlez ensuite la correspondance entre certificat et clé privée. Pour RSA, comparez les empreintes dérivées du modulus :

openssl x509 -noout -modulus -in certificat.pem | openssl sha256

openssl rsa -noout -modulus -in cle-privee.pem | openssl sha256

Les deux sorties doivent être identiques. Ne transmettez jamais la clé privée à un service de test en ligne.

Solution 2 : créer correctement un certificat auto-signé sous Windows

Les erreurs sont fréquentes sur les applications internes, les consoles d’administration et les anciens certificats générés par défaut. Dans PowerShell lancé en administrateur, une base de commande pour un certificat de serveur RSA est :

New-SelfSignedCertificate -DnsName "intranet.exemple.local" -CertStoreLocation "Cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm SHA256 -KeyUsage DigitalSignature,KeyEncipherment -Type SSLServerAuthentication

Adaptez le nom DNS à celui réellement saisi dans le navigateur. Le certificat doit contenir ce nom dans le SAN ; un nom commun seul ne suffit plus dans les clients modernes. La commande crée un certificat pour un environnement contrôlé, mais elle ne le rend pas automatiquement fiable. Il faut distribuer sa racine ou le certificat auto-signé dans le magasin de confiance des appareils autorisés, selon la politique de l’organisation.

N’utilisez pas un certificat auto-signé pour un site public lorsque vous pouvez obtenir un certificat délivré par une autorité reconnue. N’exportez la clé privée que si le déploiement l’exige, avec un mot de passe robuste et un canal sécurisé.

Solution 3 : installer le bon certificat dans IIS

Sur IIS, un certificat valide dans le magasin Windows peut rester inutilisé si la liaison HTTPS pointe vers l’ancien. Ouvrez le Gestionnaire IIS, sélectionnez le site, puis Liaisons. Éditez la liaison https sur le port 443, choisissez le nouveau certificat et vérifiez le nom d’hôte ainsi que l’option SNI lorsque plusieurs sites partagent la même adresse IP.

Vous pouvez contrôler les liaisons HTTP.sys avec :

netsh http show sslcert

Comparez l’empreinte affichée à celle du certificat prévu. Redémarrez le site ou IIS pendant une fenêtre de maintenance si nécessaire, puis refaites un test externe avec SNI. Sur une ferme de serveurs, remplacez le certificat sur chaque nœud et sur tout répartiteur de charge qui termine TLS.

Si le serveur présente encore l’ancien certificat, recherchez une seconde terminaison HTTPS : reverse proxy, WAF, CDN, appliance de sécurité ou load balancer. Le certificat visible par l’utilisateur est celui du premier équipement qui termine TLS, pas nécessairement celui installé dans IIS.

Solution 4 : remplacer le certificat dans Nginx ou Apache

Avec Nginx, vérifiez les chemins de ssl_certificate et ssl_certificate_key dans le bloc server qui correspond exactement au nom demandé. Le fichier de certificat doit généralement contenir le certificat du site suivi des intermédiaires. Testez la configuration avant le rechargement :

sudo nginx -t

sudo systemctl reload nginx

Avec Apache, contrôlez SSLCertificateFile et SSLCertificateKeyFile dans le bon VirtualHost. Selon la version et la distribution, la chaîne peut être incluse dans le fichier du certificat. Puis lancez :

sudo apachectl configtest

sudo systemctl reload apache2

Sur les distributions où le service s’appelle httpd, adaptez la dernière commande. Un rechargement est préférable à un arrêt brutal, mais conservez une session d’administration ouverte et une copie de la configuration fonctionnelle.

Solution 5 : corriger la chaîne de certificats et la terminaison TLS

Une chaîne incomplète provoque plus souvent une erreur d’autorité ou de chaîne qu’une incompatibilité d’usage de clé. Elle doit néanmoins être vérifiée, car un serveur peut présenter le mauvais certificat de tête ou un intermédiaire inadapté après un renouvellement.

Installez le certificat d’entité finale associé au domaine, puis les certificats intermédiaires fournis par l’autorité. Ne servez pas la clé privée et n’ajoutez pas aveuglément un certificat racine au bundle. Vérifiez également que le CDN ou le proxy utilise le certificat destiné au client et que la liaison vers l’origine possède son propre certificat valide.

Cette distinction rejoint le fonctionnement expliqué dans notre guide SSL ou TLS : quelles différences ? : le navigateur valide une identité et négocie une session TLS, tandis que plusieurs équipements peuvent intervenir entre lui et le serveur applicatif.

Solution 6 : identifier un antivirus, un proxy ou une inspection HTTPS

Si l’erreur touche plusieurs sites uniquement sur un poste ou un réseau, un intermédiaire peut générer à la volée des certificats incompatibles. C’est fréquent avec certaines fonctions d’analyse HTTPS, des proxies d’entreprise, des pare-feu ou des outils de contrôle parental.

Mettez d’abord le produit à jour. Dans un environnement professionnel, transmettez le nom du site, l’heure, la version du navigateur et le certificat observé à l’équipe informatique. Elle devra corriger le profil de l’autorité interne ou mettre à jour l’équipement.

Désactiver durablement l’inspection sans décision de sécurité peut exposer l’organisation ; un arrêt très court peut servir de test uniquement si vous êtes autorisé à le faire.

Un attaquant sur le réseau peut lui aussi tenter d’intercepter la connexion. Si l’émetteur du certificat est inconnu, si plusieurs sites bancaires ou administratifs échouent, ou si le problème apparaît sur un Wi-Fi public, quittez le réseau. Notre guide pour se protéger d’une attaque man-in-the-middle détaille les signes à surveiller.

Solution 7 : mettre à jour le poste et éliminer les causes locales

Ces vérifications ne corrigent pas un mauvais certificat public, mais elles permettent d’écarter une anomalie locale :

activez la synchronisation automatique de la date, de l’heure et du fuseau horaire ;
mettez Chrome, Windows, macOS ou Linux à jour ;
redémarrez complètement le navigateur après la mise à jour ;
testez sans extension dans un profil temporaire ;
vérifiez les paramètres de proxy et les certificats racines ajoutés récemment ;
comparez avec un autre appareil sur le même réseau, puis sur un autre réseau.

Vider le cache et les cookies peut résoudre certains problèmes de session, mais pas une extension Key Usage incorrecte. De même, la commande de purge DNS n’altère pas le certificat. Ne la retenez que si le domaine vient de changer d’adresse et que les tests montrent que votre appareil contacte encore un ancien serveur.

Ce qu’il ne faut pas faire

Ne cherchez pas un bouton « continuer quand même » et ne lancez pas Chrome avec une option qui ignore les erreurs de certificat. N’abaissez pas la version minimale de TLS et ne réactivez pas d’anciennes suites cryptographiques pour conserver un certificat obsolète. Ne supprimez pas non plus des certificats racines au hasard dans Windows : vous pourriez interrompre d’autres services ou affaiblir leur validation.

Évitez enfin de conclure qu’Edge, Firefox ou Safari « fonctionne donc le site est sûr ». Les navigateurs n’appliquent pas toujours les mêmes contrôles au même moment. Une différence de comportement constitue un indice de diagnostic, pas une preuve de conformité.

Comparatif : reconnaître la bonne correction selon le scénario

Toutes les alertes HTTPS ne se corrigent pas de la même manière. Le code affiché, l’étendue de la panne et le certificat réellement servi permettent de choisir la prochaine action sans multiplier les manipulations inutiles.

Le site échoue sur tous les appareils et tous les réseaux

C’est le scénario le plus compatible avec une erreur côté infrastructure. Inspectez d’abord le certificat public à l’aide de openssl s_client, puis comparez son empreinte à celle attendue. Si digitalSignature manque dans un certificat RSA dont l’extension Key Usage est présente, réémettez-le avec un profil TLS serveur adapté.

Si le fichier local est correct mais que le certificat public ne l’est pas, cherchez une ancienne liaison IIS, un autre VirtualHost, un nœud non mis à jour ou une terminaison TLS placée devant le serveur.

Un seul ordinateur échoue sur de nombreux sites HTTPS

La probabilité d’une mauvaise configuration simultanée de tous ces sites est faible. Examinez la date du système, les mises à jour, le proxy, l’antivirus et le magasin de certificats. Affichez l’émetteur du certificat observé : le nom d’un produit de sécurité ou d’une autorité interne signale souvent une inspection HTTPS.

Dans ce cas, c’est le certificat généré par l’intermédiaire qu’il faut analyser, pas celui du site public.

Tous les appareils du réseau d’entreprise échouent, mais le réseau mobile fonctionne

Le point commun est alors le réseau : proxy explicite, passerelle de sécurité, pare-feu ou inspection TLS. L’équipe réseau doit contrôler le profil de l’autorité interne et la compatibilité des certificats substitués avec les clients Chromium actuels.

La solution n’est pas d’ajouter une exception sur chaque poste. Corriger le modèle d’émission évite que le défaut réapparaisse à chaque certificat généré.

Chrome échoue, tandis qu’un autre navigateur ouvre encore le site

Cette différence indique souvent une validation plus stricte ou une pile de certificats différente. Elle ne justifie ni de recommander l’autre navigateur comme solution permanente, ni de désactiver une politique de sécurité.

Notez les versions exactes, comparez le certificat vu par chaque client et corrigez le profil X.509. Après le remplacement, testez à nouveau tous les navigateurs visés.

Le problème apparaît juste après un renouvellement

Trois contrôles sont prioritaires : le nouveau certificat possède-t-il les bonnes extensions, correspond-il à la clé privée et est-il réellement servi ? Un renouvellement peut produire un fichier correct sans modifier une liaison, ou déployer le certificat sur certains nœuds seulement.

Interrogez plusieurs fois le domaine si un répartiteur distribue les connexions, puis contrôlez individuellement chaque origine.

Certificat RSA ou ECDSA : ce qui change dans le diagnostic

Le message parle d’usage de clé, mais la correction ne consiste pas à ajouter mécaniquement Key Encipherment et Digital Signature à tous les certificats. Les usages cohérents dépendent de l’algorithme de la clé et du profil attendu par le logiciel TLS.

Avec RSA, la clé a historiquement servi soit au chiffrement de clé dans d’anciennes suites, soit à la signature dans les suites modernes. Pour un certificat RSA de serveur actuel, digitalSignature est donc essentiel lorsque l’extension Key Usage est déclarée et que la négociation utilise la signature. Certains profils ajoutent aussi keyEncipherment pour une compatibilité déterminée, mais cela ne doit pas servir à réactiver des suites obsolètes.

Avec ECDSA, la clé sert à la signature et non au chiffrement de clé RSA. Un profil de certificat ECDSA de serveur doit être conçu en conséquence, généralement avec digitalSignature et serverAuth. Copier sans réflexion le profil d’un ancien certificat RSA peut créer une nouvelle incohérence. Le serveur doit également proposer des suites compatibles avec ECDSA et les clients ciblés.

Le choix RSA ou ECDSA dépasse cette erreur. ECDSA offre des clés et signatures plus compactes à niveau de sécurité comparable, tandis que RSA conserve une compatibilité très large avec certains environnements anciens. Sur un site public moderne, les deux peuvent convenir si l’autorité, le serveur, le CDN et les navigateurs sont correctement configurés. Dans une infrastructure interne, inventoriez les clients les plus anciens avant de changer d’algorithme.

La règle sûre reste la même : partez d’un profil TLS serveur maintenu par votre autorité de certification ou votre plateforme, évitez les modèles improvisés et validez le résultat avec le certificat effectivement présenté sur le réseau.

ERR_SSL_KEY_USAGE_INCOMPATIBLE ou autre erreur SSL : comment les différencier ?

Le terme « erreur SSL » regroupe des échecs très différents. Le code du navigateur indique l’étape à examiner en premier, mais il ne remplace pas l’inspection du certificat et des journaux du serveur. Voici les erreurs les plus proches et ce qu’elles changent dans le diagnostic.

NET::ERR_CERT_DATE_INVALID : vérifier les dates avant les usages de clé

Ce message apparaît lorsque le certificat est expiré, pas encore valide ou lorsque l’horloge du poste est incorrecte. Commencez par comparer la date du système aux champs Not Before et Not After. Si le certificat est expiré, renouvelez-le et vérifiez son déploiement. Ajouter digitalSignature ne corrige pas une période de validité dépassée.

La différence essentielle est donc simple : ERR_CERT_DATE_INVALID concerne le temps, alors que ERR_SSL_KEY_USAGE_INCOMPATIBLE concerne les opérations cryptographiques autorisées par le certificat.

NET::ERR_CERT_COMMON_NAME_INVALID : contrôler le SAN et le nom demandé

Ici, le navigateur ne trouve pas le nom saisi dans l’extension Subject Alternative Name. Cela se produit lorsqu’un certificat prévu pour www.exemple.com est présenté sur api.exemple.com, lorsqu’un mauvais VirtualHost répond, ou lorsqu’une appliance sert son certificat par défaut.

La bonne correction consiste à faire émettre un certificat contenant les noms nécessaires et à corriger le routage SNI ou la liaison. Un certificat peut avoir des usages de clé parfaits et rester invalide pour le nom demandé.

NET::ERR_CERT_AUTHORITY_INVALID : examiner la confiance et la chaîne

Ce code signale que le navigateur ne parvient pas à relier le certificat à une autorité racine approuvée. Les causes fréquentes sont un certificat auto-signé non distribué, une autorité interne absente du magasin de confiance ou une chaîne intermédiaire incomplète.

Vérifiez l’émetteur, les intermédiaires présentés et la racine attendue. Dans un environnement interne, distribuez la confiance par les mécanismes d’administration prévus ; sur un site public, servez une chaîne compatible avec les clients ciblés. Ne confondez pas ce défaut de confiance avec un mauvais bit Key Usage.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH : inspecter les protocoles et algorithmes

Cette erreur indique généralement que le client et le serveur ne trouvent pas de version TLS, de suite cryptographique ou d’algorithme compatible. Elle peut aussi apparaître lorsqu’une configuration CDN ou un ancien équipement ne prend pas en charge les paramètres exigés.

La correction porte sur les versions TLS et les algorithmes proposés, sans réactiver SSLv3, TLS 1.0 ou des suites faibles uniquement pour faire disparaître l’erreur. Avec ERR_SSL_KEY_USAGE_INCOMPATIBLE, une négociation compatible existe, mais l’usage déclaré de la clé du certificat ne convient pas à l’opération requise.

ERR_SSL_PROTOCOL_ERROR : rechercher un échec TLS plus général

Ce code est moins précis. Il peut être provoqué par une réponse non-TLS sur le port 443, une terminaison HTTPS mal configurée, un proxy défaillant, une chaîne cassée ou une négociation interrompue. Vérifiez d’abord que le service écoute bien en TLS, puis examinez les journaux, la configuration du VirtualHost et la sortie d’OpenSSL.

Autrement dit, ERR_SSL_PROTOCOL_ERROR décrit un échec de protocole large ; ERR_SSL_KEY_USAGE_INCOMPATIBLE cible une incompatibilité cryptographique identifiée dans le certificat.

ERR_CONNECTION_RESET : distinguer coupure réseau et rejet du certificat

ERR_CONNECTION_RESET signifie que la connexion TCP a été réinitialisée avant la fin de l’échange attendu. Un pare-feu, un proxy, un serveur saturé, un logiciel de sécurité ou un problème réseau peut fermer la session. Le navigateur n’a pas nécessairement reçu assez d’informations pour valider le certificat.

Commencez alors par tester le réseau, le serveur et les intermédiaires. Notre guide consacré à l’erreur ERR_CONNECTION_RESET propose un diagnostic spécifique. À l’inverse, ERR_SSL_KEY_USAGE_INCOMPATIBLE prouve que le client a reçu un certificat et a rejeté l’usage déclaré de sa clé.

Résumé du choix de diagnostic

Si le code mentionne la date, contrôlez l’horloge et la validité. S’il mentionne le nom commun, contrôlez le SAN et le SNI. S’il mentionne l’autorité, contrôlez la chaîne de confiance. S’il mentionne la version ou le chiffrement, comparez les capacités TLS. S’il indique une réinitialisation, examinez le réseau.

Pour ERR_SSL_KEY_USAGE_INCOMPATIBLE, commencez par Key Usage, Extended Key Usage, l’algorithme de la clé et le certificat réellement associé à la terminaison HTTPS.

Vérifications après correction

Une réparation n’est terminée que lorsque le certificat réellement présenté répond à toutes les conditions suivantes :

le SAN contient exactement le nom DNS utilisé ;
le certificat est dans sa période de validité ;
la chaîne mène à une autorité approuvée par les clients visés ;
la clé privée correspond au certificat ;
Key Usage, lorsqu’il est présent, autorise l’opération requise, notamment la signature numérique pour les négociations concernées ;
Extended Key Usage, lorsqu’il est présent, inclut l’authentification serveur ;
IIS, Nginx, Apache, le CDN ou le proxy sert bien la nouvelle empreinte ;
le site fonctionne depuis un réseau externe et plusieurs navigateurs à jour.

Surveillez ensuite les journaux TLS, les erreurs de disponibilité et la date d’expiration. Automatisez le renouvellement lorsque votre autorité le permet, mais vérifiez aussi le déploiement : un certificat renouvelé sur le disque ne sert à rien si le service continue de présenter l’ancien.

FAQ

Un visiteur peut-il corriger ERR_SSL_KEY_USAGE_INCOMPATIBLE ?

Pas si le mauvais certificat est présenté à tous les utilisateurs. Le visiteur peut seulement exclure une mauvaise horloge, un logiciel d’inspection HTTPS ou un problème local. La correction définitive appartient au propriétaire du serveur ou du proxy.

Pourquoi l’erreur apparaît-elle dans Chrome mais pas dans un autre navigateur ?

Les navigateurs peuvent déployer des contrôles de certificat à des dates différentes ou utiliser des piles TLS distinctes. Le certificat doit toutefois être corrigé ; le succès dans un autre navigateur ne garantit pas que ses usages de clé sont adaptés.

Digital Signature et Key Encipherment sont-ils identiques ?

Non. digitalSignature autorise la clé à vérifier des signatures numériques. keyEncipherment concerne l’encapsulation ou le transport de clés. Un certificat RSA de serveur peut contenir les deux, mais le profil approprié dépend de l’algorithme et des usages prévus.

Faut-il renouveler ou réémettre le certificat ?

Si les extensions sont incorrectes, il faut obtenir un nouveau certificat. Selon le fournisseur, l’opération s’appelle réémission ou renouvellement. L’important est que le nouveau certificat soit signé avec le bon profil et effectivement associé au service HTTPS.

Une chaîne intermédiaire manquante provoque-t-elle ce code ?

Pas habituellement. Une chaîne manquante produit plutôt une erreur de confiance. Vérifiez-la tout de même, car un bundle ou une liaison erronée peut faire présenter le mauvais certificat et compliquer le diagnostic.

Sources officielles

Les faits et commandes sont recoupés avec Chromium, les RFC, OpenSSL, Microsoft, Nginx et Apache.

Comment réparer l’erreur ERR_SSL_KEY_USAGE_INCOMPATIBLE : 7 solutions efficaces