Estou tentando solucionar problemas de acesso seguro a um site no meu laptop Debian. Quando tento acessar o site no Gnome web (Epiphany), Gnome feeds, urlwatch
, ou openssl
, ele falha. Gnome web declara que o site não pode ser verificado. Veja a saída openssl
abaixo. Mas o Chromium e o Firefox carregam o site sem problemas e declaram que a conexão é segura. Como posso verificar se é um bug no meu sistema, que eu poderia corrigir, ou uma configuração incorreta no site, que o Chromium e o Firefox apenas resolvem de alguma forma?
$ 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
Editar :
Considerando as respostas, decidi verificar se a validação SSL seria bem-sucedida se o servidor fornecesse a cadeia. A partir das informações sobre o site no Firefox, salvei localmente o certificado intermediário, que o Firefox usou para o site. Com ele, executei com sucesso openssl verify
o certificado do servidor. Concluo que meu sistema possui o certificado raiz necessário. O Firefox provavelmente usa como solução alternativa o certificado intermediário que ele armazenou em cache de um uso anterior em outro lugar.
$ 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
Como observação, descobri que posso usar ssl_no_verify: true
na urlwatch
configuração do trabalho para ignorar a verificação.
Atualização :
Enviei um e-mail para a linha de feedback do site e os indiquei para RFC, conforme sugerido na resposta. O site funciona bem agora.
Seu servidor está enviando apenas um certificado - aquele emitido para ele.
No entanto, ele deve enviar todos os certificados da cadeia. Para obter mais orientações, indique aos administradores do servidor a RFC 5246 Seção 7.4.2 , onde afirma especificamente que a cadeia deve ser enviada e não simplesmente o certificado da entidade final.
Contanto que seu cliente tenha o certificado da CA raiz em seu armazenamento de âncora de confiança, ele criará a cadeia usando os certificados intermediários e de entidade final fornecidos no handshake TLS.
Observe que os clientes Windows podem buscar automaticamente os certificados pai ausentes da cadeia, baixando-os de uma URL incorporada no certificado subordinado na extensão de acesso às informações da autoridade. Esta é uma solução de cinto e chaves que muitas vezes pode esconder servidores web mal configurados. O Firefox se recusa a fazer isso.
A razão pela qual (www.)fg.gov.ua está funcionando no Chromium e no Firefox, mas não no Epiphany, é que o certificado do emissor (
Sectigo RSA Organization Validation Secure Server CA
) é confiável para os dois primeiros e não para o último.Surpreendentemente, no Linux, tanto o Chromium quanto o Firefox usam o armazenamento raiz do Mozilla. De https://www.chromium.org/Home/chromium-security/root-ca-policy :
O Epiphany, no entanto, não inclui seu próprio armazenamento raiz . Presumivelmente, ele usa os certificados
/etc/ssl/certs
disponíveis na maioria das distribuições do Linux. Eu verifiquei o meu, mas não consegui encontrar nenhum certificado raiz do Sectigo:Para resolver esse problema, você precisará adicionar manualmente o certificado correto ou clicar no botão "Aceitar risco e prosseguir" ;)