Python Urllib2 erreur SSL

Python 2.7.9 est maintenant beaucoup plus strictes à propos de la vérification du certificat SSL. Génial!

Je ne suis pas surpris que les programmes de travail avant sont en train de CERTIFICATE_VERIFY_FAILED erreurs. Mais je n'arrive pas à obtenir leur travail (sans la désactivation de la vérification du certificat entièrement).

Un programme a l'aide de urllib2 pour se connecter à Amazon S3 sur https.

J'ai télécharger le certificat racine CA dans un fichier appelé "verisign.pem" et essayez ce qui suit:

import urllib2, ssl
context = ssl.create_default_context()
context.load_verify_locations(cafile = "./verisign.pem")
print context.get_ca_certs()
urllib2.urlopen("https://bucket.s3.amazonaws.com/", context=context)

et je reçois toujours CERTIFICATE_VERIFY_FAILED erreurs, même si l'autorité de certification racine est imprimé correctement à la ligne 4.

openssl peut se connecter à ce serveur d'amende. En fait, voici la commande que j'ai utilisé pour obtenir le CA cert:

openssl s_client -showcerts -connect bucket.s3.amazonaws.com:443 < /dev/null

J'ai pris la dernière cert dans la chaîne et le mettre dans un fichier PEM, qui openssl se lit très bien. C'est un certificat Verisign avec:

Serial number: 35:97:31:87:f3:87:3a:07:32:7e:ce:58:0c:9b:7e:da
Subject key identifier: 7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
SHA1 fingerprint: F4:A8:0A:0C:D1:E6:CF:19:0B:8C:BC:6F:BC:99:17:11:D4:82:C9:D0

Toute idées sur la façon de le faire fonctionner avec la validation est activé?

Le certificat est en verisign.pem? Assurez-vous qu'il s'agit d'un certificat avec Empreinte SHA1 de A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B (Classe 3 Primaire Publique de l'Autorité de Certification) et non pas l'un avec 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5 (VeriSign Class 3 Primaire Publique de l'Autorité de Certification - G5)
J'ai finalement trouvé que l'un et ça fonctionne, merci! Comment pouvez-vous dire lequel certificat racine qui est utilisé? Je suis à l'aide d'openssl x509 commande pour vidage de chaque cert dans la chaîne. La plupart d'entre eux disent qui cert ils ont signé avec, mais je ne vois pas où la dernière, dit racine cert il a été signé.

OriginalL'auteur abjennings | 2015-01-06

  1. 30

    Pour résumer les commentaires au sujet de la cause du problème et d'expliquer le réel problème plus en détail:

    Si vous cochez la chaîne de confiance pour la OpenSSL client, vous obtenez le résultat suivant:

     [0] 54:7D:B3:AC:BF:... /CN=*.s3.amazonaws.com 
 [1] 5D:EB:8F:33:9E:... /CN=VeriSign Class 3 Secure Server CA - G3
 [2] F4:A8:0A:0C:D1:... /CN=VeriSign Class 3 Public Primary Certification Authority - G5
[OT] A1:DB:63:93:91:... /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

    Le premier certificat [0] est la feuille certificat envoyé par le serveur. La suite certifcates [1] et [2] sont de la chaîne de certificats envoyés par le serveur. Le dernier certificat [OT] est le certificat racine de confiance, ce qui n'est pas envoyé par le serveur, mais est dans le local de stockage de l'autorité de certification de confiance. Chaque certificat de la chaîne est signé par le suivant et le dernier certificat [OT] est de confiance, de sorte que la chaîne de confiance est terminée.

    Si vous cochez la chaîne de confiance plutôt que par un navigateur (par exemple: Google Chrome à l'aide de la NSS bibliothèque), vous obtenez la chaîne suivante:

     [0] 54:7D:B3:AC:BF:... /CN=*.s3.amazonaws.com 
 [1] 5D:EB:8F:33:9E:... /CN=VeriSign Class 3 Secure Server CA - G3
[NT] 4E:B6:D5:78:49:... /CN=VeriSign Class 3 Public Primary Certification Authority - G5

    Ici [0] et [1] sont de nouveau envoyés par le serveur, mais [NT] est le certificat racine de confiance. Tout cela ressemble à partir de l'objet exactement comme la chaîne de certificat [2] l'empreinte dit que les certificats sont différents. Si vous voulez prendre un proche semble à l'certificats [2] et [NT] vous voyez que la clé publique à l'intérieur du certificat est le même et donc à la fois [2] et [NT] peut être utilisée pour vérifier la signature de [1] et peut donc être utilisé pour construire la chaîne de confiance.

    Cela signifie que, tandis que le serveur envoie la même chaîne de certificat dans tous les cas, il y a plusieurs façons de vérifier la chaîne jusqu'à un certificat racine de confiance. Comment c'est fait dépend de la bibliothèque SSL et sur l'connu les certificats racine de confiance:

                              [0] (*.s3.amazonaws.com)
                           |
                          [1] (Verisign G3) --------------------------\
                           |                                          |
      /------------------ [2] (Verisign G5 F4:A8:0A:0C:D1...)         |
      |                                                               |
      |              certificates sent by server                      |
 .....|...............................................................|................
      |              locally trusted root certificates                |
      |                                                               |
     [OT] Public Primary Certification Authority        [NT] Verisign G5 4E:B6:D5:78:49
     OpenSSL library                                    Google Chrome (NSS library)

    Mais la question demeure, pourquoi votre vérification a échoué.
    Ce que vous avez fait était de prendre le certificat racine de confiance utilisé par le navigateur (Verisign G5 4E:B6:D5:78:49) avec OpenSSL. Mais la vérification dans le navigateur (NSS) et OpenSSL fonctionner de manière légèrement différente:

    • NSS: bâtir la confiance de la chaîne de certificats envoyer par le serveur. Arrêter de construire la chaîne quand nous avons obtenu un certificat signé par l'un des localement des certificats racine de confiance.
    • OpenSSL_ renforcer la confiance de la chaîne de certificats envoyés par le serveur. Après ceci est fait vérifier si nous avons une racine de confiance de signature de certificat le certificat le plus récent de la chaîne.

    En raison de cette différence subtile OpenSSL n'est pas en mesure de vérifier la chaîne [0],[1],[2] contre le certificat racine [NT], parce que ce certificat ne signe pas le dernier élément de la chaîne [2] mais au lieu de cela [1]. Si le serveur au lieu de cela seulement envoyé une chaîne de [0],[1], alors la vérification de la réussite.

    C'est un longue bug connu et il existe les patchs et j'espère que la question si finalement abordé dans OpenSSL 1.0.2 avec l'introduction de la X509_V_FLAG_TRUSTED_FIRST option.

    C'est une excellente réponse et j'ai marqué comme correcte. Merci!!!! Mon erreur a été de passage dans cert [2] et attendu que pour valider la chaîne (également essayé [0] et [1]). J'ai pensé [2] a une racine cert. Je ne savais pas à chercher [OT], ni où le trouver. Une fois que vous m'avez dit que l'empreinte digitale, je l'ai trouvé dans /usr/local/share/certs/ca-racine-nss.crt (FreeBSD), mais j'aurais pu également trouvé dans Firefox ou téléchargé à partir de Verisign. Mais comment savez-vous qui racine cert était la bonne? Les navigateurs les identifier par l'émetteur des chaînes?
    OpenSSL recherches par l'émetteur de la chaîne et vérifie ensuite si la signature correspond.

    OriginalL'auteur Steffen Ullrich