bug#30555: elpa.gnu.org certificate order

[Ian Kelling <iank@fsf.org>]

I think I've found the root cause as the apache config is wrong and am
going to fix this on the elpa server in the next few minutes, which I would
normally not touch.

Originall reported to sysadmin@gnu.org by "Sam Brightman, who i've cced

I'm writing because I believe the certificate chain for elpa.gnu.org is
incorrect. You can see the out-of-order chain warning on:

https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org&hideResults=on

You can also run e.g. gnutls-cli:

$ gnutls-cli elpa.gnu.org
|<1>| There was a non-CA certificate in the trusted list:
O=Entrust.net,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits
liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Certification
Authority (2048).
Processed 165 CA certificate(s).
Resolving 'elpa.gnu.org:443'...
Connecting to '208.118.235.89:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=elpa.gnu.org', issuer `CN=Let's Encrypt Authority
X3,O=Let's Encrypt,C=US', serial 0x037b6d60120d207d3270b0b184b1585921f0,
RSA key 2048 bits, signed using RSA-SHA256, activated `2017-12-02
10:00:36 UTC', expires `2018-03-02 10:00:36 UTC',
pin-sha256="m1/quPWpzBTNugV6iU+BLRy/IZIJex8ggZ47SOV4kG0="
Public Key ID:
sha1:a055226618cb098619db153e7d847d0f2637b836
sha256:9b5feab8f5a9cc14cdba057a894f812d1cbf2192097b1f20819e3b48e578906d
Public Key PIN:
pin-sha256:m1/quPWpzBTNugV6iU+BLRy/IZIJex8ggZ47SOV4kG0=
Public key's random art:
+--[ RSA 2048]----+
|++.o*..oo. |
|+=.B o.++ * |
|. = o + .* + |
| + oE . |
| . .S. |
| |
| |
| |
| |
+-----------------+

- Certificate[1] info:
- subject `CN=elpa.gnu.org', issuer `CN=Let's Encrypt Authority
X3,O=Let's Encrypt,C=US', serial 0x037b6d60120d207d3270b0b184b1585921f0,
RSA key 2048 bits, signed using RSA-SHA256, activated `2017-12-02
10:00:36 UTC', expires `2018-03-02 10:00:36 UTC',
pin-sha256="m1/quPWpzBTNugV6iU+BLRy/IZIJex8ggZ47SOV4kG0="
- Certificate[2] info:
- subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer
`CN=DST Root CA X3,O=Digital Signature Trust Co.', serial
0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using
RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17
16:40:46 UTC', pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Status: The certificate is trusted.
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
- Session ID:
85:4F:3F:0C:1E:14:EE:51:33:81:38:3A:C8:72:FE:2C:72:B5:93:81:C0:8A:69:10:CA:66:CC:EE:44:99:74:D5
- Ephemeral EC Diffie-Hellman parameters
- Using curve: SECP256R1
- Curve size: 256 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
- Compression: NULL
- Options: safe renegotiation,
- Handshake was completed

- Simple Client Mode:

Whilst some TLS libraries will re-order/de-duplicate in this situation,
at least GnuTLS prior to version 3 does not. This is a very common
version for LTS distribution releases, including Travis CI. Stock Emacs
with GnuTLS (<3) support cannot verify the certificate of its own
package repository as a result of this.


end quote.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org