înregistrare Logare
Puncte:0
Timothy Fisher avatar Server

Curl eroare „emitentul certificatului peer nu este recunoscut” atunci când încercați să comunicați între două servere

drapel ca
Timothy Fisher

Am două servere A și B care găzduiesc site-uri web care funcționează bine într-un browser cu https. Pictograma de lacăt din browsere arată certificate SSL active și de încredere.

Încerc să rulez curl astfel încât acel server A pot vorbi cu serverul B, dar ma confrunt cu o eroare.

- Server A -
$ curl https://dev.partsvu.com
CAfile: /etc/pki/tls/certs/ca-bundle.crt
curl: (60) Emitentul certificatului Peer nu este recunoscut.

Am făcut câteva cercetări în jurul site-urilor Stack Overflow și am întâlnit multe întrebări, cu toate acestea, soluțiile lor nu au funcționat pentru mine.

Am încercat mai întâi să descarc fișierele certificatelor pentru server B dintr-un raport SSL Labs și a adăugat manual lista de certificate la /etc/pki/tls/certs/ca-bundle.crt fișier pe server A dar inca primesc aceeasi eroare.

De asemenea, m-am asigurat că serverul B certificatul este valabil cu următoarele:

- Server B -
openssl x509 -dates -noout < /etc/pki/tls/certs/cloudflare.pem
notBefore=6 mai 21:25:00 2022 GMT
notAfter=2 mai 21:25:00 2037 GMT

De asemenea, am încercat să copiez conținutul /etc/pki/tls/certs/cloudflare.pem pe server B direct la /etc/pki/tls/certs/ca-bundle.crt pe server A dar aceeasi eroare.

În cele din urmă, am încercat să vizitez serverul B în Chrome și a descărcat fișierul crt la care apare https://cacerts.digicert.com/CloudflareIncECCCA-3.crt, l-a convertit în pem cu:

openssl x509 -inform DES -in CloudflareIncECCCA-3.crt -out outcert.pem

și a adăugat asta la același lucru ca-bundle.crt fișier pe server A.

Aceeași eroare când încercați să rulați curl.

Iată lanțul de certificări de la Chrome:

introduceți descrierea imaginii aici

26
0 + 0
Binky avatar
drapel de
Binky
Comanda `$ curl https://.com` este problematic. Este „adresa serverului B” o adresă IP sau eticheta(e) DNS de sub „.com”? Vă rugăm să postați comanda reală și eroarea. Dacă aceasta este o adresă IP, comanda eșuează, deoarece serverul are nevoie de informații despre ce certificat să trimită, pe baza porțiunii de URL care este prezentă după schemă ("https://") și înainte de începutul căii (" /"). Cert identitățile sunt în mod normal nume DNS, nu adrese IP. Vă rugăm să postați certificatul serverului B în formă PEM, cu o captură de ecran a lanțului de certificate afișată de un browser când navigați pe serverul B.
0
Răspunde
Binky avatar
drapel de
Binky
De asemenea, când spuneți „M-am asigurat și că certificatul serverului B este valid...”, datele de valabilitate arată că acesta nu este certificatul serverului, cu excepția cazului în care ați emis certificatul de la o PKI privată, în loc să utilizați o autoritate de certificare publică. Certificatele de server de la un CA public nu pot fi valabile mai mult de puțin peste un an. Deci fie aveți 1) certificatul greșit în acel fișier, fie 2) certificate multiple, iar datele notBefore/After aparțin probabil unui certificat rădăcină.
0
Răspunde
dave_thompson_085 avatar
drapel jp
dave_thompson_085
Faceți `curl -V` (majuscule) pentru a afla ce middleware folosește curl dvs.; probabil veți găsi că este NSS (NU OpenSSL), ceea ce înseamnă că NU folosește /etc/pki/tls/certs/ca-bundle.crt (_or_ ca-bundle.trust.crt). De aceea, RH/CentOS/etc are `update-ca-trust` pentru a _corect_ actualiza mai multe truststores, mai degrabă decât ca utilizatorii ignoranți să încerce să o facă manual. De asemenea, rețineți că funcționarea browserului nu este dovada că serverul dvs. este în regulă, deoarece browserul poate rezolva, de obicei, certificatele de lanț lipsă, în timp ce `curl` de obicei nu poate, dar dacă ați avea această problemă SSLLabs ar fi spus așa.
1
Răspunde
Timothy Fisher avatar
drapel ca
Timothy Fisher
@Binky Am actualizat cu comanda cu numele de domeniu real și, de asemenea, captura de ecran a lanțului de certificare. Și da, ai dreptate că certificatul pentru datele de expirare este un certificat rădăcină, nu cel care apare în browser. Folosim Cloudflare. Există un certificat de margine în Cloudflare și apoi un altul care este utilizat de HAProxy pentru a lega portul 443.
0
Răspunde
drapel in
Gerald Schneider
Ce versiune de CentOS folosești? Sunt pachetele instalate la zi?
0
Răspunde
Timothy Fisher avatar
drapel ca
Timothy Fisher
@dave_thompson_085 Cred că ai dreptate pe NSS.când îl rulez cu `-V` primesc `curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.53.1 zlib/1.2.7 libidn/1.28 libssh2/1.8.0`, iar rularea `-v` arată `* Inițializarea NSS cu certpath: sql:/etc/pki/nssdb`
1
Răspunde
Timothy Fisher avatar
drapel ca
Timothy Fisher
@GeraldSchneider CentOS Linux lansare 7.9.2009 (Core). M-am asigurat că pachetul ca-certificates este actualizat.
0
Răspunde
drapel in
Gerald Schneider
Pe un stoc CentOS 7.9 mă pot conecta la `https://dev.partsvu.com` cu curl fără probleme.
0
Răspunde
Timothy Fisher avatar
drapel ca
Timothy Fisher
@GeraldSchneider Am putut și atunci când folosesc curl pe mașina mea locală. Dar, când încerc de pe un anumit server, primesc eroarea nerecunoscută. Mă întreb de unde pot începe depanarea asta.
0
Răspunde
drapel in
Gerald Schneider
Ați încercat doar să rulați „yum reinstall ca-certificates”?
0
Răspunde
Timothy Fisher avatar
drapel ca
Timothy Fisher
Da, am rulat asta și am urmat asta pentru a încerca să readuc lucrurile la o stare implicită: https://access.redhat.com/solutions/1549003
0
Răspunde
drapel in
Gerald Schneider
Ei bine, asta este destul de inutil. Fără să ai vreo modalitate de a ști ce ai făcut de fapt și ce stare este sistemul tău, nu există cu adevărat o modalitate de a te ajuta. Dacă serverul meu ar fi în această stare, l-aș reinstala.
0
Răspunde
Binky avatar
drapel de
Binky
@TimothyFisher Puteți posta rezultatul comenzilor: 1) sudo ls -l /etc/pki/nssdb și 2) sudo certutil -L -d sql:/etc/pki/nssdb? Acesta din urmă poate avea o mulțime de rezultate; dacă da, trimiteți rezultatul către grep și căutați „Baltimore CyberTrust Root”.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.