Comment mettre à jour le bundle cURL CA sur RedHat?


38

Je rencontre des problèmes pour lesquels le groupe d'autorités de certification fourni avec ma version de cURL est obsolète.

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

Lire la documentation ne m'a pas aidé car je ne comprenais pas ce que je devais faire ou comment le faire. J'utilise RedHat et j'ai besoin de mettre à jour le bundle CA. Que dois-je faire pour mettre à jour mon bundle d'AC sur RedHat?

Réponses:


50

Pour RHEL version 6 ou ultérieure , vous devriez utiliser update-ca-trust , comme décrit par lzap dans sa réponse ci-dessous.

--- Pour les anciennes versions de Fedora, CentOS, Redhat:

Curl utilise le groupe d’autorités de certification par défaut du système qui est stocké dans /etc/pki/tls/certs/ca-bundle.crt. Avant de le modifier, effectuez une copie de ce fichier afin de pouvoir restaurer les paramètres système par défaut, le cas échéant. Vous pouvez simplement ajouter de nouveaux certificats d’autorité de certification à ce fichier ou remplacer l’ensemble complet.

Vous vous demandez également où obtenir les certificats? Je (et les autres) recommandent curl.haxx.se/ca. En une ligne:

curl https://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt

L’emplacement de Fedora Core 2 est /usr/share/ssl/certs/ca-bundle.crt.


C'est bien, mais comment puis-je être sûr que le certificat que j'ai ajouté ne sera pas perdu lors de la prochaine mise à jour de ca-bundle.crt? Y a-t-il un endroit où je peux mettre le nouveau où il sera automatiquement inclus?
Andrew Schulman

À partir de 2006, les mises à niveau openssl ne devraient pas remplacer le fichier ca-bundle.crt (voir rhn.redhat.com/errata/RHSA-2006-0661.html ). Cependant, si vous avez installé un autre package, comme le package ca-certificates recommandé par @mgorven, je suppose qu'il sera écrasé manuellement.
Nada

36

La méthode recommandée pour cela sur les systèmes RHEL 6+ consiste à utiliser l' outil update-ca-trust , qui est maintenant installé par défaut.

# cat /etc/pki/ca-trust/source/README 
This directory /etc/pki/ca-trust/source/ contains CA certificates and 
trust settings in the PEM file format. The trust settings found here will be
interpreted with a high priority - higher than the ones found in 
/usr/share/pki/ca-trust-source/.

=============================================================================
QUICK HELP: To add a certificate in the simple PEM or DER file formats to the
            list of CAs trusted on the system:

            Copy it to the
                    /etc/pki/ca-trust/source/anchors/
            subdirectory, and run the
                    update-ca-trust
            command.

            If your certificate is in the extended BEGIN TRUSTED file format,
            then place it into the main source/ directory instead.
=============================================================================

Please refer to the update-ca-trust(8) manual page for additional information

Par conséquent, il vous suffit de déposer votre fichier crt dans /etc/pki/ca-trust/source/anchors/et d'exécuter l'outil. Travail effectué. C'est sûr, vous n'avez pas besoin de faire de sauvegarde. La page de manuel complète peut être trouvée ici: https://www.mankier.com/8/update-ca-trust


Bonjour, ça marche pour vous? J'ai juste essayé de suivre le scénario de access.redhat.com/solutions/1549003 et cela ne fonctionne pas pour moi.
Kirby

6

RHEL fournit les certificats de l'autorité de certification Mozilla dans le ca-certificatespackage (installez-le yums'il n'est pas déjà installé). Pour dire à cURL de les utiliser, utilisez le --cacertparamètre comme suit.

curl --cacert /etc/ssl/certs/ca-bundle.crt https://google.com/

J'ai essayé yum install ca-certificateset obtenuNo package ca-certificates available
Andrew le

1
RHEL6 a ce paquet; Je suppose que vous utilisez une version plus ancienne. Malheureusement, la liste n'a pas changé depuis 2010, merci de nous tenir au courant.
Dan Pritts

J'utilise RHEL7 sur AWS EC2, je viens de mettre à niveau mon package pour ca-certificates.noarch 0:2014.1.98-70.0.el7_0- cela n'a malheureusement pas résolu mon problème, mais je pensais que j'ajouterais ces informations.
DuffJ

6

Cela dépend probablement de la version de Redhat. Vous pouvez trouver quel paquet met réellement à jour le fichier en procédant comme suit:

rpm -qf /etc/pki/tls/certs/ca-bundle.crt

Mon résultat montrait que openssl-0.9.8e-12.el5 doit être mis à jour.

S'il n'y a pas de certificats mis à jour dans votre distribution, vous devez mettre à jour manuellement, conformément à la réponse de Nada.


6

Depuis le commentaire de Dan Pritts, Red Hat met à jour plus souvent les ensembles de certificats pour les versions RHEL prises en charge. vous pouvez le voir assez facilement dans le changelog du paquet. Les certificats RHEL 6 ont été mis à jour deux fois en 2013 et deux fois en 2014.

Toutes les distributions RHEL et associées / clones / dérivées fournissent un fichier bundle à /etc/pki/tls/certs/ca-bundle.crt, et le même fichier à /etc/pki/tls/cert.pem(sur les distributions plus anciennes, cert.pemun lien symbolique vers ca-bundle.crt; sur les distributions plus récentes, les deux sont des liens symboliques vers un fichier généré par update-ca-trust).

Dans RHEL 6 et versions ultérieures, le kit fait partie du package 'ca-certificates'. Dans RHEL 5 et les versions antérieures, il fait partie du package 'openssl'.

Dans RHEL 6 avec la mise à jour https://rhn.redhat.com/errata/RHEA-2013-1596.html et dans toute version plus récente de RHEL, le système de «certificats de système partagé» est disponible (vous devez l'exécuter update-ca-trust enablepour l'activer) et le meilleur méthode est celle donnée par lzap. Un avantage de ce système est qu’il fonctionne pour les applications basées sur NSS et GnuTLS ainsi que pour celles basées sur OpenSSL. Notez que vous pouvez également vous méfier d'un certificat en le plaçant dans l'annuaire /etc/pki/ca-trust/source/blacklist/.

Dans RHEL 5 et plus (et RHEL 6 si vous ne souhaitez pas utiliser le nouveau système) , vous pouvez faire confiance à CA supplémentaires en plaçant leurs fichiers de certificat au format PEM avec l'extension.pem dans / etc / pki / tls / certs et en cours d' exécution c_rehash(peut aussi avoir besoin yum install /usr/bin/c_rehash). Cela ne fonctionnera que pour les logiciels qui utilisent les magasins d'approbation par défaut d'OpenSSL. Cela vaut mieux que de modifier ou de remplacer le fichier de paquet car cela vous permet de continuer à recevoir les mises à jour officielles du fichier de paquet.

Les logiciels qui utilisent directement l’un des emplacements de fichiers du bundle (au lieu de demander à OpenSSL d’utiliser les librairies sécurisées par défaut du système) ne respecteront pas la modification; si vous avez un tel logiciel, vous êtes bloqué pour éditer le fichier de bundle (ou pour améliorer le logiciel). Les logiciels qui n'utilisent pas du tout OpenSSL ne respecteront pas le certificat ajouté.


3

Il me suffisait de faire cela sur une vieille boîte RHEL5. J'ai touché le crochet 22 ... curl rejetterait le téléchargement https car les certificats de la machine étaient trop anciens pour valider les certificats curl.haxx.se.

J'ai utilisé l'option --insecure de curl pour forcer le téléchargement https. (Ouais, je sais ... c'est "peu sûr".)

curl https://curl.haxx.se/ca/cacert.pem --insecure -o /etc/pki/tls/certs/ca-bundle.crt


1

Pour RHEL 6 , j'ai pu résoudre ce problème en mettant à jour et en réinstallant le dernier package CA certs de Red Hat:

sudo yum update ca-certificates
sudo yum reinstall ca-certificates

(Dans mon cas, cela suffisait pour autoriser le certificat de signature "Let's Encrypt Authority X3" plus récent.


La commande a fonctionné pour moi (CentOS 6) mais n'a pas résolu mon problème (avec un certificat délivré par "DigiCert SHA2 Secure Server CA")
rinogo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.