Puncte:2

Cum se remediază lanțul de certificate cu letsencrypt / certbot?

drapel cn

Nu pot să-mi înțeleg următoarea problemă. Verificarea certificatelor serverului cu openssl eșuează, lanțul este incomplet.

Disclaimer: nu sunt administrator și nu am lucrat prea mult cu certificatele încă.

Verificați cu OpenSSL

$ openssl verifica -CAfile /etc/letsencrypt/live/co2-avatar.com/fullchain.pem /etc/letsencrypt/live/co2-avatar.com/cert.pem

# /etc/letsencrypt/live/co2-avatar.com/cert.pem: C = SUA, O = Internet Security Research Group, CN = ISRG Root X1
# eroare 2 la căutarea 2 profunzime: nu se poate obține certificatul emitentului

Verificați unul dintre domeniile din certificat

openssl s_client -connect co2avatar.org:443 -servername co2avatar.org
# CONECTAT(00000003)
# adâncime=0 CN = gitlab.sustainable-data-platform.org
# verify error:num=20:nu se poate obține certificatul de emitent local
# verificați returnarea:1
# adâncime=0 CN = gitlab.sustainable-data-platform.org
# verify error:num=21:nu se poate verifica primul certificat
# verificați returnarea:1
# ---
# Lanț de certificate
# 0 s:CN = gitlab.sustainable-data-platform.org
# i:C = US, O = Let's Encrypt, CN = R3
# ---
# Certificat de server
# -----ÎNCEPE CERTIFICAT-----

Sau fugi

curl -v https://co2avatar.org
# * Se încearcă 85.214.38.88:443...
# * TCP_NODELAY setat
# * Conectat la co2avatar.org (85.214.38.88) portul 443 (#0)
# * ALPN, oferind h2
# * ALPN, oferind http/1.1
# * a setat cu succes locațiile de verificare a certificatelor:
# * CAfile: /etc/ssl/certs/ca-certificates.crt
# CApath: /etc/ssl/certs
# * TLSv1.3 (OUT), TLS handshake, Client salut (1):
# * TLSv1.3 (IN), strângere de mână TLS, salut server (2):
# * TLSv1.2 (IN), strângere de mână TLS, Certificat (11):
# * TLSv1.2 (OUT), alertă TLS, CA necunoscută (560):
# * Problemă cu certificatul SSL: nu se poate obține certificatul emitentului local
# * Închiderea conexiunii 0
# curl: (60) Problemă cu certificatul SSL: nu se poate obține certificatul emitentului local

Ar putea exista ambele, o configurație greșită în Apache VHost pentru domeniu, precum și o problemă în lanțul de certificate în sine. Cum îl pot verifica pe ultimul (am căutat mult pe google, dar majoritatea accesărilor sunt despre verifica openssl cu -CAfile sau despre alt emitent de certificat)?

Trebuie să verific pachet de certificate de rădăcină si cum mai exact?

Există ceva asemănător unui -adaugă încredere steag pentru certbot certnly?

Puncte:6
drapel in

Încercați openssl s_client și vă permiteți să afișați certificatele. Comanda este:

$ openssl s_client -connect co2avatar.org:443 -servername co2avatar.org -showcerts

Veți descoperi că serverul dvs. returnează un certificat pentru CN = gitlab.sustainable-data-platform.org și un nume alternativ al subiectului care include domeniul dvs DNS:co2-avatar.com. Deci certificatul în sine este în regulă.

Dacă doriți să combinați totul într-o singură conductă de comenzi pentru a vedea conținutul certificatului dvs.:

ecou | openssl s_client -connect co2avatar.org:443 -servername co2avatar.org -showcerts 2>/dev/null |sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -text

Ceea ce lipsește este certificatul intermediar. Acesta ar trebui să fie trimis și de server, dar prima comandă vă arată că nu este acolo - doar certificatul este trimis de serverul dvs.

Deci, openssl eșuat este corect, deoarece, într-adevăr, certificatul intermediar lipsește.

Deci, pentru a o rezolva, trebuie să vă modificați configurația Apache. Iată cum ar putea arăta configurația dvs.:

Numele fișierului ar trebui să fie similar cu /etc/apache2/sites-enabled/co2-avatar.com-le-ssl.conf

<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000)
<VirtualHost *:443>
        ServerName co2-avatar.com
        ServerAlias www.co2-avatar.com
#... 
#... insert your other stuff here...
#...

SSLCertificateFile /etc/letsencrypt/live/co2-avatar.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/co2-avatar.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLUseStapling on
</VirtualHost>
</IfModule>

Pe baza descrierii dvs., cea mai bună presupunere este că următoarea linie este greșită în configurația dvs.: SSLCertificateFile /etc/letsencrypt/live/co2-avatar.com/cert.pem. Ar trebui inlocuit cu SSLCertificateFile /etc/letsencrypt/live/co2-avatar.com/fullchain.pem, pentru a trimite și intermediarul(i).

UPDATE soluție (după discuție)

În discuție s-a dovedit că versiunea openssl și Apache utilizate pe acest server CentOS este doar mai veche, așa că unele funcții nu sunt acceptate. (Apache 2.4.6, OpenSSL 1.0.2k, configurație intermediară, fără HSTS, fără OCSP)

Conform Mozilla SSL Configuration Generator următoarea configurație generică ar putea fi utilizată în acest caz:

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      /path/to/signed_certificate
    SSLCertificateChainFile /path/to/intermediate_certificate
    SSLCertificateKeyFile   /path/to/private_key
</VirtualHost>

Tradusă în acest caz specific, o configurație de lucru rezultată ar fi următoarea:

<VirtualHost *:443>
    ServerName  sustainable-data-platform.org
    ServerAlias co2-avatar.com
    ServerAlias ... <include all other SAN names here>
    
    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/co2-avatar.com/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/co2-avatar.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/co2-avatar.com/privkey.pem

</VirtualHost>

Ca notă pentru astfel de instalații vechi

Cross-Signed Letâs Encrypt R3 și DST Root CA X3, certificatele intermediare și rădăcină vor expira pe 29 septembrie 2021 și, respectiv, pe 30 septembrie 2021. Deci, din 4 mai 2021, certificatele nou emise folosesc un lanț mai lung cu ISRG Root X1 cu semnătură încrucișată ca certificat intermediar.

Din păcate, datorită modului în care sunt construite și verificate căile certificatelor, nu toate implementările TLS pot verifica cu succes semnul încrucișat. Acesta este cazul OpenSSL 1.0.2. Prin urmare, programele care rulează pe RHEL/CentOS 7 care utilizează OpenSSL probabil nu vor reuși să verifice noul lanț de certificate sau să stabilească conexiunea TLS. Actualizarea la versiuni mai noi Openssl pe astfel de platforme nu este simplă.

Există câteva opțiuni: fie actualizați depozitul de încredere (eliminați certificatul rădăcină DST Root CA X3 - odată ce este eliminat, impactul ar trebui să fie minim) pe partea clientului (sau) schimbați lanțul de certificate pe partea serverului.

Pentru Nginx

Pentru Nginx există un singur parametru pentru a specifica fișierul cert. Ar trebui să utilizați fullchain.pem furnizate de certbot pentru ca acesta să funcționeze corect.

Configurația corectă în blocul serverului pentru gazda virtuală dată ar fi următoarea:

Server {
  ...
  ssl_certificate /etc/letsencrypt/live/co2-avatar.com/fullchain.pem; -> a înlocuit cert.pem pentru fullchain.pem
  ssl_certificate_key /etc/letsencrypt/live/co2-avatar.com/privkey.pem;
}

Referințe

BairDev avatar
drapel cn
Mulțumiri! Folosesc deja fișierul *fullchain*, exact ca `SSLCertificateFile /etc/letsencrypt/live/co2-avatar.com/fullchain.pem`. Deci certificatul intermediar nu este cumva prezent, ceea ce ar putea explica eșecul `openssl verify -CAfile .../fullchain.pem .../cert.pem`. Cum vedeți asta: *Ce lipsește certificatul intermediar*? Presupun că trebuie să repar certificatul (certificatele). Vreun indiciu pentru asta?
drapel in
Răspundeți la a doua întrebare: Comanda `openssl s_client ... -showcerts` vă arată **toate** certificatele trimise de un server. În cazul dvs.: Faptul că este returnat un singur certificat arată că intermediarul(ele) lipsesc. Puteți vedea cel mai bine dacă îl comparați cu rezultatul în cazul în care utilizați alt domeniu. Exemplu de comparat cu: `eco | openssl s_client -connect belug.de:443 -servername belug.de -showcerts` Verificați dacă toate certificatele așteptate sunt incluse în fișierul dvs. `fullchain.pem`. (se așteaptă să vedeți mai mult de un certificat acolo)
drapel in
Pentru a răspunde la prima întrebare: Având în vedere că certificatul(ele) intermediar(e) prezent(e) în fișierul `fullchain.pem` **și** configurat în vhost, dar **nu** livrat de serverul dvs., indică puternic că un alt fișier vhost este folosit. Verificați celelalte fișiere de configurare Apache - aș paria că configurația vhost se suprapune.
BairDev avatar
drapel cn
Bine, acum toate directivele SSLCertificateFile din fișierele mele conf indică la *fullchain.pem*. Dar al doilea certificat exact în acest fișier nu este livrat. Pentru ce este directiva SSLCertificateChainFile (este depreciată, nu)? O altă configurație pare să blocheze fișierul fullchain.pem. (da, am repornit apache / httpd)
BairDev avatar
drapel cn
S-a dovedit că versiunea Apache este prea scăzută/veche (

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.