Secure WebSockets - possible documentation issue

[apdevelop]

In the Secure WebSockets (wss://) documentation block the x509 certificate containing a public and private key is noticed, but the following code example doesn't have password argument, which is needed for getting certificate data: new X509Certificate2("MyCert.pfx") instead of new X509Certificate2(string fileName, string password)

Or is it possible to use .pfx certificate without providing password ? Getting it from certificates store, for example (using X509Store.Certificates.Find()) ?

[statianzo]

@apdevelop Thanks for pointing that out. The code sample is an example that WebSocketServer.Certificate accepts an X509Certificate2. A password isn't necessary if your private key doesn't have a password. In your use case, you're correct that you'd need to pass the second argument to the constructor.

[apdevelop]

Well, some clarification about optional password would be useful. Because the standard way of exporting certificate to .pfx file with private key (using Certificates MMC snap-in) requires entering password (Probably I'm wrong somewhere).

[StevenBonePgh]

You can also get the cert from the store and use it, as you pointed out, as long as the private portion of the key is stored. In the snap in it will display a key icon next to the certificate icon - the general tab says 'You have a private key that corresponds to this certificate'. You can store just the public cert and not the private key in the store in which case no key icon or private bits can be retrieved from the store.

The .pfx file format provides the optional ability to protect the private key stored as part of the certificate file with a password. When importing a password protected .pfx file you provide the password just so the key can be extracted - the password is not kept anywhere once the private key is decoded.

The store protects the private key by the user permissions that call into the store apis based on user/machine stores, etc. When you get the cert from the store, therefore, no password is required. When you keep the cert in the store you are delegating responsibility for securing it to the store.

I don't see this as a doc bug, as getting an instance of the X509Certificate with both keys is more a .NET level documentation thing than a Fleck thing. In fact, it is remarkable that the need to have both keys is documented as that would be 'obvious' to anyone familiar with crypto. But, yes, much more often than not .pfx files are stored with a password in production use.