On 2020-12-08 Axel Beckert <a...@debian.org> wrote: > Andreas Metzler wrote: > > > I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect > > > to > > > the Debian mirror https://debian.ethz.ch/debian/: > > > > > $ sudo apt update > > > Ign:1 https://debian.ethz.ch/debian sid InRelease > > > Err:2 https://debian.ethz.ch/debian sid Release > > > Certificate verification failed: The certificate is NOT trusted. The > > > certificate issuer is unknown. Could not handshake: Error in the > > > certificate verification. [IP: 129.132.53.171 443] > > > Reading package lists... Done > [...] > > afaict the server is misconfigured:
> I beg to disagree. ;-) Hello Axel, thanks for following up upstream and providing more context. My "afaict" was just a result of a quick google for the respective rfc. I ended up with tls 1.2 (rfc 5246) which has | The sender's certificate MUST come first in the list. Each following | certificate MUST directly certify the one preceding it. The current rfc (TLS 1.3 / rfc 8446) is more lenient (MUST -> SHOULD). So still the server shouldn't send duplicate certificates. | Each following certificate SHOULD directly certify the one immediately | preceding it. [...] However according to the rfc GnuTLS should accept the certificate chain. ;-) | Note: Prior to TLS 1.3, "certificate_list" ordering required each | certificate to certify the one immediately preceding it; however, | some implementations allowed some flexibility. Servers sometimes | send both a current and deprecated intermediate for transitional | purposes, and others are simply configured incorrectly, but these | cases can nonetheless be validated properly. For maximum | compatibility, all implementations SHOULD be prepared to handle | potentially extraneous certificates and arbitrary orderings from any | TLS version, with the exception of the end-entity certificate which | MUST be first. cu Andreas