Allow macOS chain building to use network if revocation checking is online #47718
Conversation
…nline. The DisableCertificateDownloads property on the chain policy controls all network activity when building a chain on macOS, not just AIA fetching. If set to true, the (default) revocation policy would fail because the network would be treated as unavailable. On macOS, as a work around, permit the network activity if revocation checking is explicitly enabled.
|
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq Issue DetailsPossible solution for #47713 The DisableCertificateDownloads property on the chain policy controls all
|
| // There is no way to independently enable or disable online revocation checking | ||
| // and AIA fetching. If the caller specifies they want Online revocation checking, | ||
| // then we need to allow network operations (including AIA fetching.) | ||
| bool revocationRequiresNetwork = revocationMode == X509RevocationMode.Online; |
There was a problem hiding this comment.
I seem to recall macOS does not support Offline. Does Offline act as NoCheck or Online? In other words, should this be:
| bool revocationRequiresNetwork = revocationMode == X509RevocationMode.Online; | |
| bool revocationRequiresNetwork = revocationMode != X509RevocationMode.NoCheck; |
There was a problem hiding this comment.
That's a question for the ages 😄. I don't know what macOS does with CRL or OCSP caching, so it's hard to know which one is right. Maybe something like
- With everything on do a revocation check
- Make sure the OCSP responses include the nextUpdate time (or whatever it's called) and it's at least 5 minutes in the future.
- Put the network state in no downloads (let Offline + DisableDownloads be "no downloads")
- Change the mode to Offline
- Build the chain again
If that succeeds, then there's caching and we want Online vs not. If that fails then we probably decide that we want NoCheck vs not, since we've let Offline be Online on macOS historically.
There was a problem hiding this comment.
Okay, given this line here, we opt in to the revocation checking polices as long as != NoCheck. It's done that for a while, prior to .NET 5, so Offline was being treated as Online.
Given that, it probably makes sense to keep that behavior.
There was a problem hiding this comment.
Given that, it probably makes sense to keep that behavior.
Well, previously we had two booleans that seemed indepdent:
- Do revocation checking
- Networky stuff (interpreted as "use AIA")
If validity-period OCSP means that there's a meaningful "revocation yes, download no" then Offline could be Offline if DisableCertificateDownloads is true, or Online when it's false.
But that's definitely a hard thing to test, document, and maintain, so I'm probably OK with "on macOS Offline means Online".
NoCheck must be used to disable network.
|
@bartonjs I will de-draft this since I think this is the right thing to do. If you agree, I would appreciate and outer-loop run to get a sense of what other platforms I might need to chip away at. My hesitation is around the impact of this. I know |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Seems good to me. |
|
Looks like all of the failures are unrelated. |
ghost
locked as resolved and limited conversation to collaborators
Fixes #47713
The DisableCertificateDownloads property on the chain policy controls all
network activity when building a chain on macOS, not just AIA fetching. If
set to true, the (default) revocation policy would fail because the network
would be treated as unavailable. On macOS, as a work around, permit the
network activity if revocation checking is explicitly enabled.