Comment puis-je m'assurer que Stunnel envoie tous les certificats CA intermédiaires?

Quelques ordinateurs, mais pas la plupart, rejettent le certificat SSL de mon serveur Web. Le problème semble être que certains ordinateurs rejettent les certificats CA. Le problème semble se manifester sur Mac OS X 10.6 lorsqu'il n'est pas entièrement mis à jour.

Selon http://www.sslshopper.com/index.php?q=ssl-checker.html#hostname=beta.asana.com - il n'y a pas de problème.

Selon http://certlogik.com/sslchecker/ , aucun certificat intermédiaire n'est envoyé.

Mon certificat vient de Starfield Technologies et j'utilise sf_bundle.crtd'ici: certs.godaddy.com/anonymous/repository.seam

Je gère SSL sur mon serveur via stunnel avec les éléments suivants stunnel.conf:

cert = $CODEZ/admin/production/proxy/asana.pem
CAfile = $CODEZ/admin/production/proxy/sf_bundle.crt
pid =
client = no

[<forwarded port>]
accept = 443
connect = 8443

Des idées sur ce que je pourrais faire de mal?

L' CAFileoption configure une autorité de certification à utiliser pour les certificats d'authentification client; ce n'est pas ce que tu veux.

Au lieu de cela, vous souhaitez créer le fichier dans l' certoption pour contenir toute la chaîne de certificats applicable. Vous voudrez enregistrer une copie de sauvegarde de ce fichier, puis en créer un nouveau; combinant essentiellement les deux fichiers, formatés comme ceci:

-----BEGIN CERTIFICATE-----
(certificate from asana.pem file pasted here)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(intermediate certificate here; copy-paste the top chunk from the bundle)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root certificate here; copy-paste the bottom chunk from the bundle)
-----END CERTIFICATE-----

Cela obligera Stunnel à présenter la chaîne de certificats complète aux clients.

Une autre friandise; la openssl s_clientcommande est très utile pour tester les problèmes de chaîne de certificats et vérifier comment votre service présente ses certificats.

Edit: Ok .. la chaîne de cet ensemble de certificats est à trois profondeurs, mais la chaîne de confiance semble à deux profondeurs. Quelque chose ne va pas.

Le certificat supérieur ("Starfield Secure Certification Authority") est signé par un émetteur nommé "Starfield Class 2 Certification Authority" avec une empreinte numérique commençant par ad7e1c28.. mais le deuxième cert du bundle, nommé exactement de la même manière que le premier signataire du cert, qui devrait être exactement le même certificat, a une empreinte digitale commençant par 363e4734et une date d'expiration 10 ans plus tôt. Le troisième certificat (racine) est alors le signataire du certificat intermédiaire inclus .. mais aucun de ces deux n'a de relation avec le premier!

Si cela n'a pas de sens, ne vous inquiétez pas. Résumé: travail bâclé, quelqu'un a sérieusement laissé tomber la balle en construisant ce bundle cert. Votre meilleur pari est alors d'exporter les fichiers au format base-64 à partir d'un navigateur qui valide avec succès la chaîne, en les collant dans le format que j'ai répertorié à partir de là.

Comme c'est un gâchis déroutant sans aucune faute de votre part, j'ai pris une supposition sur votre nom DNS et j'ai attrapé le certificat, et je pense que cela devrait être la chaîne complète dont vous avez besoin: http://pastebin.com/Lnr3WHc8

Qualys SSLLabs est vraiment pratique pour vérifier votre configuration après les modifications.

https://www.ssllabs.com/ssldb/analyze.html

Vérifie que vous avez

• chiffres forts activés
• chiffrement faible désactivé
• la chaîne de certificats complète et dans le bon ordre

Pour toute autre personne confrontée à ce problème, le message de Shane a fait l'affaire, même si j'ai également dû inclure le fichier CAFile. Aussi, lors de la création de la chaîne, assurez-vous de suivre les instructions de dénomination des fichiers conformément à cet article

Pour déterminer le nom de fichier que vous devez utiliser, vous pouvez utiliser le programme c_hash fourni avec OpenSSL (dans le /usr/local/ssl/miscrépertoire):

c_hash some_certificate.pem
a4644b49.0 => some_certificate.pem

Donc, dans le cas ci-dessus, vous renommeriez le fichier a4644b49.0.
(Notez que c'est un zéro, pas la lettre «O», après le point dans le nom de fichier.)

Si vous n'avez pas le c_hashprogramme, vous pouvez exécuter la commande OpenSSL appropriée pour déterminer la valeur de hachage:

openssl x509 -hash -noout -in some_certificate.pem
a4644b49

Et si vous êtes confronté à ce problème, car vous essayez d'utiliser des Websockets avec Android Cordova, assurez-vous d'ajouter manuellement wss à votre liste cordova-liste blanche, car le * ne comprend que http et https.