Erreur SSL: impossible d'obtenir le certificat de l'émetteur local

95

J'ai du mal à configurer SSL sur un serveur Debian 6.0 32 bits. Je suis relativement nouveau avec SSL, alors soyez indulgents avec moi. J'inclus autant d'informations que possible.
Remarque: le vrai nom de domaine a été modifié pour protéger l'identité et l'intégrité du serveur.

Configuration

Le serveur fonctionne avec nginx. Il est configuré comme suit:

ssl_certificate           /usr/local/nginx/priv/mysite.ca.chained.crt;
ssl_certificate_key       /usr/local/nginx/priv/mysite.ca.key;
ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers               HIGH:!aNULL:!MD5;
ssl_verify_depth          2;

J'ai enchaîné mon certificat en utilisant la méthode décrite ici

cat mysite.ca.crt bundle.crt > mysite.ca.chained.crt

où se mysite.ca.crttrouve le certificat qui m’a été remis par l’autorité de signature, et le bundle.crtcertificat CA m’a également été envoyé par mon autorité de signature. Le problème est que je n'ai pas acheté le certificat SSL directement auprès de GlobalSign, mais plutôt via mon fournisseur d'hébergement, Singlehop.

Essai

Le certificat se valide correctement sur Safari et Chrome, mais pas sur Firefox. La recherche initiale a révélé qu'il pouvait s'agir d'un problème avec l'autorité de certification.

J'ai exploré la réponse à une question similaire , mais je n'ai pas pu trouver de solution, car je ne comprends pas vraiment à quoi sert chaque certificat.

J'ai utilisé le s_client de openssl pour tester la connexion et j'ai reçu une sortie qui semble indiquer le même problème que la question similaire . L'erreur est la suivante:

depth=0 /OU=Domain Control Validated/CN=*.mysite.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /OU=Domain Control Validated/CN=*.mysite.ca
verify error:num=27:certificate not trusted
verify return:1

Un détail complet de la réponse d'openssl (avec des certificats et des informations inutiles tronquées) peut être trouvé ici .

Je vois aussi l'avertissement:

No client certificate CA names sent

Est-il possible que ce soit le problème? Comment puis-je m'assurer que nginx envoie ces noms d'autorité de certification?

Tentatives de résoudre le problème

J'ai tenté de résoudre le problème en téléchargeant la racine CA directement à partir de GlobalSign, mais j'ai reçu la même erreur. J'ai mis à jour les CA racine sur mon serveur Debian en utilisant la update-ca-certificatescommande, mais rien n'a changé. Cela est probablement dû au fait que l'autorité de certification envoyée par mon fournisseur était correcte, ce qui a conduit le certificat à être chaîné deux fois, ce qui n'aide pas.

0 s:/OU=Domain Control Validated/CN=*.mysite.ca
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
1 s:/O=AlphaSSL/CN=AlphaSSL CA - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA

Prochaines étapes

S'il vous plaît laissez-moi savoir si je peux essayer quelque chose, ou si tout est configuré de manière incorrecte.

Jamie Counsell
la source
10
Votre certificat de domaine est signé par l'émetteur AlphaSSL CA - SHA256 - G2. Cependant, votre chaîne fournit des intermédiaires AlphaSSL CA - G2. Je pense que vous devez supprimer le certificat intermédiaire actuel ( AlphaSSL CA - G2) et le remplacer par celui avec empreinte digitale ae:bf:32:c3:c8:32:c7:d7...( AlphaSSL CA - SHA256 - G2). De plus, vous n'avez pas besoin d'envoyer GlobalSign Root CA. Le client doit enraciner sa confiance leur (ou sur l'intermédiaire).
jww
6
Vous pourrez tester cela localement avec OpenSSL. Essayez openssl s_client -connect <server>:<port> -CAfile <GlobalSign Root CA.pem>. La commande doit se terminer par un Verify OK (0)ou similaire. Lorsque vous obtenez le Verify OK (0), le serveur est configuré correctement (pour ce problème).
jww
6
Lorsque vous téléchargez ce nouvel intermédiaire, vous devrez le convertir en PEM avec openssl x509 -in gsalphasha2g2.crt -inform DER -out Alpha-SHA256-G2.pem -outform PEM.
jww
Belle. Je crois que ça marche maintenant. Pour une raison quelconque, je pensais avoir essayé d'obtenir le SHA 256, mais je n'ai pas réussi à le convertir correctement. Merci sincèrement.
Jamie Counsell
1
ouais, ce qu'il faut rechercher, ce sont les paires Sujet-Émetteur qui retournent vers une racine ou une CA. OpenSSL les affiche au fur i:et s:à mesure s_client. Une fois que vous avez les certificats dont vous avez besoin, concattez-les tous sauf la racine. Parce qu'ils sont concatés, ils doivent être au format PEM. L'URL était utile. Cela vieillit en essayant d'aider les gens qui ne fournissent pas d'informations afin que nous puissions les examiner localement s_client. (Si vous n'aviez pas fourni l'URL, j'aurais voté pour la fermeture).
jww

Réponses:

-1

Si vous êtes un utilisateur Linux, mettez à jour le nœud vers une version ultérieure en exécutant

sudo apt update

 sudo apt install build-essential checkinstall libssl-dev

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.35.1/install.sh | bash

nvm --version

nvm ls

nvm ls-remote

nvm install [version.number]

Cela devrait résoudre votre problème

Collins Koech
la source