CertificateManager.ListCertificates impacting ASP.NET startup

[stephentoub]

In an app created from the Blazor server template, CertificateManager.ListCertificates is consuming ~5% of startup time. Within ListCertificates, a significant portion of normal processing time is spent opening the certificate stores and enumerating/validating every certificate. However, in the typical developer use case, an ASP.NET certificate will be found in the user store (since that's where it's generally added), but we still open and enumerate the local machine store, anyway. It could be beneficial to first check the user store and only look at the local machine store if a valid cert can't be found in the user store.

cc: @halter73

[blowdart]

However, in the typical use case, an ASP.NET certificate will be found in the user store (since that's where it's generally added)

Are we sure about that?

For IIS the typical approach was to put it into local machine so all app pools could see it, and ACL appropriately there.
Service Fabric also uses the machine store, including in their kestrel instructions.

The dotnet cert tooling installs the self signed cert into the user store, because it's a testing cert. I'm not sure you can say that the typical, real life use case does the same.

[stephentoub]

The dotnet cert tooling installs the self signed cert into the user store, because it's a testing cert. I'm not sure you can say that the typical, real life use case does the same.

Test cert is "real life use case" when focused on developer inner loop performance.

And, regardless, it doesn't really matter. Today both costs are paid up-front: we fetch all certs from both stores, and then process the user certs, and then process the local machine certs. We may as well just fetch one, and only fetch the other if necessary.

aspnetcore/src/Shared/CertificateGeneration/CertificateManager.cs

Lines 178 to 180 in 7c0c74b

	var currentUserCertificates = ListCertificates(StoreName.My, StoreLocation.CurrentUser, isValid: true, requireExportable: true);
	var trustedCertificates = ListCertificates(StoreName.My, StoreLocation.LocalMachine, isValid: true, requireExportable: true);
	var certificates = currentUserCertificates.Concat(trustedCertificates);

[ShreyasJejurkar]

If a certificate gets found in the current user store location, should we skip the call to find certificates from the local machine store? Or vice versa?

@stephentoub

[stephentoub]

If a certificate gets found in the current user store location, should we skip the call to find certificates from the local machine store

That is what I was suggesting.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[stephentoub]

After the changes made to CertificateManager recently (e.g. #27956), ListCertificates has dropped to only ~2% of startup. On top of that, the path Kestrel takes already only checks the user store:

aspnetcore/src/Servers/Kestrel/Core/src/KestrelServerOptions.cs

Line 176 in dfe625f

private void EnsureDefaultCert()

It's not clear why

aspnetcore/src/Shared/CertificateGeneration/CertificateManager.cs

Line 166 in 277cc56

public EnsureCertificateResult EnsureAspNetCoreHttpsDevelopmentCertificate(

and EnsureDefaultCert don't need to do the same thing, but it appears that's used only by dotnet-dev-certs rather than by Kestrel, and so isn't an issue for ASP.NET startup.

So, we can close this, unless someone would like to keep it open for tracking improvements to dotnet-dev-certs.