Skip to content

[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

Merged
merged 17 commits into from
Jan 16, 2020

Conversation

javiercn
Copy link
Member

@javiercn javiercn commented Dec 3, 2019

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

  • Uses a sentinel file to detect if we explicitly made a certificate key trusted.
  • Creates new certificates and tries to set the key to be accessible across partitions when running dotnet dev-certs https
  • Detects when a valid certificate might not contain an accessible key and tries to fix it.
  • Produces an error message when Kestrel is not able to access the certificate key.

@@ -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);
Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

@javiercn javiercn requested review from Pilchie and Tratcher December 3, 2019 23:41
@javiercn javiercn added the feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform label Dec 4, 2019
@javiercn javiercn force-pushed the javiercn/https-mac-os-21 branch from c8134b5 to 79e8f14 Compare December 4, 2019 12:45
@javiercn javiercn changed the title [Platform] Detect and fix certificates with potentially inaccessible keys on Mac OS [Platform] Detect and fix certificates with potentially inaccessible keys on Mac OS (2.1) Dec 4, 2019
@javiercn javiercn added the Servicing-consider Shiproom approval is required for the issue label Dec 4, 2019
@javiercn
Copy link
Member Author

javiercn commented Dec 4, 2019

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

Screen Shot 2019-12-04 at 9 53 26 PM

@jamshedd jamshedd added Servicing-approved Shiproom has approved the issue and removed Servicing-consider Shiproom approval is required for the issue labels Dec 10, 2019
@jamshedd jamshedd added this to the 2.1.16 milestone Dec 10, 2019
@vivmishra vivmishra modified the milestones: 2.1.16, 2.1.17 Jan 9, 2020
@vivmishra
Copy link

Moved to Mar as per Tactics. Will need to be explicitly approved for Feb, if required.

@javiercn
Copy link
Member Author

/AzurePipelines run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@vivmishra
Copy link

If this can make Feb then move the milestone to 2.1.16.

@javiercn
Copy link
Member Author

/AzurePipelines run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkArtakMSFT
Copy link
Contributor

/AzurePipelines run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mkArtakMSFT mkArtakMSFT modified the milestones: 2.1.17, 2.1.16 Jan 16, 2020
@mkArtakMSFT
Copy link
Contributor

All the checks have passed:
image

@mkArtakMSFT mkArtakMSFT merged commit 7f53f7e into release/2.1 Jan 16, 2020
@mkArtakMSFT mkArtakMSFT deleted the javiercn/https-mac-os-21 branch January 16, 2020 06:54
mkArtakMSFT pushed a commit that referenced this pull request Jan 17, 2020
* [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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-platform Deprecated: Cross-cutting issues related to ASP.NET Core as a platform Servicing-approved Shiproom has approved the issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants