web-dev-qa-db-fra.com

Résolution des échecs de négociation d'alertes sslv3 lors de la tentative d'utilisation d'un certificat client

J'essaie de me connecter à un service nécessitant un certificat pour autorisation. Le processus consiste à envoyer au service un fichier CSR. Le service signe le CSR et m'envoie un certificat que j'utilise pour la connexion.

  1. J'ai généré le CSR par la ligne de commande suivante:

    openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr

  2. J'ai pris le contenu de cert.csr et leur ai envoyé. Ils génèrent le certificat client et j'ai récupéré un fichier PEM.

  3. J'essaie maintenant de me connecter en utilisant leur fichier de certificat dans SSLCERT pour curl () et en fournissant la clé privée de cert.key sous la forme CURLOPT_SSLKEY que j'ai obtenue à l'étape 1).

  4. Échoue avec: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Qu'est-ce que je fais mal dans ce processus?

--- (Cela fonctionne lorsque j'essaie avec un certificat de test comprenant une clé privée du service (certificat auto-signé). Mais lorsque j'utilise un certificat généré par mon CSR, puis ma clé privée comme clé, cela provoque une erreur lors de la négociation.

Je sais donc que cela n’a rien à voir avec le fait que openssl/curl ne prend pas en charge v3/TLS, etc., ce que d’autres, lors de la recherche d’une solution, ont découvert que leur problème était.

Voici ce que je lance:

  curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0

Exécution des versions suivantes: curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3

sslcurlopensslclient-certificates
11
Karem

Pas une réponse définitive, mais trop pour tenir dans les commentaires:

Je suppose qu’ils vous ont fourni un certificat indiquant qu’il s’agissait d’un mauvais émetteur (bien que leur serveur puisse = utiliser un code d’alerte plus spécifique pour cela) ou d’un sujet erroné. Nous savons que le certificat correspond à votre clé privée - parce que curl et openssl client les a jumelés sans se plaindre d’une inadéquation; mais nous ne savons pas réellement qu'il correspond aux autorités de certification souhaitées, car votre adresse curl utilise openssl et que le client SSL d'OpenSl n'impose PAS qu'un certificat client configuré corresponde à certreq.CAs.

Faire openssl x509 <clientcert.pem -noout -subject -issuer et le même sur le cert du test P12 qui fonctionne. Faire openssl s_client (ou cochez celle que vous avez faite) et regardez sous Acceptable client certificate CA names; le nom ou l'un d'entre eux doit correspondre (exactement!) à l'émetteur ou aux émetteurs de vos certificats. Sinon, c'est probablement votre problème et vous devez vérifier auprès d'eux que vous avez soumis votre CSR au bon endroit et de la bonne manière. Ils ont peut-être des régimes différents selon les régions, les secteurs d'activité, le test vs le produit, le test actif ou l'attente, etc.

Si l'émetteur de votre certificat correspond auxCAA souhaités, comparez son sujet à celui qui fonctionne (test-P12): sont-ils dans un format similaire? y a-t-il des composants dans le composant actif qui ne sont pas présents dans le vôtre? S'ils le permettent, essayez de générer et de soumettre un nouveau CSR avec un nom de sujet identique à celui de test-P12, ou le plus près possible, et voyez si cela produit un certificat qui fonctionne mieux. (Vous n'avez pas besoin de générer une nouvelle clé pour le faire, mais si vous le souhaitez, gardez une trace des certificats qui correspondent aux clés afin de ne pas les mélanger.) aidez pas à regarder les extensions de certificat avec openssl x509 <cert -noout -text pour toute différence pouvant raisonnablement être liée à l'autorisation du sujet, telle que KeyUsage, ExtendedKeyUsage, peut-être une stratégie, peut-être des contraintes, voire même un élément non standard.

Si tout échoue, demandez au (x) opérateur (s) du serveur ce que ses journaux indiquent à propos du problème, ou si vous avez accès, consultez les journaux vous-même.

4
dave_thompson_085

Quelle clé privée SSL doit être envoyée avec le certificat client?

Aucun d'entre eux :)

L’un des attraits des certificats clients est qu’il ne fait pas de bêtises, comme de transmettre un secret (comme un mot de passe), en texte brut à un serveur (HTTP basic_auth). Le mot de passe est toujours utilisé pour déverrouiller la clé du certificat client, il n’est pas utilisé directement pour échanger ou authentifier le client.

Au lieu de cela, le client choisit une clé aléatoire temporaire pour cette session. Le client signe ensuite la clé aléatoire temporaire avec son certificat et l'envoie au serveur (renonciation de la main). Si un méchant intercepte quelque chose, c'est aléatoire afin qu'il ne puisse plus être utilisé à l'avenir. Il ne peut même pas être utilisé pour une deuxième exécution du protocole avec le serveur car celui-ci sélectionnera également une nouvelle valeur aléatoire.

Échec avec: erreur: 14094410: routines SSL: SSL3_READ_BYTES: échec de la négociation de l'alerte sslv3

Utilisez TLS 1.0 et ci-dessus; et utilisez Indication du nom du serveur .

Vous n'avez pas fourni de code, donc ce n'est pas clair pour moi comment vous dire quoi faire. À la place, voici la ligne de commande OpenSSL pour le tester:

openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com \
    -cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem

Vous pouvez aussi utiliser -CAfile pour éviter le “erreur de vérification: num = 20” . Voir, par exemple, "verify error: num = 20" lors de la connexion à gateway.sandbox.Push.Apple.com .

5
jww