Bug#944124: apt fails to verify certificate when using https and ocsp stapling

[David Kalnischkies]

Control: reassign -1 libgnutls30 3.6.10-4

Hi,

On Mon, Nov 04, 2019 at 05:49:53PM +0100, Robert Senger wrote:
> We are running several debian repositories for custom kernel and patched deb
> packages. We use apache2 on Buster, with https enabled, to serve the repos.
> 
> This worked fine, until we decided to enable ocsp stapling in apache2, which
> runs other vhosts besides the repos.
> 
> Since then, apt fails to validate the server's certificate. Error message is:
> 
> Fehl:15 https://microscopium.de/repos/apt/debian/common buster/patched Release
>   Certificate verification failed: The certificate is NOT trusted. The received
> OCSP status response is invalid.  Could not handshake: Error in the certificate
> verification. [IP: fd10:2842:f0d1:101:222:4dff:feb8:17c 8000]
> 
> Restarting apache2 helps for a while (apt works, at least once), but the error
> comes up again when apt is run later.

The (part of the) error message is from libgnutls30:
| The certificate is NOT trusted. The received OCSP status response is invalid.
and is the stringyified GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR error returned
by gnutls_handshake.

apts https method is a thin gnutls-powered wrapper around our http method, the
code lives in the TlsFd struct and the UnwrapTLS method, both here:
https://salsa.debian.org/apt-team/apt/blob/master/methods/connect.cc#L802

As you can see, we have no code dealing with OCSP directly and we do not keep
state ourselves by caching responses or some such, so I am completely at a lose
what apt could be doing wrong here or how its behaviour would change over
multiple runs.

So it is either a bug in gnutls or in how we use it; in both cases I hope the
gnutls maintainers can shine some light on the issue better than I could and
hence I reassign to them.


> All web tools tell us that certificate installation and ocsp stapling are
> correct. No other problems with other https clients have been observed so far.

You might want to retry with gnutls based clients. Many popular https clients
are based on openssl, so your testing might not be as diverse as you have thought.

It might also help if you could provide a public testcase as – as you might
predict – https servers with client certificate setup and stapling aren't
exactly common or easy to setup for a quick test; in all honest, I haven't
tried in the hope that someone closer to the material can/will.


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20191109/b7e4d3ae/attachment.sig>