Comment dépanner la vérification de site Web SSL sur Debian ?
J'essaie de dépanner l'accès sécurisé à un site Web sur mon ordinateur portable Debian. Lorsque j'essaie d'accéder au site Web Gnome (Epiphany), aux flux Gnome urlwatch, ou openssl, cela échoue. Gnome Web déclare que le site Web ne peut pas être vérifié. Voir la sortie ci- openssldessous. Mais Chromium et Firefox chargent le site sans problème et déclarent que la connexion est sécurisée. Comment puis-je vérifier s'il s'agit d'un bogue dans mon système, que je pourrais corriger, ou d'une mauvaise configuration sur le site Web, que Chromium et Firefox contournent d'une manière ou d'une autre ?
$ 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
Modifier :
Compte tenu des réponses, j'ai décidé de vérifier si la validation SSL réussirait si le serveur fournissait la chaîne. À partir des informations sur le site Web dans Firefox, j'ai enregistré localement le certificat intermédiaire que Firefox a utilisé pour le site Web. Avec lui, j'ai couru avec succès openssl verifysur le certificat du serveur. Je conclus que mon système dispose du certificat racine nécessaire. Firefox utilise probablement comme solution de contournement le certificat intermédiaire qu'il a mis en cache à partir d'une utilisation précédente ailleurs.
$ 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
En remarque, j'ai trouvé que je peux utiliser ssl_no_verify: truedans urlwatchla configuration du travail pour ignorer la vérification.
Mise à jour :
J'ai envoyé un e-mail à la ligne de commentaires du site Web et les ai dirigés vers RFC, comme suggéré dans la réponse. Le site fonctionne bien maintenant.
Réponses
Votre serveur n'envoie qu'un seul certificat - celui qui lui a été délivré.
Cependant, il devrait envoyer tous les certificats de la chaîne. Pour plus d'informations, dirigez vos administrateurs de serveur vers RFC 5246 Section 7.4.2 où il est spécifiquement indiqué que la chaîne doit être envoyée et pas simplement le certificat d'entité finale.
Tant que votre client dispose du certificat de l'autorité de certification racine dans son magasin d'ancrage de confiance, il créera la chaîne en utilisant les certificats intermédiaires et d'entité finale fournis dans la poignée de main TLS.
Notez que les clients Windows peuvent automatiquement récupérer les certificats parents manquants de la chaîne en les téléchargeant à partir d'une URL intégrée dans le certificat subordonné dans l'extension Authority Information Access. Il s'agit d'une solution de ceinture et de bretelles qui peut souvent cacher des serveurs Web mal configurés. Firefox refuse cependant de le faire.
La raison pour laquelle (www.)fg.gov.ua fonctionne dans Chromium et Firefox, mais pas dans Epiphany, est que le certificat de l'émetteur ( Sectigo RSA Organization Validation Secure Server CA) est approuvé par les deux premiers et non par le second.
Étonnamment, sous Linux, Chromium et Firefox utilisent le magasin racine de Mozilla. Dehttps://www.chromium.org/Home/chromium-security/root-ca-policy:
Lorsqu'il s'exécute sous Linux, Google Chrome utilise la bibliothèque Mozilla Network Security Services (NSS) pour effectuer la vérification des certificats. Lorsqu'il est empaqueté ou construit à partir de la source, NSS inclut des certificats approuvés conformément au programme de certificat racine de Mozilla.
Epiphany, cependant, n'inclut pas son propre magasin racine . Vraisemblablement, il utilise les certificats sous /etc/ssl/certsdisponibles sur la plupart des distributions Linux. J'ai vérifié le mien, mais je n'ai trouvé aucun certificat racine de Sectigo :
$ find /etc/ssl/certs -name *Sectigo*
$ No results found.
Pour résoudre ce problème, vous devrez soit ajouter manuellement le bon certificat, soit cliquer sur le bouton "Accepter le risque et continuer" ;)