-
Notifications
You must be signed in to change notification settings - Fork 10.4k
[Platform] Detect and fix certificates with potentially inaccessible keys on Mac OS (2.1) #17560
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
Conversation
…ranteed to be accessible across security partitions
@@ -9,7 +9,7 @@ public static void GenerateAspNetHttpsCertificate() | |||
{ | |||
var manager = new CertificateManager(); | |||
var now = DateTimeOffset.Now; | |||
manager.EnsureAspNetCoreHttpsDevelopmentCertificate(now, now.AddYears(1)); | |||
manager.EnsureAspNetCoreHttpsDevelopmentCertificate(now, now.AddYears(1), isInteractive: false); |
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.
This is the bit that goes into the CLI.
At this point we don't want to try and setup the certificate key as that requires user interaction and the CLI first run experience must remain non-interactive.
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.
After this change, at which point would the dev certificate first be added/updated if not during the first run experience?
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.
The certificate still gets created during the first run experience. We simply don't try and make it available across security partitions at that time as that's the bit that requires user interaction.
Co-Authored-By: Daniel Roth <[email protected]>
Co-Authored-By: Daniel Roth <[email protected]>
src/Servers/Kestrel/Core/src/Internal/HttpsConnectionAdapter.cs
Outdated
Show resolved
Hide resolved
Co-Authored-By: Chris Ross <[email protected]>
c8134b5
to
79e8f14
Compare
I had to change the exception being caught to be inline with the ones in 3.0 and 3.1. As it turns out, the test I wrote was not hitting the right code path and I'm afraid there's no good way we can write a test for this. I've validated the solution E2E by monkey-patching the Kestrel.Core assembly in my shared framework and validated that it works. This fix is inline now with the one in 3.0 and in 3.1 |
Moved to Mar as per Tactics. Will need to be explicitly approved for Feb, if required. |
/AzurePipelines run AspNetCore-ci |
Azure Pipelines successfully started running 1 pipeline(s). |
If this can make Feb then move the milestone to 2.1.16. |
/AzurePipelines run AspNetCore-ci |
Azure Pipelines successfully started running 1 pipeline(s). |
/AzurePipelines run AspNetCore-ci |
Azure Pipelines successfully started running 1 pipeline(s). |
* [Platform] Detect and fix certificates with potentially inaccessible keys on Mac OS (2.1) (#17560) * [Https] Detects and fixes HTTPS certificates where the key is not guaranteed to be accessible across security partitions * Fix dotnet dev-certs https --check * Update logic for detecting missing certs * Fix security command * Update warning logic * Check that the key is accessible in Kestrel * Add correct link to docs * Update src/Tools/dotnet-dev-certs/src/Program.cs Co-Authored-By: Daniel Roth <[email protected]> * Update src/Tools/dotnet-dev-certs/src/Program.cs Co-Authored-By: Daniel Roth <[email protected]> * Add test for 2.1 * Update src/Tools/dotnet-dev-certs/src/Program.cs Co-Authored-By: Chris Ross <[email protected]> * Address feedback * Fix non-interctive path * Fix tests * Remove a couple of test from an unshipped product * Check only for certificates considered valid * Switch the exception being caught, remove invalid test Co-authored-by: Daniel Roth <[email protected]> Co-authored-by: Chris Ross <[email protected]> * Fix patchconfig merge (#18389) * Fix flaky HubConnectionHandler test (#18391) Co-authored-by: Javier Calvarro Nelson <[email protected]> Co-authored-by: Daniel Roth <[email protected]> Co-authored-by: Chris Ross <[email protected]> Co-authored-by: Brennan <[email protected]>
Description
We are signing the SDK installer and packages for Mac OS Catalina compliance with the requirement to have packages notarized. That change affects the way HTTPS works in ASP.NET Core and prevents users from running their ASP.NET Core applications.
To mitigate the issue we are including logic in Kestrel that detects this situation and informs customers of what steps to take to mitigate the issue and we are updating the "dotnet dev-certs" tool to detect when this situation can happen and to fix it automatically when the "dotnet dev-certs https" command is run.
Customer Impact
High
Once a customer installs an updated SDK version they won't be able to run their applications normally unless they fix the existing certificate.
Regression?
No, this is a new requirement introduced by Mac OS Catalina.
Risk
Low, we are limiting the changes in the runtime and the changes on the tool are simple.
Implementation details
dotnet dev-certs https