Nefunkční HTTPS mirror od CZ.NIC

[OndraNi]

Ahoj, mám problém s ubuntu mirrorem od cz.nic přes https.

Kód: [Vybrat]

W: Failed to fetch https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 2001:1488:ffff::63 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Ostatní mirrory mi fungují vpořádku. Zkoušel jsem reinstalovat ca-certificates, ale nepmohlo.

[Reklama]

[Petr Krčmář]

Zkouším to v Debianu i Ubuntu, koukám na certifikáty a připadá mi to všechno v pořádku. Buď už to tedy mezi tím opravili nebo je rozbitá ta instalace Ubuntu, na které to zkoušíš ty. Zkus to stáhnout ručně pomocí curl -v a podívat se, co se mu přesně nezdá.

[Pavel Dufek]

Zdravím, jen takový nápad - pokud by v použitých certifikátech bylo LetsEncrypt, mohl by u staršího systému (v roli klienta) být problém s "dvojakostí" podpisu kořene LetsEncrypt a správném rozpoznání důvěry. Stručně - mohlo by pomoci na tvém Ubuntu poeditovat soubor /etc/ca-certificates.conf - najít řádek s /DST_Root_CA_X3.crt a zaremovat ho na tvar !mozilla/DST_Root_CA_X3.crt a pak dát update-ca-certificates, to vše samozřejmě jako root či přes sudo. A pak zkusit znovu apt-get update atd.

[Vít Šesták (v6ak)]

Podle URL jde o Ubuntu Jammy, tedy 22.04. To není staré…

Zkoušel jsem https://www.ssllabs.com/ssltest/analyze.html?d=cz.archive.ubuntu.com&s=2001:1488:ffff:0:0:0:0:63 a je tam „Chain issues:    Incorrect order, Extra certs“. Nevidím ale, proč by se to mělo chovat u každého jinak.

[OndraNi]

Udělal jsem úplně čistou instalaci Ubuntu 22.04 ve VM a stejný problém. Ve starších 20.04 funguje bez problémů. Musí teda být problém na straně nic.cz a novější verze systému.

curl normálně jde bez žádných chyb
DST_Root_CA_X3.crt v /etc/ca-certificates.conf není

Ostatní mirrory fungují, mají dobré skóre na ssllabs
https://www.ssllabs.com/ssltest/analyze.html?d=mirror.dkm.cz&s=86.49.49.49
https://www.ssllabs.com/ssltest/analyze.html?d=ftp.sh.cvut.cz&s=147.32.127.196

[Reklama]

[Lukáš Tesař]

Mám už několik měsíců stejný problém na několika strojích s Ubuntu 22.04. Zatím jsem to vždy řešil změnou mirroru na ten od IT4Innovations, který funguje v pořádku.

Zkoušel jsem https://www.ssllabs.com/ssltest/analyze.html?d=cz.archive.ubuntu.com&s=2001:1488:ffff:0:0:0:0:63 a je tam „Chain issues:    Incorrect order, Extra certs“. Nevidím ale, proč by se to mělo chovat u každého jinak.

Podle https://stackoverflow.com/a/52858001/6440524 je to špatně. Může to být zdrojem chyby?

Jestli ano, dá se někde sehnat kontakt na někoho v CZ.NICu, kdo to má na starosti? Je trošku blbé, aby hlavní a výchozí český mirror měl nefunkční HTTPS na APT interface.

[Filip Jirsák]

Ano, je tam zmatek v řetězci certifikátů, viz výpis z OpenSSL:

Kód: [Vybrat]

Certificate chain
 0 s:CN = mirror-r-01.nic.cz
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:CN = mirror-r-01.nic.cz
   i:C = US, O = Let's Encrypt, CN = R3
 2 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
 4 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

Certifikáty číslo 0 a 4 tam být nemají. Poslal jsem to e-mailem na podporu CZ.NIC. Když už ten problém trvá pár měsíců, rychlost e-mailu by měla stačit :-)

[Michal Stanke]

Nedaří se mi to nijak reprodukovat, ale přeposlal jsem info a odkaz na snad platný kontakt správců z CZ.NICu. Snad se jim to podaří vyřešit.

[to_je_jedno]

mam starsi, avsak (skoro - max tyden, dva od posledniho update) aktualizovane 22.04 na vpsfree.cz a chybu nevidim:

Kód: [Vybrat]

wget https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease
--2023-02-24 09:38:24--  https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease
Resolving cz.archive.ubuntu.com (cz.archive.ubuntu.com)... 2001:1488:ffff::63, 217.31.202.63
Connecting to cz.archive.ubuntu.com (cz.archive.ubuntu.com)|2001:1488:ffff::63|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 270087 (264K)
Saving to: ‘InRelease’

InRelease                         100%[===========================================================>] 263.76K  --.-KB/s    in 0.002s

2023-02-24 09:38:24 (113 MB/s) - ‘InRelease’ saved [270087/270087]

[Filip Jirsák]

To, že se nějkaý software srovná s chybným seznamem certifikátů, neznamená, že tam ta chyba není. OpenSSL i SSL Report shodně ukazují stejné chyby v řetězci certifikátů (jsou tam 2 certifikáty navíc, problematický je hlavně ten zopakovaný certifikát serveru, který přerušuje hned na začátku řetězec důvěryhodnosti certifikátů).

[Michal Stanke]

Před obědem mi dorazila odpověď od správců z CZ.NICu, a Qualys SSL Labs už nic nenamítá.

Dobrý den,

duplicitní certifikát z chainu jsme odstranili. Snad by někteří uživatelé už neměli mít problém.

Děkuji za upozornění!

Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.

[Filip Jirsák]

Před obědem mi dorazila odpověď od správců z CZ.NICu, a Qualys SSL Labs už nic nenamítá.

Dobrý den,

duplicitní certifikát z chainu jsme odstranili. Snad by někteří uživatelé už neměli mít problém.

Děkuji za upozornění!

Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.

Ano, také jsem dostal odpověď:

Dobrý den,

děkujeme za upozornění. Chybný chain jsme opravili.

S pozdravem.

Podle OpenSSL už jsou tam jen 3 certifikáty, které na sebe navazují správně:

Kód: [Vybrat]

Certificate chain
 0 s:CN = mirror-r-01.nic.cz
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Formálně by to tedy mělo být správně, teď je na uživatelích Ubuntu ověřit, zda tohle opravdu byla ta příčina.

[Petr Krčmář]

Já jsem to dneska do CZ.NIC nahlásil a očividně to rychle řešili.

[Lukáš Tesař]

Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.

Dobrý den,

ano, mirror již nyní funguje bez problémů. Děkuji všem zúčastněným za nahlášení a CZ.NIC za rychlou opravu

--
Omlouvám se za prodlevu, najednou mi přestaly chodit notifikace.

[mikesznovu]

Poslal jsem to e-mailem na podporu CZ.NIC. Když už ten problém trvá pár měsíců, rychlost e-mailu by měla stačit :-)

E-mail umí být i rychlý, doručení do 5s, při push notifikacích to MUA se dozví hned. Akorát ne všichni mail.provideři umí IDLE (u seznam.cz mi to nešlo). Za druhý někdy to doručení není v řádku vteřin, ale minut, vázne to.



Nemyslím, že problém je vyřešen všude. Někdy před 2 měsíci(hodně přibližně) to začlo zlobit, jsem zpozoroval jsem invalid certificate

Kód: [Vybrat]

depth=0 C = CZ, ST = "Praha, Hlavn\C3\AD m\C4\9Bsto", O = "CESNET, z\C3\A1jmov\C3\A9 sdru\C5\BEen\C3\AD pr\C3\A1vnick\C3\BDch osob",
CN = speedtest.cesnet.cz
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CZ, ST = "Praha, Hlavn\C3\AD m\C4\9Bsto", O = "CESNET, z\C3\A1jmov\C3\A9 sdru\C5\BEen\C3\AD pr\C3\A1vnick\C3\BDch osob",
CN = speedtest.cesnet.cz
verify error:num=21:unable to verify the first certificate
verify return:1
DONE
notBefore=Feb 21 00:00:00 2023 GMT
notAfter=Feb 21 23:59:59 2024 GMT

Tomu odpovídá Feb 21 a myslím, že to spolu souvisí i když to v názvu nemá NIC