CertificateFile without Bundled Key does not use Mutual Authentication

[caleblloyd]

Both a Client Certificate and a Client Key are needed to perform Mutual Authentication

X509Certificate2 allows loading a PEM encoded certificate from CertificateFile, but the X509Certificate2.HasPrivateKey property will be false. The SSL connection will still succeed, but will not be mutually authenticated - SslStream.IsMutuallyAuthenticated will be false. To the user, this is unexpected behavior; when they provide a Client Certificate and the connection succeeds, they would assume the connection is using Mutual Authentication.

Loading separate Certificate and Key files has spotty support - it is possible in netstandard2.0 but not elegant: https://github.com/dotnet/corefx/issues/17892. If we wanted to support it, it'd probably be better to find a third-party library (BouncyCastle?) that handles loading and validating certificates in different formats.

I think that the best path forward that does not involve adding dependencies would be to only allow pkcs12 (.pfx) certificates with a bundled Certificate and Private Key in the CertificateFile.

[bgrainger]

Sounds good. Is the backwards compatibility workaround (for consumers that are currently using CertificateFile with a PEM file) to just remove that option from the connection string (i.e., if there's no private key, it doesn't do anything anyway)? (That is, there's no need to add another DisableMutualAuthentication=true connection string option to be backwards-compatible?)

[caleblloyd]

Is the backwards compatibility workaround (for consumers that are currently using CertificateFile with a PEM file) to just remove that option from the connection string

That is correct

[bgrainger]

Fixed in 0.36.0.