Dev Certs tool should handle "upgrading" certificates as necessary

In .NET Core 3.0 we need to introduce an updated dev cert in order to handle changes in supported cipher suites in Windows (https://github.com/aspnet/AspNetCore/issues/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.

[jkotalik]

Acceptance will be handled by https://github.com/aspnet/AspNetCore/issues/10927

[analogrelay]

Filed https://github.com/aspnet/AspNetCore/issues/10927.