Closed
Description
In order to send intermediate certificates we try to add them to Certificate store when OS cannot build full chain without them.
While the X509Store.Open is on try/catch block the actual addition is not and it can fail for various reasons.
Exception = System.Security.Cryptography.CryptographicException: Access is denied.
at System.Security.Cryptography.X509Certificates.StorePal.Add(ICertificatePal certificate)
at System.Net.Security.SslStreamCertificateContext..ctor(X509Certificate2 target, ReadOnlyCollection`1 intermediates, SslCertificateTrust trust)
at System.Net.Security.SslStreamCertificateContext.Create(X509Certificate2 target, X509Certificate2Collection additionalCertificates, Boolean offline, SslCertificateTrust trust, Boolean noOcspFetch)
at System.Net.Security.SslAuthenticationOptions.UpdateOptions(SslServerAuthenticationOptions sslServerAuthenticationOptions)
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Participants
Activity
dotnet-policy-service commentedon Oct 7, 2024
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.
bartonjs commentedon Oct 7, 2024
I just want to say on record that the state that the reporting machines are in (where they stably succeed at opening the store ReadWrite, and stably fail at actually adding to it) is degenerate, and we shouldn't really cater to it (they should fix their permissions model so that open fails, or writes succeed).
However, since transitory failure (such as a concurrent permissions change) looks the same, we should go ahead and make sure that the calls to Add are in a try.
Which means I support fixing it, but still want them to know they're wrong 😄