comment faire en sorte que Gnu / Linux fasse confiance à un certificat qui est approuvé par Windows prêt à l'emploi?

11

Il y a un serveur avec une chaîne SSL cassée, comme indiqué par cette vérification SSL :

Rapport de vérification SSL

Je sais que c'est un problème qui devrait être résolu sur le serveur lui-même, mais parfois c'est difficile à résoudre (je ne suis pas l'administrateur du serveur).

Le fait est que Chrome / Mozilla / Edge sous Windows font de toute façon confiance au certificat de site :

entrez la description de l'image ici

Cependant, dans un déploiement Gnu / Linux (Ubuntu 18.04 dans Docker), le certificat n'est pas approuvé:

curl: (60) SSL certificate problem: unable to get local issuer certificate

J'ai essayé update-ca-certificateset même importé le certificat racine Globalsign. update-ca-certificatessignalé un certificat en double dans ce cas. Quoi qu'il en soit, rien ne fonctionne.

Comment se reproduire

Utilisation de Docker:

docker run -it ubuntu:18.04

# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

Comment puis-je faire en sorte que Gnu / Linux fasse confiance à ce certificat?

PS: le même certificat est déployé correctement sur un autre serveur .

Udo G
la source
pourquoi le downvote?
Udo G
1
Je vote pour clore cette question comme hors sujet parce que le PO demande quelque chose qu'il ne peut pas influencer lui-même. Il a dit qu'il ne pouvait rien modifier côté serveur , donc cela appartient probablement au superutilisateur je pense, car il décrit un problème n'ayant pas de solution côté client.
LinuxSecurityFreak
2
Je demande spécifiquement une solution côté client . Je ne peux pas influencer le serveur, mais j'ai un contrôle total sur le O / S client (Ubuntu) et je veux que cette installation O / S spécifique fasse confiance au certificat, tout comme les autres O / S (Windows). Il ne s'agit pas de réparer le site HTTPS pour les autres.
Udo G
1
Vous ne contrôlez pas le serveur, mais vous pouvez toujours signaler le problème à la personne qui contrôle le serveur.
Michael Hampton

Réponses:

11

La vraie solution est de vous assurer que votre serveur présente tous les certificats de la chaîne et pas seulement le certificat d'entité finale (serveur).

Dirigez votre administrateur de serveur vers la section 7.4.2 de la RFC 5246 qui indique clairement que ce message transmet la chaîne de certificats du serveur au client.


Si votre administrateur refuse / ne peut pas le faire pour une raison quelconque, votre option alternative est d'essayer de vous mettre curlau travail avec la poignée de main malformée.

Selon un message sur la liste de diffusion Curl:

Quelqu'un peut-il confirmer si cURL prend en charge (ou non) un certificat intermédiaire?

Oui. Tous les certificats CA ont une chaîne de certificats remontant à la racine. Le bundle ca que vous utilisez avec curl doit être composé des certificats pour toute la chaîne.

/ daniel.haxx.se

Vous devriez pouvoir ajouter l'autorité de certification racine et tous les certificats intermédiaires à un ensemble et pointer curlvers celui-ci à l'aide de l' --cacert <file>option.

Au fur et à mesure que vos navigateurs fonctionnent, vous pouvez accéder aux bons certificats CA à partir de là. Sur l'onglet certificats (différent pour chaque navigateur, mais je suis sûr que vous comprendrez celui-là), affichez la chaîne de certificats. Double-cliquez sur l'autorité de certification racine première racine de GlobalSign CA - G1 et sur la Détails onglet, cliquez sur Copier dans un fichier ... . Enregistrez-le sous root.cer. Faites de même avec l' AlphaSSL CA-SHA256-G2 et enregistrez-le sous issuing.cer. Joignez les deux ensemble dans un seul fichier (par exemple chain.cer) et utilisez-le comme argument pour -cacert.

Comme l'a gentiment souligné @AB, le certificat manquant peut également être trouvé ici .


Vos navigateurs fonctionnent car ils mettent en cache les certificats CA. Si vous avez navigué vers un site Web correctement configuré à un moment donné dans le passé, dont le certificat a été émis par la même autorité de certification que le certificat de votre serveur, il sera mis en cache par le navigateur. Lorsque vous visitez par la suite votre site incorrectement configuré, votre navigateur utilise les certificats CA dans son cache pour créer la chaîne. Pour vous, il semble que tout va bien, bien que dans les coulisses, le serveur soit mal configuré.

Notez que sous Windows, IE / Edge et Chrome partagent le même cache, tandis que Firefox utilise le sien.

En plus de ce qui précède, IE / Edge et Chrome (car ils partagent la même pile de chiffrement) utiliseront une extension dans les certificats appelée AuthorityInformationAccess . Cela a une option caIssuer qui fournit une URL à partir de laquelle le certificat CA du certificat d'entité finale peut être téléchargé. Par conséquent, même si l'un de ces navigateurs n'a pas mis en cache les certificats manquants de la navigation précédente, il peut le récupérer si nécessaire. Notez que Firefox ne fait pas cela, c'est pourquoi parfois Firefox peut afficher des erreurs de certificat lorsque IE / Edge et Chrome semblent fonctionner.

garethTheRed
la source
1
Ce n'est pas mon serveur, donc je ne peux rien modifier côté serveur. J'ai essayé d'utiliser le bundle CA à partir de curl.haxx.se/docs/caextract.html (puisque Firefox fait confiance au certificat) et de le passer en utilisant --cacert cacert.pemmais CURL n'accepte toujours pas le certificat.
Udo G
1
Il est votre serveur. Exécutez echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443et vous ne verrez qu'un seul certificat présenté par votre serveur. Il devrait y en avoir deux - le certificat d'entité finale (qui est présenté) et l'autorité de certification émettrice - le certificat Alpha SSL - SHA256 - G2. Ce dernier n'est pas envoyé par le serveur, mais devrait l'être.
garethTheRed
2
@garethTheRed: Je comprends que le serveur ne présente pas tous les certificats, mais le serveur n'est pas sous mon contrôle (c'est ce que je voulais dire par "pas mon serveur"). J'essaie juste d'accéder à une API sur un serveur étranger. Sous Windows, aucun de mes navigateurs ne se plaint du certificat, seul Linux / Debian / Ubuntu le fait.
Udo G
@AB: merci beaucoup! L'installation de tous les certificats racine à partir de cette page a résolu le problème . Cependant, j'aimerais comprendre pourquoi cette étape manuelle est nécessaire.
Udo G
2
Le certificat intermédiaire manquant (comme mentionné par @garethTheRed) peut être trouvé ici: support.globalsign.com/customer/portal/articles/… . Au départ, OP a seulement essayé d'ajouter le certificat racine qui était probablement déjà en place, n'atteignant ainsi rien.
AB