Come risolvere i problemi di verifica del sito Web SSL su Debian?
Sto cercando di risolvere i problemi di accesso sicuro a un sito Web sul mio laptop Debian. Quando provo ad accedere al sito in Gnome web (Epiphany), Gnome alimenta urlwatch, o openssl, fallisce. Gnome web dichiara che il sito Web non può essere verificato. Vedere l'output di opensslseguito. Ma Chromium e Firefox caricano il sito senza problemi e dichiarano che la connessione è sicura. Come posso verificare se si tratta di un bug nel mio sistema, che potrei correggere, o di una configurazione errata sul sito Web, che Chromium e Firefox risolvono in qualche modo?
$ openssl s_client -connect fg.gov.ua:443
CONNECTED(00000003)
depth=0 C = UA, postalCode = 04053, L = Kyiv, street = vul.Sichovykh Striltsiv 17, O = "Deposit Guarantee Fund, State Organisation", OU = IT, CN = *.fg.gov.ua
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = UA, postalCode = 04053, L = Kyiv, street = vul.Sichovykh Striltsiv 17, O = "Deposit Guarantee Fund, State Organisation", OU = IT, CN = *.fg.gov.ua
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:C = UA, postalCode = 04053, L = Kyiv, street = vul.Sichovykh Striltsiv 17, O = "Deposit Guarantee Fund, State Organisation", OU = IT, CN = *.fg.gov.ua
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHJjCCBg6gAwIBAgIQdMlRgieLFotpxhGUZykkijANBgkqhkiG9w0BAQsFADCB
lTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT0wOwYDVQQD
EzRTZWN0aWdvIFJTQSBPcmdhbml6YXRpb24gVmFsaWRhdGlvbiBTZWN1cmUgU2Vy
dmVyIENBMB4XDTIwMDcxNzAwMDAwMFoXDTIxMTAxNTIzNTk1OVowgakxCzAJBgNV
BAYTAlVBMQ4wDAYDVQQREwUwNDA1MzENMAsGA1UEBxMES3lpdjEjMCEGA1UECRMa
dnVsLlNpY2hvdnlraCBTdHJpbHRzaXYgMTcxMzAxBgNVBAoTKkRlcG9zaXQgR3Vh
cmFudGVlIEZ1bmQsIFN0YXRlIE9yZ2FuaXNhdGlvbjELMAkGA1UECxMCSVQxFDAS
BgNVBAMMCyouZmcuZ292LnVhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAtIRBuOW3b3qcA8TJOrl6MIwpDHvNBlLMaqDR8CMJtmIiUZJ+og789eTVbJlc
VbjUjOrRXx+3sIVyYeF4tJWnaEzbhDpSzfzvufr0jFphkDWdYu2gzrKbXjQUUmz2
fzcimEqXC1r/rkUspCMdfk6fXscYMgWfP8Wq9ItMYYdlVrQM5W+T2hC3a3gcw2vM
pr/hg1WIph99ZrazZsE9o8ROLR7GHip9Lua7IfJkyjylFr6IIwnM2N8ave9QeoId
agL20KOeWTVnIm5Iqoa9l4C/45u8m/AJsk4FpWyNlMDnZLcNsJbJD/Arrm+z11BD
uf6cpodB0SI4wgaMYlFWblf5cQIDAQABo4IDWjCCA1YwHwYDVR0jBBgwFoAUF9nW
JSdn+THCSUPZMDZEjGypT+swHQYDVR0OBBYEFJh20/maGIe5ZDHiejh3rT8JxzI7
MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjBKBgNVHSAEQzBBMDUGDCsGAQQBsjEBAgEDBDAlMCMGCCsG
AQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgIwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBT3Jn
YW5pemF0aW9uVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNybDCBigYIKwYBBQUH
AQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp
Z29SU0FPcmdhbml6YXRpb25WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3J0MCMG
CCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYggsq
LmZnLmdvdi51YYIJZmcuZ292LnVhMIIBfQYKKwYBBAHWeQIEAgSCAW0EggFpAWcA
dQB9PvL4j/+IVWgkwsDKnlKJeSvFDngJfy5ql2iZfiLw1wAAAXNceArmAAAEAwBG
MEQCID6Q5XEksvVz0ljVMfog/BqFK5o01JsVQW2UpFnrj1lzAiAawR6Km293kJ3h
Eh4Su+lnonBz3+cLD/CzFC1cXQLhXQB2AJQgvB6O1Y1siHMfgosiLA3R2k1ebE+U
PWHbTi9YTaLCAAABc1x4Cw0AAAQDAEcwRQIhAP7aecTO1S57pSnARdR7wLYF0zUm
/FZgGvBLR4/bs8yiAiBM+A0miPcT2B1qY3hwA83LyqbTZOEUmb21K/0B4z0XGwB2
AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABc1x4Ct8AAAQDAEcw
RQIgNJzEpbzBvpaXv5AxmjAhcblO1FStCDPUbHxLav5ZzvMCIQDA/3R3G2/i9jD3
vkbhLjIxYmynL/lStRBdshvQV/r0ozANBgkqhkiG9w0BAQsFAAOCAQEAGLxGWkZf
Jz8y1RIMewDTJdW3OWhs0tYpWkdbVyYNUZN2e5Pgn5dmPJDgcF3AE+anNoCgohf3
aV+7x4JMUius/QLu/GH1cSz+to+DvHqE/N8w9oOZOwvAhAkVfTOpyHtDWVVhRWGH
UMtWcl9Jr9JTYk8nDPPSbmLqm7Rc86ZdWcMRwNpgiNVxs0oiR1A2qas3fHHlo01w
sg611jaKHY1Y84IUiDArEhhONJXxYYYSaTnwFAO3gBAq9loPmobnf4WXc51hWsCY
FID/isAye93MZT+ld8/o7sC8p6ImqxjJpwsQP/y2urnoalUoLy0Qg74FQmWEDVsa
UrtX7cbo45eOog==
-----END CERTIFICATE-----
subject=C = UA, postalCode = 04053, L = Kyiv, street = vul.Sichovykh Striltsiv 17, O = "Deposit Guarantee Fund, State Organisation", OU = IT, CN = *.fg.gov.ua
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2390 bytes and written 381 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: D05774AA93DE22018DD221D4D56BBA7AC8B2C15ED3BE7BC7C75396FCB75F6FA4
Session-ID-ctx:
Resumption PSK: EA673D1A4985E74D6CA74F5105FF311757CF08251515A0C3F92A39362B66C22CD264B61F87F09EAD2DD3355FEA948503
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 09 64 75 0e e1 89 54 b2-b8 43 89 59 36 88 88 cc .du...T..C.Y6...
0010 - 18 50 a2 ef 53 9c d8 f7-8f b2 fa e9 89 a5 73 34 .P..S.........s4
0020 - 07 4b 64 dc 14 d4 dc e4-be 29 c4 a4 99 b8 da 15 .Kd......)......
0030 - d1 09 c4 6b fc d0 61 c0-59 5e d8 e7 0a 40 31 ca ...k..a.Y^...@1.
0040 - 42 2d 00 9b ae fd e3 b1-50 5e 08 04 46 2c a7 b7 B-......P^..F,..
0050 - 3b 8a 61 28 c1 23 37 5a-05 23 14 d3 45 91 40 d5 ;.a(.#7Z.#..E.@.
0060 - b9 ae 3d 3c 6b 61 1b 5f-5e 7a 05 1a b9 10 ab 61 ..=<ka._^z.....a
0070 - 09 b9 08 6c ab 5e 3b f7-15 7a 98 d5 91 b1 7c 7e ...l.^;..z....|~
0080 - a8 45 51 e3 74 24 35 40-ba 7c b8 e5 35 8e a4 22 .EQ.t$5@.|..5.."
0090 - d4 47 63 59 d2 e2 c7 8b-d2 35 46 27 dc 2f 13 51 .GcY.....5F'./.Q
00a0 - 6b 8f bf ba 16 0b 18 ae-e2 f0 e9 df 5a 79 56 a1 k...........ZyV.
00b0 - 76 8d 4c 66 ef 16 07 fd-91 b5 5a f7 87 93 e6 b0 v.Lf......Z.....
00c0 - ed e5 22 2b 26 9e 70 aa-39 4b 4c c0 c9 ff fc 83 .."+&.p.9KL.....
00d0 - 22 f8 5c 4f 3c 91 04 c3-88 65 2a ec 6b 78 d0 16 ".\O<....e*.kx..
Start Time: 1597841026
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 75A45FF3AAA8E24217131F365A8953BEA5FF6D2666A858ECF56F7219F33115DA
Session-ID-ctx:
Resumption PSK: 043BB4F8848D3F069467B3638A887DE50B10A697BDA8D9A18180CC82ACF0D72C67B527AD8ADFC9BAD1DDF08E7C83808F
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 09 64 75 0e e1 89 54 b2-b8 43 89 59 36 88 88 cc .du...T..C.Y6...
0010 - c7 09 c9 47 b4 46 29 74-cb ff f6 a1 25 09 73 78 ...G.F)t....%.sx
0020 - 84 1e 40 a7 40 61 19 39-58 ec 4b 34 20 c9 e7 3f ..@[email protected] ..?
0030 - b7 21 1a 30 a7 cb ad c3-e4 53 dd f9 74 b6 4b 08 .!.0.....S..t.K.
0040 - c9 7f 11 26 a0 77 3f f1-9a ff 58 2a f0 1f aa f9 ...&.w?...X*....
0050 - 12 52 06 c9 08 25 9c 16-4e f2 f7 43 64 f2 3b 4d .R...%..N..Cd.;M
0060 - b1 dc c7 62 94 ce c8 91-1e 66 cb 0d 11 aa 37 3e ...b.....f....7>
0070 - 2a 63 14 ad 2d 00 bf 29-09 53 35 fd 33 52 98 5f *c..-..).S5.3R._
0080 - 82 5b fd 01 b1 bd 8c 22-81 76 d7 26 32 e7 0e e7 .[.....".v.&2...
0090 - 9e bd a4 56 bc da 96 75-08 ce e3 76 9c 2d 6a b2 ...V...u...v.-j.
00a0 - 81 02 70 74 5d e4 92 1a-94 ed 9e db c5 40 68 ff ..pt]........@h.
00b0 - 07 f3 f5 69 b5 cb 3b 88-20 7c 17 61 7c 72 be 95 ...i..;. |.a|r..
00c0 - b9 d1 01 4e 6c 96 b0 4c-a0 30 e1 ae 7f 88 27 81 ...Nl..L.0....'.
00d0 - 44 1c 7b 7f 23 d8 bc 57-21 df 92 8a af 49 d9 e6 D.{.#..W!....I..
Start Time: 1597841026
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
closed
Modifica :
Considerando le risposte, ho deciso di verificare se la convalida SSL avrebbe avuto successo se il server avesse fornito la catena. Dalle informazioni sul sito Web in Firefox, ho salvato localmente il certificato intermedio, utilizzato da Firefox per il sito Web. Con esso, ho eseguito correttamente openssl verifyil certificato del server. Concludo che il mio sistema dispone del certificato radice necessario. Firefox probabilmente utilizza come soluzione alternativa il certificato intermedio che ha memorizzato nella cache da un uso precedente da qualche altra parte.
$ openssl verify -show_chain -untrusted intermediate.pem server.pem
server.pem: OK
Chain:
depth=0: C = UA, postalCode = 04053, L = Kyiv, street = vul.Sichovykh Striltsiv 17, O = "Deposit Guarantee Fund, State Organisation", OU = IT, CN = *.fg.gov.ua (untrusted)
depth=1: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Organization Validation Secure Server CA (untrusted)
depth=2: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
Come nota a margine, ho scoperto che posso utilizzare ssl_no_verify: truenella urlwatchconfigurazione del lavoro per saltare la verifica.
Aggiorna :
Ho inviato un'e-mail alla riga di feedback del sito Web e li ho indirizzati a RFC come suggerito nella risposta. Il sito ora funziona bene.
Risposte
Il tuo server sta inviando solo un certificato, quello che gli è stato rilasciato.
Tuttavia, dovrebbe inviare tutti i certificati della catena. Per ulteriori indicazioni, indirizza gli amministratori del server alla sezione 7.4.2 RFC 5246, dove si afferma specificamente che la catena deve essere inviata e non semplicemente il certificato dell'entità finale.
Finché il tuo client ha il certificato CA radice nel suo archivio di ancoraggio sicuro, costruirà la catena, utilizzando i certificati di entità intermedia e finale forniti nell'handshake TLS.
Si noti che i client Windows possono recuperare automaticamente i certificati padre mancanti dalla catena scaricandoli da un URL incorporato nel certificato subordinato all'interno dell'estensione Authority Information Access. Si tratta di una soluzione a cinghia e bretelle che spesso può nascondere server Web mal configurati. Firefox si rifiuta di farlo però.
Il motivo per cui (www.)fg.gov.ua funziona in Chromium e Firefox, ma non in Epiphany, è che il certificato dell'emittente ( Sectigo RSA Organization Validation Secure Server CA) è considerato attendibile dai primi due e non dal secondo.
Sorprendentemente, su Linux, sia Chromium che Firefox utilizzano il root store di Mozilla. Dahttps://www.chromium.org/Home/chromium-security/root-ca-policy:
Quando viene eseguito su Linux, Google Chrome utilizza la libreria Mozilla Network Security Services (NSS) per eseguire la verifica del certificato. Quando è impacchettato o compilato dal sorgente, NSS include certificati verificati secondo il Mozilla Root Certificate Program.
Epiphany, tuttavia, non include il proprio root store . Presumibilmente utilizza i certificati sotto /etc/ssl/certsdisponibili sulla maggior parte delle distribuzioni Linux. Ho controllato il mio, ma non sono riuscito a trovare alcun certificato radice da Sectigo:
$ find /etc/ssl/certs -name *Sectigo*
$ No results found.
Per risolvere questo problema, dovrai aggiungere manualmente il certificato corretto o fare clic sul pulsante "Accetta il rischio e procedi" ;)