Dev Certs tool should handle "upgrading" certificates as necessary

[analogrelay]

In .NET Core 3.0 we need to introduce an updated dev cert in order to handle changes in supported cipher suites in Windows (#8952). If the user already has the existing (pre-3.0) dev cert installed, they will get an error. In order to update, the user must run two commands:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

These commands re-install the cert, ensuring it is the correct version.

I suggest we introduce a "versioning" element to the dev certificates and update the commands to make this experience cleaner for users.

1. We augment the ASP.NET Core HTTPS Development Certificate extension to include an optional "version" value. I believe the extension can carry any raw data and that data is tagged with a size. It looks like we currently put the friendly name ASP.NET Core HTTPS development certificate in as the content of this field. My suggestion would be to treat that as a "magic number" and allow additional fields to be specified immediately following it. So the logic would be as follows:
   1. If the extension size equals the length of the ASCII friendly name, the version is presumed to be 0
   2. If the extension size is greater than the length of the ASCII friendly name, immediately following the final byte of the friendly name there must be a single byte indicating the version. This byte must be greater than or equal to 1
   3. Further data may be provided, as needed in the future. Where possible, tools that consume the certificate should ignore unnecessary additional fields
   4. As an alternative, if no tools are currently depending on the specific value of the extension, we could replace the extension content completely with our own format that includes a version and treat the ASCII A (hex 0x41) value as indicating version 0 (which by definition has no additional data). We would also have to prohibit the use of 0x41 to indicate a future version.
2. The dotnet dev-certs --check action will return a non-zero exit code and indicate an appropriate error message if a cert is present BUT the version of the installed cert pre-dates the version the tool provides.
3. The dotnet dev-certs action (no arguments), on detecting that a certificate already exists with an earlier version than the tool supports, will remove that certificate and install a new one with the appropriate version.
4. The dotnet dev-certs --trust action will similarly upgrade the cert and ensure the new cert is trusted.

Things to consider:

• An "upgrade" of the cert is "destructive". A new certificate is generated. As long as nothing is pinning the thumbprint of this cert it should be OK. Since this is for development purposes, we shouldn't be making guarantees that it will remain entirely unchanged anyway.
• Some platforms (i.e. Linux) don't have a certificate store, so upgrades aren't feasible here. We'll just have to document this situation for those platforms since the user will have to manually manage the certificate anyway. Using the --export-path option to export the certificate will export a new certificate that meets the new requirements anyway.
• The version field in the certificate would, theoretically, allow Kestrel to detect an out-of-date certificate and either fail or produce a warning. That's a topic for further discussion elsewhere though.

[analogrelay]

We need to bump the priority of this somewhat since 1903 is rolling out and breaks customers on 2.1 and above.

We think we have some short-term options to make this better, but we need to have a strategy for handling this moving forward. Core scenarios:

1. When running the first-run experience of the SDK, the dev cert tool should automatically detect and update out-of-date dev certificates
2. VS should be able to run a command to detect an out-of-date dev certificate, prompt the user to upgrade and then execute the upgrade
3. Users should be able to (from the command line) run a command to upgrade the certificate
4. (Lower Priority) The runtime should provide a warning if it knows an out-of-date dev certificate is being used.

cc @javiercn @DamianEdwards @davidfowl @shirhatti

[analogrelay]

Adding area-servers so that it comes up in triage and we keep track of it.

[Tratcher]

Note the Win 1903 issue only affects HTTP/2 which was not available or was disabled by default prior to 3.0.

[analogrelay]

Impact Matrix:

Client OS / ASP.NET Core Version + Protocol	2.1 HTTP/1.1	2.2 HTTP/1.1	2.2 HTTP/2	3.0 All
Windows 10 1903	Not Affected	Not Affected	Affected, no fix*	Affected, fix available
Windows <1903	Not Affected	Not Affected	Not Affected	Not Affected

(*) 2.2 HTTP/2 user can change to use the IIS Express dev cert instead to workaround this problem. Or use the 3.0 dev-cert tool to fix the cert.

[analogrelay]

Given @Tratcher 's context above, @DamianEdwards and I agreed that this no longer meets the bar for a backport. The only impacted users are 2.2 users who explicitly opted in to HTTP/2 and 3.0 users. In both cases, the 3.0 dev-certs tool can be used to repair the issue.

cc @shirhatti

[javiercn]

So good to close? We already did the cert update, so clean machines are good and 2.2 machines will get automatically fixed as soon as their cert expires or can be preemptively fixed by running the two commands above.

(VS just runs the tool, so it gets updates automatically)

[Tratcher]

@javiercn no. The cert is good for a year, so 2.2 customers that upgrade to 3.0 would be broken for up to a year. VS wouldn't update them because its validity checks would still pass. This issue is about adding an additional validity check so VS can automatically update a non-expired cert based on other criteria.

Having customers run those two commands is a mitigation, not a solution. We'd rather have VS run those automatically.

[analogrelay]

This is still an active issue in 3.0. @DamianEdwards hit it and thought it was a server bug.