Re: TLS error from M-x gnus-read-ephemeral-emacs-bug-group

[Bob Proulx]

Glenn Morris wrote:
> Just a note to say that the Emacs command gnus-read-ephemeral-emacs-bug-group
> now fails with the (old) Emacs 24.3 (the default on fencepost.gnu.org).
> It worked fairly recently. It works (on a non-fencepost host) with (eg) 25.1.
> This may be https://debbugs.gnu.org/20465, an Emacs problem. Although on

I think you are probably correct.  But reading that it wasn't clear to
me if Emacs is using gnutls-cli as an external, or if it was using the
library as a compiled and linked in library.  I think if it is an
external that we can make this work more easily.

> fencepost.gnu.org, it still fails with 25.3. Maybe the gnutls version on
> fencepost is old...

Since I think both fencepost and debbugs have not changed libraries
which would change ciphers or codecs but time has marched on I think
this must be due to a certificate expiration that is now expiring that
allowed things to verify previously but now does not.

> Contacting host: debbugs.gnu.org:80
> gnutls.c: [0] (Emacs) fatal error: A TLS fatal alert has been received.
> gnutls.c: [0] (Emacs) Received alert:  Handshake failed
> gnutls.el: (err=[-12] A TLS fatal alert has been received.) boot: (:priority 
> NORMAL :hostname debbugs.gnu.org :loglevel 0 :min-prime-bits 256 :trustfiles 
> (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags 
> nil :verify-error nil :verify-hostname-error nil :callbacks nil)
> error in process filter: gnutls-negotiate: GnuTLS error: #<process 
> debbugs.gnu.org<1>>, -12
> error in process filter: GnuTLS error: #<process debbugs.gnu.org<1>>, -12

Since I have pre-compiled commands for openssl I will use it to poke
first.  On fencepost I can try this command and see this result.

    rwp@fencepost:~$ openssl s_client -connect debbugs.gnu.org:443 -CApath 
/etc/ssl/certs -showcerts </dev/null
    ...
        Verify return code: 0 (ok)
    ...

    rwp@fencepost:~$ openssl s_client -connect debbugs.gnu.org:443 -CApath 
/etc/ssl/certs -showcerts </dev/null 2>/dev/null | sed -n '/^-----BEGIN 
CERTIFICATE-----/,/^-----END CERTIFICATE-----/p;/^-----END CERTIFICATE-----/q' 
| openssl x509 -noout -dates
    notBefore=Dec 22 04:19:07 2020 GMT
    notAfter=Mar 22 04:19:07 2021 GMT

So on fencepost using openssl things appear to verify okay, that's the
"0 (ok)" code above, and the dates of the certificates expire March
2021.

I'll drop back to my own system where I have Jan Schamann's xpipe
command installed so that I can easily extract the  dates of the
intermediate certificates.  Same as if I were to hack them out of the
above -showcerts stream using other means and then extracting the
dates from them one by one.

    rwp@angst:~$ openssl s_client -connect debbugs.gnu.org:443 -CApath 
/etc/ssl/certs -showcerts </dev/null 2>/dev/null | xpipe -I -p '^-----END 
CERTIFICATE-----$' openssl x509 -noout -subject -dates
    subject=CN = debbugs.gnu.org
    notBefore=Dec 22 04:19:07 2020 GMT
    notAfter=Mar 22 04:19:07 2021 GMT
    subject=C = US, O = Let's Encrypt, CN = R3
    notBefore=Oct  7 19:21:40 2020 GMT
    notAfter=Sep 29 19:21:40 2021 GMT

That shows that the intermediate certificate expires September.
Which all looks good.

It seems reasonable that gnutls-cli would have similar capabilities
but I do not know it and so don't know how to use it to extract the
above.  I tried a few things very briefly but failed to deduce the
incantation in the time I have to look right now.

    rwp@fencepost:~$ gnutls-cli --print-cert debbugs.gnu.org
    Resolving 'debbugs.gnu.org'...
    Connecting to '209.51.188.43:443'...
    *** Fatal error: A TLS fatal alert has been received.
    *** Received alert [40]: Handshake failed
    *** Handshake has failed
    GnuTLS error: A TLS fatal alert has been received.

However that works with other web servers.

    rwp@fencepost:~$ gnutls-cli --print-cert www.gnu.org
    ... lots of output ...

I'll note that it also fails with my own server running Debian Stretch.

    rwp@fencepost:~$ gnutls-cli --print-cert www.proulx.com
    Resolving 'www.proulx.com'...
    Connecting to '96.88.95.61:443'...
    *** Fatal error: A TLS fatal alert has been received.
    *** Received alert [40]: Handshake failed
    *** Handshake has failed
    GnuTLS error: A TLS fatal alert has been received.

But interestingly it works okay with a client system that I set up
identically to the above.  Identically as far as I know.  It's a
client system so I will keep the URL unpublished.

The above gnutls-cli commands that fail on fencepost succeed for me on
my main desktop system.  So it does seem to be related to an installed
version problem of some sort.  But what?

And that is all I know at this moment.  I need to run off.  But maybe
this will be enough that someone else will know the detail that we are
missing right now.

Bob