runtime: [OCSP Stapling] OSCP Reponse has expired in .NET Linux

Description

Running on 7.0.14 version

We opened https://github.com/dotnet/runtime/issues/89907 previously for the invalid ocsp response when the application is started. A fix is made, but however it is not backported to .NET7.0.14 version yet.

Now, we met another OCSP expired failure on a long-running application instance which ran for about 10 days:

curl --cert-status --connect-timeout 10 <host>
Exception: curl: (91) OCSP response has expired 

This failure didn’t observed on all long-running instances, but just a bunch of them.

Per previous discussion in https://github.com/dotnet/runtime/issues/89907#issuecomment-1665979637, I wonder whether an invalid OCSP response was returned during the re-new operation, then caused this issue.

Can anyone help to take a further investigation on this?

Reproduction Steps

See above

Expected behavior

See above

Actual behavior

See above

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

About this issue

  • Original URL
  • State: open
  • Created 7 months ago
  • Comments: 17 (10 by maintainers)

Most upvoted comments

Update: when upgrading to .NET8, the OSCP stabling is disabled on Linux now … Is that the desired behavior?

curl --cert-status --connect-timeout 10 -vvv <target-url>
...
*  SSL certificate verify ok.
* No OCSP response received
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (91) No OCSP response received

Searching the code, it should due to the commit: https://github.com/dotnet/runtime/commit/43542978d7bea0f4760de4606b39d2c373bd5914 image in which “noOcspFetch == true” in the call stack , and the fix is added to .net8 related release only.

Prior to .net8, i.e. .NET7, without the explicit setting of noOcspFetch flag, the below code is invoked in which noOcspFetch= false, https://github.com/dotnet/runtime/blob/c282395b63c1757d4f4c1dc2e236680cfe2e7f96/src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.cs#L24C1-L33C10

image

So the behavior on .NET7 and .NET8 is different … Will .net8 go head with OCSP disabled by default?

@cdlliuy Please see https://github.com/dotnet/runtime/issues/89907#issuecomment-1697080508. I believe there should be no problem with servicing the 7.0 release with the fix if you provide us the business justification.