-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response #96792
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
|
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Show resolved
Hide resolved
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Outdated
Show resolved
Hide resolved
…treamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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
CheckOcspGetExpiry
function 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_CHAIN
to 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
CheckOcspGetExpiry
from 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.