Î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