Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch

[Andreas Metzler]

On 2020-12-08 Axel Beckert <abe at 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