4

I am trying to troubleshoot secure access to a website on my Debian laptop. When I try to access the site in Gnome web (Epiphany), Gnome feeds, urlwatch, or openssl, it fails. Gnome web declares that the website cannot be verified. See the output of openssl below. But Chromium and Firefox load the site without any issues and declare that the connection is secure. How can I check whether it is a bug in my system, which I could fix, or a misconfiguration on the website, which Chromium and Firefox just work-around somehow?

$ 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   ..@.@a.9X.K4 ..?
    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

Edit:

Considering the answers, I decided to check whether SSL validation would succeed if the server provided the chain. From information about the website in Firefox, I saved locally the intermediate certificate, which Firefox used for the website. With it, I successfully ran openssl verify on the server certificate. I conclude that my system has the necessary root certificate in place. Firefox probably uses as a work-around the intermediate certificate which it cached from a previous use somewhere else.

$ 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

As a side note, I found that I can use ssl_no_verify: true in urlwatch job configuration to skip verification.

Update:

I emailed the website's feedback line and pointed them to RFC as suggested in the answer. The website works fine now.

2
  • When I tried visiting the website, it redirected me to www.fg.gov.ua, whose certificate is valid. Aug 19, 2020 at 13:36
  • @hedgie www.fg.gov.ua gives me the same errors. Aug 19, 2020 at 13:39

2 Answers 2

2

Your server is only sending one certificate - the one issued to it.

However, it should be sending all the certificates in the chain. For further guidance, point your server admins to RFC 5246 Section 7.4.2 where it specifically states that the chain should be sent and not simply the end-entity certificate.

As long as your client has the Root CA certificate in its trust-anchor store it will build the chain, using the intermediate and end-entity certificates provided in the TLS handshake.

Note that Windows clients can automatically fetch missing parent certificates from the chain by downloading them from an URL embedded in the subordinate certificate within the Authority Information Access extension. This is a belt-and-braces solution which can often hide badly configured web servers. Firefox refuses to do that though.

1

The reason (www.)fg.gov.ua is working in Chromium and Firefox, but not in Epiphany, is that the issuer certificate (Sectigo RSA Organization Validation Secure Server CA) is trusted by the former two and not by the latter.

Surprisingly, on Linux, both Chromium and Firefox use the root store of Mozilla. From https://www.chromium.org/Home/chromium-security/root-ca-policy :

When running on Linux, Google Chrome uses the Mozilla Network Security Services (NSS) library to perform certificate verification. When packaged or built from source, NSS includes certificates vetted according to the Mozilla Root Certificate Program.

Epiphany, however, doesn't include their own root store. Presumably it uses the certificates under /etc/ssl/certs available on most Linux distributions. I checked mine, but couldn't find any root cert from Sectigo:

$ find /etc/ssl/certs -name *Sectigo*
$ No results found.

To solve this issue, you'll need to either manually add the correct certificate, or click the button labeled "Accept Risk and Proceed" ;)

1
  • 1
    Thank you for explanation. Adding the intermediate certificate to the system's trust store would probably make validation work, but I'd rather do not try to decide whether I want to trust the intermediary certificate or not. Aug 19, 2020 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.