Puncte:1

curl spune că un certificat valid a expirat

drapel in

Am o ediție comunitară gitlab găzduită pe un server și când folosesc curl pe acest server pentru a prelua acest site web local gitlab, primesc o eroare de certificat expirat chiar dacă datele sunt valide:

curl --insecure -vvI https://gitlab.mysite.com 2>&1 | awk 'BEGIN { cert=0 } /^\* Certificat server:/ { cert=1 } /^\*/ { if (cert) print }'
* Certificat de server:
* subiect: CN=gitlab.mysite.com
* data de începere: 12 noiembrie 14:36:12 2021 GMT
* data expirării: 10 februarie 14:36:11 2022 GMT
* emitent: C=US; O=Let's Encrypt; CN=R3
* Rezultatul verificării certificatului SSL: certificatul a expirat (10), continuând oricum.

Dar nu primesc această eroare de certificat expirat când încarc site-ul dintr-un browser sau când folosesc curl pe alt server. Eroarea apare numai când se folosește curl local, pe serverul care găzduiește instanța gitlab ce.

Acesta este rezultatul când utilizați curl pe alt server:

* Certificat de server:
* subiect: CN=gitlab.mysite.com
* data de începere: 12 noiembrie 14:36:12 2021 GMT
* data expirării: 10 februarie 14:36:11 2022 GMT
* emitent: C=US; O=Let's Encrypt; CN=R3
* Verificare certificat SSL ok.

Este posibil să existe o problemă deoarece curl-ul se rezolvă pe un site web local (ip rezolvat = 127.0.1.1)?

drapel cn
Bob
Problema ar putea fi cu un vechi certificat rădăcină Let's Encrypt, mai degrabă decât cu certificatul de server real. https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
tio oit avatar
drapel in
Am folosit OpenSSL pentru a obține mai multe informații și asta este ceea ce primesc: openssl s_client -showcerts -connect gitlab.mysite.com:443
Raul Benet avatar
drapel ru
@tiooit ce sistem de operare și versiune folosești? Ce versiune de curl? Ce versiune de SSL folosește curl (dacă rulați Linux, puteți afla făcând „sh$ readelf -d `which curl`” și căutați intrarea care conține libssl ]?
Raul Benet avatar
drapel ru
Ne pare rău, formatarea a alterat comanda `readelf` din comentariul de mai sus - să vedem dacă de data aceasta o înțeleg corect ```sh$ readelf -d `which curl` ```
tio oit avatar
drapel in
Serverul rulează un `Debian 9.13`, cu `curl 7.52.1`, dar comanda `readelf` nu afișează date libssl
Raul Benet avatar
drapel ru
Se pare că în Debian 9.3 (și posibil multe altele) `curl` depinde mai întâi de `libcurl`, care la rândul său depinde de `libssl`. De aceea, nu ați primit date libssl la emiterea readelf. Verificând depozitul Debian 9.3, arată că `curl` folosește în cele din urmă OpenSSL 1.0.2d (acest lucru poate fi independent de instalarea pachetului tău `openssl`). Și, prin urmare, sunteți foarte probabil afectat de problema menționată în răspunsul meu.
Raul Benet avatar
drapel ru
De fapt, întrebarea dvs. este probabil o copie a https://serverfault.com/q/1079199/473319 și aș încerca mai întâi să urmăresc răspunsul: https://serverfault.com/a/1080278/473319
tio oit avatar
drapel in
Ai absoluta dreptate! Aplicarea remedierii răspunsului menționat a rezolvat problema, mulțumesc :)
Puncte:3
drapel ru

Am avut acele simptome (funcționează pe browser, eșuează pe Curl) pe mașina mea Ubuntu 16.04, curl 7.47.0.

În cazul meu, problema a fost într-adevăr declanșată de certificatul expirat Let's Encrypt (după cum a menționat Bob), dar creată de fapt de un gândac privind gestionarea OpenSSL a arborilor de certificate cu mai multe căi.

Ubuntu 16.04

Această problemă pe OpenSSL a fost corectată pe versiunea 1.0.2g-1ubuntu4.20 (mai recentă de astăzi) a pachetului pentru Ubuntu 16.04 (vezi jurnalul de modificări Aici).

Dacă sunteți pe Ubuntu 16.04, încercați să actualizați OpenSSL la cea mai recentă. Dacă sunteți pe alt sistem, verificați versiunea dvs. de OpenSSL. Versiunile anterioare versiunii 1.1.x au problema și necesită „patching” (cum se face pentru distribuția Ubuntu menționată mai sus). Dacă nu puteți trece pentru a utiliza o versiune OpenSSL cu o remediere, atunci puteți recurge la dezactivarea certificatului care provoacă problema. Modul de dezactivare a certificatului va varia în funcție de sistemul de operare/distribuție.

Debian 9.3

(răspuns actualizat - odată ce OP a identificat sistemul de operare ca Debian 9.3)
Se pare că pentru Debian 9.3 aceasta ar fi o întrebare duplicat (nu am suficiente privilegii pentru a o marca ca atare).
Clientul de pe Debian 9 raportează în mod eronat certificatul expirat pentru domeniul emis de letsencrypt
Și OP a avut succes în aplicarea acestui răspuns (care este echivalent cu sugestia mea de mai sus pentru Ubuntu 16.04):
https://serverfault.com/a/1080278/473319

Mai multe informatii

Pagina următoare poate oferi mai multe informații de fundal și indicații pentru a înțelege mai bine problema. https://scotthelme.co.uk/lets-encrypt-old-root-expiration/

tio oit avatar
drapel in
Vă mulțumim pentru sugestii. Am verificat versiunea OpenSSL și este 1.1.0l, așa că nu ar trebui să fie afectată de eroarea la care vă referiți. De asemenea, am reînnoit recent certificatul, dar încă nu funcționează când apelez site-ul de pe serverul care îl găzduiește.
Paul avatar
drapel cn
Ubuntu 16.04 este EOL. Vă rugăm să actualizați serverul la o versiune întreținută.
tio oit avatar
drapel in
Pentru toți cei care caută soluția, Raul Benet a dat soluția într-un comentariu la întrebarea mea
Raul Benet avatar
drapel ru
Pentru a fi mai clar, am îmbunătățit răspunsul. @tiooit vă rugăm să-l acceptați din nou, așa că este marcat ca răspuns. Mersi.

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.