[release/7.0] Fix server-side OCSP stapling on Linux

[rzikm]

Backport of PR #96792, PR #96448, PR #90200 and PR #96972.

Fixes #96770, #96659 and #89907

Description

Regression: No, .NET 6 didn't have OCSP staple feature.
Customer: Internal partner team - blocking migration from Windows to Linux.

OCSP (Online Certificate Status Protocol) stapling is an optimization where instead of clients individually retrieving revocation status of the server certificate, server will fetch the OCSP response itself and send it to clients during connection handshake. The authenticity of the response is assured by a digital signature.

First bug in .NET 7.0+ ... An invalid response can get cached and the server would fail to refresh it. The server would then keep sending the old, cached and potentially malformed OCSP response. This bug is triggered when either:

• The OCSP response could not be parsed (e.g. due to OCSP server sending an error page due to outage)
• .NET fails to validate the authenticity of the OCSP response
  This has been partially fixed in main by PR Do not OCSP staple invalid OCSP responses #90200 and completely fixed in main by PR Recover from failed OCSP download. #96448

Second bug in .NET 7.0+ ... Validation of OCSP response always fails when the method of "delegated signing" is used (delegated signing means that the OCSP response is signed by a special certificate delegated by the server certificate issuer).

• Note that validation when receiving OCSP response on client-side is not affected by this bug and is extensively tested, only the server part is affected by the bug.
• Server validating the OCSP response before sending it out is only to play nice and not send invalid OCSP responses out. This bug DOES NOT create security vulnerability because clients are expected to independently validate the OCSP response themselves.
  Fixed in main by PR Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response #96792

The two issues mentioned above may lead to following undesired behaviors:

• Server caches an invalid OCSP staple (e.g. error page due to OCSP server outage), and keeps sending it out.
• Server stops refreshing the OCSP staple and keeps sending the old one even after its validity expired.
• Server sends out OCSP staple which it does not consider valid

Customer Impact

Android clients cannot connect to .NET 7+ servers affected by this bug because the OCSP information may get outdated (and not refreshed) and Android 9+'s application default security restrictions don't allow HTTP connections by default.

Regression

No, sending OCSP staples from .NET servers is a new feature in .NET 7.

Testing

Locally reproduced affected scenario and extensively tested manually.

Customer validated private 7.0 bits.

There is extensive existing test coverage on client-side OCSP usage/validation. Missing E2E server-side automated test coverage is planned for upcoming weeks.

Risk

Small to medium. Code touched by this PR is not used in other code paths than OCSP, so only "Sending OCSP staples from a server" scenario is affected.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection-metadata
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes Issue

main PR

Description

Customer Impact

Regression

Testing

Risk

Package authoring signed off?

IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	rzikm
Assignees:	rzikm
Labels:	area-System.Reflection.Metadata, new-api-needs-documentation
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes Issue

main PR

Description

Customer Impact

Regression

Testing

Risk

Package authoring signed off?

IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	rzikm
Assignees:	rzikm
Labels:	area-System.Net.Security, new-api-needs-documentation
Milestone:	-

[rzikm]

No *.ref assemblies were touched by this PR

[carlossanlop]

There was a generalized failure in the 7.0 branch which impacted this PR. I'm updating the branch so that your PR gets rebased to the latest bits.

[rzikm]

Build analysis shows that CI failures are either known or unrelated.

[karelz]

Approved by Tactics (@SteveMCarroll) on 1/15 via email - label updated to Servicing-approved.

[carlossanlop]

@karelz @rzikm who can provide a sign-off? Are the CI failures unrelated?

[rzikm]

CI failures are not related to the changes.

For code review I would like to wait for @bartonjs (together with the 8.0 PR).

We are also considering adding #96972 to this, it's a oneliner which fixes a very unlikely scenario. I know this is last-minute, but this change would probably not pass servicing on its own.

[wfurt]

LGTM