[gnutls-devel] GnuTLS | gnutls-cli: Inconsistent OCSP behavior regarding intermediate depending on stapling (#981)

[Development of GNU's TLS library]

Hanno Böck created an issue: https://gitlab.com/gnutls/gnutls/-/issues/981



I noticed a curious behavior of gnutls-cli regarding OCSP checks and intermediate certs.

It seems when passing the --ocsp option the intermediate cert will be ocsp checked, but only if ocsp stapling is not set.

To test (first fake a bad ocsp server by redirecting identrust's OCSP to localhost):
`echo "127.0.0.1 isrg.trustid.ocsp.identrust.com" >> /etc/hosts`
`gnutls-cli --ocsp zucker.schokokeks.org:443`
`gnutls-cli --ocsp letsencrypt.org:443`

The first connection will succeed, the second will not. The difference is the first host enables OCSP Stapling. I believe what's happening is that when the client detects OCSP stapling it will skip direct OCSP checks. But Stapling only staples the OCSP reply for the end-entity cert, not the intermediate.

I generally think it's valuable to have a way to check the intermediate. I am not sure it should be done by default. In any case: I guess this should not depend on OCSP stapling.

I propose one of the following changes:
1. Declare/document that --ocsp always checks the intermediate and if the end-entity OCSP comes via stapling still connect to the intermediate.
2. Declare/document that --ocsp never checks the intermediate and add another option --ocsp-check-chain or something like this that will enable intermediate checks.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/981
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200430/7b490826/attachment.html>