J'ai un étrange problème. Mise à jour de ma machine de développement LAMP (Debian) vers PHP 7. Ensuite, je ne peux plus me connecter à une API cryptée TLS spécifique via Curl.
Le certificat SSL en question est signé par thawte.
curl https://example.com
Donne moi
curl: (60) SSL certificate problem: unable to get local issuer certificate
tandis que
curl https://thawte.com
qui, bien sûr, est également signé par Thawte Works.
Je peux accéder au site API via HTTPS sur d'autres machines, par exemple mon bureau via curl et dans le navigateur. Le certificat est donc définitivement valide. La cote SSL Labs est A.
Toutes les autres demandes Curl de ma machine de développement vers d'autres sites cryptés SSL fonctionnent. Mes certificats racine sont à jour. Pour vérifier, j'ai couru update-ca-certificates. J'ai même téléchargé http://curl.haxx.se/ca/cacert.pem vers / etc / ssl / certs et j'ai couru c_rehash.
Toujours la même erreur.
Existe-t-il un moyen de déboguer le processus de vérification et de voir quelle boucle d'émetteur de certificat local (ou openssl) recherche mais ne trouve pas, c'est-à-dire un nom de fichier?
MISE À JOUR
curl -vs https://example.com
me dit (IP + domaine anonymisé)
* Hostname was NOT found in DNS cache
* Trying 192.0.2.1...
* Connected to example.com (192.0.2.1) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Et
echo | openssl s_client -connect example.com:443
donne
CONNECTED(00000003)
depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=DE/ST=XYZ/CN=*.example.com
i:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
1 s:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/C=DE/ST=XYZ/CN=*.example.com
issuer=/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 4214 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5a 95 df 40 2c c9 6b d5-4a 50 75 c5 a3 80 0a 2d Z..@,.k.JPu....-
[...]
00b0 - d5 b9 e8 25 00 c5 c7 da-ce 73 fb f2 c5 46 c4 24 ...%.....s...F.$
Start Time: 1455111516
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
DONE
curl -vs https://example.com echo | openssl s_client -connect example.com:443Réponses:
Utilisation de
openssl s_client -connect thawte.com:443spectacles:Ce dernier «i» indique l'autorité de certification racine émettrice auto-signée. Je suppose que cette CA racine Thawte particulière , _i.e. le certificat racine principale CA - G3 n'est pas dans votre
/etc/ssl/certsrépertoire (comme indiqué dans lacurlsortie;openssl s_clientn'a pas de chemin CA par défaut et doit en donner un explicitement, par exemple-CApath /etc/ssl/certs).L'ajout explicite de ce certificat à votre
/etc/ssl/certsrépertoire (et sa réexécutionc_rehash) ne ferait certainement pas de mal. Et si cela fonctionne, par exemple, comme vérifié en utilisantopenssl s_client -connect example.com:443 -CApath /etc/ssl/certs, alors vous savez que cetteupdate-ca-certificatescommande peut nécessiter un examen / débogage, pour savoir pourquoi elle n'a pas récupéré cette autorité de certification racine.Maintenant, il se peut que l'autorité de certification racine ci-dessus se trouve déjà dans votre
/etc/ssl/certsrépertoire et que les étapes ci-dessus n'aient eu aucun effet. Dans ce cas, il y a deux autres certificats de CA émetteurs à vérifier (au moins dans la chaîne de certificats offerte parthawte.com:443): thawte Primary Root CA et thawte SSL CA - G2 . La répétition des étapes ci-dessus pour installer ces certificats dans votre/etc/ssl/certsrépertoire (et réexécuterc_rehash) peut fonctionner. Étant donné que ces deux sont des autorités de certification intermédiaires et non des autorités de certification racine, l'absence de l'une d'entre elles expliquerait vos résultats et pourrait être attendue comme des certificats ignorés parupdate-ca-certificates.J'espère que cela t'aides!
la source
openssl s_client -connect <server>:443 -CAfile cacert.pemcommande est très utile ... merci!Cela peut être dû à un mauvais ordre du site, à l'émission, aux certificats intermédiaires et racine dans le fichier de certificat de clé publique du site.
Le navigateur affiche les certificats dans le sens haut-bas inversé (racine, intermédiaire, émission, site) mais le certificat doit être dans le sens bas-haut (site, émission, intermédiaire, racine).
la source