Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CertificateFile without Bundled Key does not use Mutual Authentication #436

Closed
caleblloyd opened this issue Feb 15, 2018 · 3 comments
Closed

Comments

@caleblloyd
Copy link
Contributor

caleblloyd commented Feb 15, 2018

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
Copy link
Member

bgrainger commented Feb 16, 2018

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
Copy link
Contributor Author

caleblloyd commented Feb 16, 2018

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
Copy link
Member

bgrainger commented Feb 16, 2018

Fixed in 0.36.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants