Как устранить проблемы с проверкой веб-сайта SSL в Debian?
Я пытаюсь устранить неполадки с безопасным доступом к веб-сайту на своем ноутбуке Debian. Когда я пытаюсь получить доступ к сайту в сети Gnome (Epiphany), Gnome подает urlwatch
, или openssl
, это не удается. Gnome web заявляет, что веб-сайт не может быть проверен. См. Вывод openssl
ниже. Но Chromium и Firefox загружают сайт без каких-либо проблем и заявляют, что соединение является безопасным. Как я могу проверить, является ли это ошибкой в моей системе, которую я мог бы исправить, или неправильной конфигурацией на веб-сайте, которую Chromium и Firefox просто как-то обходят?
$ 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
Редактировать :
Обдумывая ответы, я решил проверить, будет ли проверка SSL успешной, если сервер предоставит цепочку. Из информации о веб-сайте в Firefox я сохранил локально промежуточный сертификат, который Firefox использовал для веб-сайта. С его помощью я успешно запустил openssl verify
сертификат сервера. Я прихожу к выводу, что в моей системе есть необходимый корневой сертификат. Firefox, вероятно, использует в качестве обходного пути промежуточный сертификат, который он кэшировал от предыдущего использования в другом месте.
$ 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
В качестве примечания я обнаружил, что могу использовать ssl_no_verify: true
в urlwatch
конфигурации задания, чтобы пропустить проверку.
Обновление :
Я отправил по электронной почте линию обратной связи веб-сайта и указал им на RFC, как было предложено в ответе. Сайт сейчас работает нормально.
Ответы
Ваш сервер отправляет только один сертификат - выданный ему.
Однако он должен отправлять все сертификаты в цепочке. Для получения дополнительных указаний направьте администраторам вашего сервера на раздел 7.4.2 RFC 5246, где конкретно указано, что следует отправлять цепочку , а не просто сертификат конечного объекта.
Пока ваш клиент имеет сертификат корневого ЦС в хранилище доверенных якорей, он будет строить цепочку, используя сертификаты промежуточных и конечных объектов, предоставленные в подтверждении TLS.
Обратите внимание, что клиенты Windows могут автоматически извлекать отсутствующие родительские сертификаты из цепочки, загружая их с URL-адреса, встроенного в подчиненный сертификат в расширении доступа к информации о полномочиях. Это простое решение, которое часто может скрывать плохо настроенные веб-серверы. Однако Firefox отказывается это делать.
Причина, по которой (www.) Fg.gov.ua работает в Chromium и Firefox, но не в Epiphany, заключается в том, что сертификату эмитента ( Sectigo RSA Organization Validation Secure Server CA
) доверяют первые два, а не последний.
Удивительно, но в Linux и Chromium, и Firefox используют корневое хранилище Mozilla. Отhttps://www.chromium.org/Home/chromium-security/root-ca-policy :
При работе в Linux Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для проверки сертификата. Будучи упакованным или собранным из исходного кода, NSS включает сертификаты, проверенные в соответствии с программой корневых сертификатов Mozilla.
Однако Epiphany не имеет собственного корневого хранилища . Предположительно, он использует сертификаты, /etc/ssl/certs
доступные в большинстве дистрибутивов Linux. Я проверил свой, но не нашел ни одного корневого сертификата от Sectigo:
$ find /etc/ssl/certs -name *Sectigo* $ No results found.
Чтобы решить эту проблему, вам нужно либо вручную добавить правильный сертификат, либо нажать кнопку с надписью «Принять риск и продолжить»;)