Debian에서 SSL 웹 사이트 확인 문제를 해결하는 방법은 무엇입니까?
Aug 19 2020
데비안 노트북에서 웹 사이트에 대한 보안 액세스 문제를 해결하려고합니다. 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를 안내했습니다. 웹 사이트는 이제 잘 작동합니다.
답변
2 garethTheRed Aug 19 2020 at 21:23
귀하의 서버는 하나의 인증서 만 전송하고 있습니다.
그러나 체인의 모든 인증서를 보내야합니다. 추가 지침을 얻으려면 서버 관리자에게 RFC 5246 섹션 7.4.2 를 알려주십시오. 여기서는 단순히 최종 엔터티 인증서가 아니라 체인을 보내야한다고 명시합니다 .
클라이언트가 신뢰 앵커 저장소에 루트 CA 인증서를 가지고있는 한 TLS 핸드 셰이크에서 제공되는 중간 및 최종 엔터티 인증서를 사용하여 체인을 구축합니다.
Windows 클라이언트는 기관 정보 액세스 확장 내의 하위 인증서에 포함 된 URL에서 다운로드하여 체인에서 누락 된 상위 인증서를 자동으로 가져올 수 있습니다. 이것은 잘못 구성된 웹 서버를 종종 숨길 수있는 벨트 및 브레이스 솔루션입니다. Firefox는이를 거부합니다.
1 JaapJorisVens Aug 19 2020 at 21:08
(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 크롬은 Mozilla NSS (네트워크 보안 서비스) 라이브러리를 사용하여 인증서 확인을 수행합니다. 소스에서 패키징되거나 빌드 된 경우 NSS에는 Mozilla Root Certificate Program에 따라 검증 된 인증서가 포함됩니다.
그러나 Epiphany 에는 자체 루트 저장소가 포함되어 있지 않습니다 . 아마도 /etc/ssl/certs대부분의 Linux 배포판 에서 사용 가능한 인증서를 사용합니다 . 내 것을 확인했지만 Sectigo에서 루트 인증서를 찾을 수 없습니다.
$ find /etc/ssl/certs -name *Sectigo* $ No results found.
이 문제를 해결하려면 올바른 인증서를 수동으로 추가하거나 "위험 수락 및 진행"버튼을 클릭해야합니다.)