web-dev-qa-db-fra.com

Problèmes de permission avec /etc/ssl/certs/ca-certificates.crt

Lorsque vous tentez d'utiliser curl ou git clone quelque chose sur HTTPS en tant qu'utilisateur normal, l'erreur échoue avec le message suivant:

fatal: unable to access 'https://github.com/mikemackintosh/xxx/': Problem with the SSL CA cert (path? access rights?)

Note: Si je lance les commandes en tant que root, cela fonctionne bien, mais root ne doit pas être le seul utilisateur capable de communiquer via ssl.

Alors, je me dis, ok, que fait curl dans les coulisses:

$ GIT_CURL_VERBOSE=1 git clone https://github.com/mikemackintosh/xxx
Cloning into 'xxx'...
* Couldn't find Host github.com in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
*   Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* error reading ca cert file /etc/ssl/certs/ca-certificates.crt (Error while reading file.)
* Closing connection 0
fatal: unable to access 'https://github.com/mikemackintosh/xxx/': Problem with the SSL CA cert (path? access rights?)

Par conséquent, nous sommes en mesure de confirmer que le fichier ca-certificate est: /etc/ssl/certs/ca-certificates.crt qui correspond à la sortie de curl-config -ca.

L'étape suivante consiste à essayer de lire le fichier. En tant que simple utilisateur non root:

$ cat /etc/ssl/certs/ca-certificates.crt
cat: /etc/ssl/certs/ca-certificates.crt: Permission denied

Maintenant, cela semble étrange.

$ Sudo ls -la /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 273790 Jun 15 22:35 /etc/ssl/certs/ca-certificates.crt

$ Sudo lsattr /etc/ssl/certs/ca-certificates.crt
-------------e-- /etc/ssl/certs/ca-certificates.crt

Donc, en regardant les autorisations, il est lisible par tout le monde. Il ne devrait y avoir aucun problème pour y accéder. Aucun attribut fou empêchant l'accès.

faire un ls -la /etc/ssl/certs/ retourne:

...
l????????? ? ? ? ?            ? Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.pem
l????????? ? ? ? ?            ? VeriSign_Universal_Root_Certification_Authority.pem
l????????? ? ? ? ?            ? Visa_eCommerce_Root.pem
l????????? ? ? ? ?            ? WellsSecure_Public_Root_Certificate_Authority.pem
l????????? ? ? ? ?            ? WoSign_China.pem
l????????? ? ? ? ?            ? WoSign.pem
...

Si je lance un Sudo cat /etc/ssl/certs/ca-certificates.pem, il crache le contenu comme prévu.

Oh, c'est à coup sûr un problème d'autorisations.

En faisant des recherches sur Google, j'ai constaté qu'il existe un groupe ssl-cert, mais ce groupe n'a pas les droits sur le répertoire /etc/ssl/certs.

Élimine l'apparmeur, exclut la corruption du disque, il n'y a aucune amélioration si je lance update-ca-certificates (w/wo -f), etc.

Quelqu'un a-t-il vu ce comportement?

Je n'ai jamais rien vu de tel auparavant, mais je l'ai dupliqué sur deux machines distinctes. En guise de remarque, je viens d’un milieu CentOS/RHEL. Il pourrait donc s'agir d’un comportement normal d’Ubuntu, mais j’aimerais bien trouver une solution réelle.

14.04permissionsssl
3
Mike Mackintosh

Exécutez namei -mo /etc/ssl/certs/ca-certificates.crt. Faites correspondre sa sortie à ce qui suit:

f: /etc/ssl/certs/ca-certificates.crt
 drwxr-xr-x root root /
 drwxr-xr-x root root etc
 drwxr-xr-x root root ssl
 drwxr-xr-x root root certs
 -rw-r--r-- root root ca-certificates.crt

Vous pouvez utiliser chmod et chown pour rétablir tous les paramètres corrects:

  • Sudo chown root / && chown root /etc/ && chown root /etc/ssl/ && chown root /etc/ssl/certs/ && chown root /etc/ssl/certs/ca-certificates.crt
  • Sudo chmod 755 /
  • Sudo chmod 755 /etc/
  • Sudo chmod 755 /etc/ssl/
  • Sudo chmod 755 /etc/ssl/certs
  • Sudo chmod 644 /etc/ssl/certs/ca-certificates.crt
10
earthmeLon

J'ai rencontré le même problème aujourd'hui. Voici ce que j'ai fait:

GIT_CURL_VERBOSE = 1 clone de git https://github.com/robbyrussell/oh-my-zsh.git

Ce référentiel de clones en mode curl verbose (curl est à l’origine du problème)

Voici ce que j'ai

Cloning into 'oh-my-zsh'...
* Couldn't find Host github.com in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
*   Trying 192.30.252.131...
* Connected to github.com (192.30.252.131) port 443 (#0)
* error reading ca cert file /bin/curl-ca-bundle.crt (Error while reading file.)
* Closing connection 0
fatal: unable to access 'https://github.com/robbyrussell/oh-my-zsh.git/': Problem with the SSL CA cert (path? access rights?)

Notez la ligne:

  • erreur de lecture du fichier de certificat ca /bin/curl-ca-bundle.crt (erreur lors de la lecture du fichier.)

J'ai eu un problème de configuration dans la section ~/.gitconfig[HTTP]->sslCAinfo. Vous n’avez peut-être pas le même problème, mais cela vous donnera suffisamment d’informations pour déboguer vous-même.

4
VarunAgw

Sous Unix, tout le chemin est vérifié, donc à mon avis, vous devriez vérifier si les dossiers du chemin ont des autorisations. Je pense qu'ils devraient avoir au moins rw-, ne paniquez pas, w ne signifie pas écrire si parler à propos des dossiers ... Parce que si vous avez /a/b/c/certificate.pem et que vous ne pouvez pas aller au-delà de "b", vous ne pouvez pas aller au-delà de b: D

J'espère que ça aide :)

2
IcyIcyIce

Assurez-vous de disposer de certificats d'autorité de certification pour permettre aux applications basées sur SSL de vérifier l'authenticité des connexions SSL. Ils peuvent être installés par:

Sudo apt-get install ca-certificates openssl

Cela peut être manquant, en particulier dans les conteneurs Docker ou CI.

Si vous en avez, envisagez de le réinstaller.

Vous pouvez également essayer de lancer: Sudo update-ca-certificates.

En relation:

0
kenorb