Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response#96792
Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response#96792rzikm merged 7 commits intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones Issue DetailsFixes #96659. When validating OCSP Staple retrieved in SslStreamCertificateContext, we create an X509_STORE to specify which certificates are to be considered trusted. Until now, we passed in only the immediate issuer of the validated certificate. If this was only an intermediate CA certificate and the OCSP was signed by a delegated signer, the signer verification process would fail because the signer could not be anchored in a trusted Root CA. Since the This was not uncovered by existing tests because the current tests are calling
|
…treamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
|
looks like we actually always need to always keep the root from AddRootCertificate🤦 |
|
FWIW, you should be able to test this locally by just adding PkiOptions.IssuerAuthorityHasDesignatedOcspResponder in src\libraries\System.Net.Security\tests\FunctionalTests\CertificateValidationRemoteServer.cs line 199. Longer term that probably needs to come from a parameter in that helper routine so that there are tests both with and without it; but that's the fastest "how do I test this?" that I can come up with. |
|
I have extracted the CertificateAuthority and RevocationResponder to a console app, so I am now running against that and was wondering why it was not working anymore. A fix is incoming. |
|
I tested latest version with
PTAL to confirm there is nothing terribly wrong in the last commit. |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
No related failures in the outerloop run. |
…onse (dotnet#96792) * Add entire issuer chain to trusted X509_STORE when validating OCSP_Response * Code review feedback * More code review feedback * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Fix compilation * Always include root certificate --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
* Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response (#96792) * Add entire issuer chain to trusted X509_STORE when validating OCSP_Response * Code review feedback * More code review feedback * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Fix compilation * Always include root certificate --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Recover from failed OCSP download. (#96448) * Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry * Don't shorten OCSP expriation on failed server OCSP fetch (#96972) * Don't shorten OCSP expriation on failed server OCSP fetch * Code review feedback --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
…onse (dotnet#96792) * Add entire issuer chain to trusted X509_STORE when validating OCSP_Response * Code review feedback * More code review feedback * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Fix compilation * Always include root certificate --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
Fixes #96659.
When validating OCSP Staple retrieved in SslStreamCertificateContext, we create an X509_STORE to specify which certificates are to be considered trusted. Until now, we passed in only the immediate issuer of the validated certificate. If this was only an intermediate CA certificate and the OCSP was signed by a delegated signer, the signer verification process would fail because the signer could not be anchored in a trusted Root CA.
Since the
CheckOcspGetExpiryfunction is used by other code paths, I believe the safer fix is to add also the rest of the certificate from the chain built as part of constructing the SslStreamCertificateContext instance, rather than usingOCSP_PARTIAL_CHAINto enable anchoring in trusted intermediate (only) CAs. See also discussion on the original issue.This was not uncovered by existing tests because the current tests are exercising codepaths which call
CheckOcspGetExpiryfrom different callstack (see #96659 (comment)). For now I tested the code via the repro code from the issue mentioned above. Automated tests are delegated to #96791.