[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: CA cert does not include key usage extension

Apparaît après le passage à Python 3.13 ou à une version ultérieure ; les versions antérieures ne définissent pas le drapeau strict. Suivi d’un emplacement dans le code source, comme « (_ssl.c:1082) ». openssl verify -x509_strict signale la même vérification sous la forme « error 92 at 1 depth lookup: CA cert does not include key usage extension ».

Python 3.13+ ssl module — VERIFY_X509_STRICT in create_default_context(), X509_V_ERR_CA_CERT_MISSING_KEY_USAGE (92)

Ce que cela signifie

Depuis Python 3.13, ssl.create_default_context() active les vérifications X.509 strictes d’OpenSSL (VERIFY_X509_STRICT). L’une d’elles exige que chaque certificat d’AC comporte une extension keyUsage autorisant la signature de certificats, comme l’impose la RFC 5280. Votre certificat d’AC n’a pas de keyUsage : une chaîne qui fonctionnait sous Python 3.12 est donc désormais rejetée, alors même que l’AC est explicitement approuvée.

Pourquoi cela se produit

• Une AC créée avec un simple openssl req -x509

  fréquente

  La configuration OpenSSL par défaut ajoute basicConstraints, mais pas keyUsage, aux certificats auto-signés. D’innombrables guides créent des AC privées exactement de cette manière, tout comme certaines fixtures de test et certains outils de développement.

• Le client est passé à Python 3.13 ou à une version plus récente

  fréquente

  Le certificat n’a pas changé ; c’est le vérificateur qui est devenu plus strict. Les images de base de conteneurs et les runners de CI qui passent à python:3.13+ font apparaître le problème sans aucune modification de la PKI.

• Anciennes PKI internes ou AC intégrées à des équipements

  occasionnelle

  Certains certificats d’AC générés par des équipements, ainsi que d’anciens certificats d’AC d’entreprise, omettent keyUsage. Ils continuent de fonctionner dans les clients qui n’appliquent pas de vérifications strictes.

Comment corriger l’erreur

1. 1.

   Confirmer quelle extension manque

   Affichez les extensions basicConstraints et keyUsage de l’AC, et lancez openssl verify -x509_strict pour voir d’un coup tous les échecs du mode strict.

   openssl x509 -in ca.pem -noout -ext basicConstraints,keyUsage
   # Same strict checks as Python 3.13+, without Python:
   openssl verify -x509_strict -CAfile ca.pem server.pem

2. 2.

   Réémettre le certificat d’AC avec keyUsage

   Re-signez l’AC avec keyUsage = critical, keyCertSign, cRLSign (et basicConstraints marquée critique). Si vous conservez la même clé et le même sujet, les certificats qu’elle a déjà émis se rattachent toujours au nouveau certificat d’AC ; distribuez le nouveau fichier d’AC aux clients.

   # A CA certificate with the extensions RFC 5280 requires
   openssl req -x509 -new -key ca.key -days 3650 -subj "/CN=Example Private CA" \
     -addext "basicConstraints=critical,CA:TRUE" \
     -addext "keyUsage=critical,keyCertSign,cRLSign" \
     -out ca.pem
   # Reusing the old key and subject keeps already issued certificates verifiable.

3. 3.

   Contournement temporaire : retirer VERIFY_X509_STRICT pour ce contexte

   Retirer ce drapeau rétablit le comportement de Python 3.12 pour un seul contexte. Ce n’est pas la même chose que désactiver la vérification, mais cela fait accepter des certificats qui enfreignent la RFC 5280 ; supprimez ce contournement une fois l’AC corrigée.

   # Temporary workaround while the CA is reissued: the chain, dates and host name
   # are still verified, only the RFC 5280 profile checks are relaxed.
   import ssl
   ctx = ssl.create_default_context(cafile="ca.pem")
   ctx.verify_flags &= ~ssl.VERIFY_X509_STRICT

← Parcourir toute la base de données des erreurs de signature