elpa.gnu.org seems to be malformed in a way that causes some SSL analyzers to warn about “extra certs”.  

For instance https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org reports

Certificates provided | 3 (3732 bytes)
Chain issues | Incorrect order, Extra certs

And of the three certificates found, it appears certificate[0] and certificate[1] are identical. Is the duplication considered "out of order?”

Because indeed, on older variants of Ubuntu where gnutls-cli v2.12.23 is in use (this is the case for the container infrastructure on Travis CI), we have this:

# gnutls-cli -v
gnutls-cli (GnuTLS) 2.12.23
Packaged by Debian (2.12.23-12ubuntu2.8)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Nikos Mavrogiannopoulos.
#
# gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 elpa.gnu.org
Processed 148 CA certificate(s).
Resolving 'elpa.gnu.org'...
Connecting to '208.118.235.89:443'...
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.


Which means tools like “Cask” which invoke Emacs in batch to install dependencies from package repos like ELPA or MELPA are failing on the Travis CI infrastructure.

It’s causing me to introduce workarounds, such as downloading a newer gnutls source package and compiling it locally in the Travis CI build. I would really prefer not to do this. It adds unnecessary time and complexity to the CI setup for some Emacs packages, and (conversely) one can imagine other Emacs package maintainers may be avoiding the complexity by not implementing CI for their projects.

Can someone more knowledgable about the standards, the evolution of gnutls since 2.12, and the server configuration of elope.gnu.org please weigh in on this?

thanks
Neil