HttpSys ClientCertificate property renegotiates

[Tratcher]

ITlsConnectionFeature.ClientCertificate is used to get the client certificate for the current connection. ITlsConnectionFeature.GetClientCertificateAsync is used to renegotiate the TLS session to request a certificate if you don't already have one. HttpSys has had a behavior in the past where it triggered the renegotiate even from the ClientCertificate property. ClientCertificateMethod.AllowRenegotation was added to control that, but it also disables it for GetClientCertificateAsync.

When implementing GetClientCertificateAsync renegotiation for Kestrel it became clear that the pattern developers want is for ClientCertificate to return the current certificate, if any, and for GetClientCertificateAsync to renegotiate for a cert if enabled. This allows them to do conditional logic like buffer the request body before starting the renegotiation.

Proposal: Remove the renegotiate logic from the ClientCertificate property and clean up the SetInitialized logic so that GetClientCertificateAsync can still renegotiate after ClientCertificate is called.

aspnetcore/src/Servers/HttpSys/src/RequestProcessing/RequestContext.FeatureCollection.cs

Lines 325 to 328 in 4f2214a

	else if (method == ClientCertificateMethod.AllowRenegotation)
	{
	_clientCert = Request.GetClientCertificateAsync().Result; // TODO: Sync over async;
	}

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.