certificate trust API for Windows

[shiftkey]

This is the second half of #9099 - adding the certificate trust API for Windows.

The Setup

I've configured a local IIS instance with a self-signed certificate to trigger this failure over HTTPS. Edge and IE don't like it, and spit this error out at the user:

I can write up the way to setup this environment locally if others want to test this flow out themselves. The sample app I've been using can be found here: shiftkey/electron-test-network-windows

User Experience

The magic in certificate_trust_win.cc is some code I've tested in isolation to resolve the above error. It installs the received certificate to the Trusted Root Certificate for the current user (not the local computer) and because we're only doing it for the current user it doesn't require elevation.

However, interacting with the trusted root certificate store will trigger this dialog when you invoke CertAddCertificateContextToStore:

It's certainly not as pretty (or as functional) as the macOS equivalent, but that might be okay for now. As a result I'm also not using the message argument that ShowCertificateTrust receives. I'm open to putting more context into this flow based on feedback and security concerns - this is just a first pass.

Testing

I'm currently at the point where the test app has the right IPC setup to trigger the certificate error, but I'm missing something with the "swap in a debug version" process and the dialog.showCertificateTrustDialog method isn't visible on Windows (there's nothing in the original PR to suggest this is being hidden deliberately).

Here's my flow for testing this PR (I've probably missed something):

• I added an #if defined here
• python script\bootstrap.py --msvs to get a VS solution file
• npm run build to get a debug build of my branch
• copy out\D\* to node_modules\electron\dist\

I can then run the test harness, attach to the electron.exe processes and VS loads the PDB symbols for electron.exe and node.exe.

UPDATE: there's something up with how electron.asar is being packaged for debug builds - I've repackaged that archive with the showCertificateTrustDialog method and I can launch the dialog in the app.

TODO

• test flow end-to-end in sample app
• refresh certificate database if added
• handle failure cases in ShowCertificateTrust gracefully, ensuring we cleanup any resources
• validate certificate chain and only work with self-signed or untrusted root certificate
• docs
• throw some more testing at it

[kevinsawicki]

Looks like a great start here, let me know if you have any questions or when it is ready to review,

[shiftkey]

@kevinsawicki I think the only issue I have at this stage is with the debugging experience:

I think I'm missing something with the "swap in a debug version" process and the dialog.showCertificateTrustDialog method isn't visible on Windows (there's nothing in the original PR to suggest this is being hidden deliberately).

Is there anything I need to be aware of when generating electron.asar?

[joshaber]

Or it looks like it's always a modal dialog on Windows?

[shiftkey]

This is probably getting way into obscure Win32 territory, but there's no way to pass a window handle to CertAddCertificateContextToStore to associate the popup message with a parent window - so modality isn't enforced here (that is, you can interact with the window without acknowledging the popup).

I need to tidy this these docs, but I also had a idea to show a dialog before this step with the message argument that the caller provides.

[joshaber]

Ahhhh I see 👍

[shiftkey]

I found myself off spending way too much time thinking about certificate chains and trust which we didn't really need to do here (only handle self-signed certs).

I'm going to throw some more testing at it in a live app to ensure I haven't missed anything but I think this is ready for a first round of reviewing.

[kevinsawicki]

Underscore case names (cert_context) are preferred, looks like there are several camel cases in this file currently.

[kevinsawicki]

Maybe an if block would make this a little more direct and concise, unless you are planning to add more cases to this block in this PR:

if (chainContext->TrustStatus.dwErrorStatus == CERT_TRUST_IS_SELF_SIGNED) {
  AddToTrustedRootStore(pCertContext, cert);
}

[kevinsawicki]

makign -> making

[kevinsawicki]

it's -> its

[kevinsawicki]

the -> The

[kevinsawicki]

Maybe expand a bit to mention browserWindow is ignored:

The `browserWindow` argument is ignored since it is not possible to make this confirmation dialog modal.

[kevinsawicki]

Left a few very minor style comments, code looks great otherwise 👍

[paulcbetts]

Are we sure that there isn't a Chromium version of this code? https://cs.chromium.org/chromium/src/net/ssl/client_cert_store_win.cc?q=CertAddCertificateContextToStore+package:%5Echromium$&dr=C looks promising

[kevinsawicki]

Hmm, I'm not seeing a public API in https://cs.chromium.org/chromium/src/net/ssl/client_cert_store.h?dr=C or https://cs.chromium.org/chromium/src/net/ssl/client_cert_store_win.h?dr=C to add a certificate to the store.

[paulcbetts]

Oh I just mean code that would be good for copy-pasting - any time you can copy-paste security code instead of writing it yourself it's a Good Thing

[kevinsawicki]

2013 -> 2017

[kevinsawicki]

I've configured a local IIS instance with a self-signed certificate to trigger this failure over HTTPS. Edge and IE don't like it, and spit this error out at the user

So I tried testing this using https://badssl.com via fetch('https://self-signed.badssl.com/') and the error status I got was CERT_TRUST_IS_UNTRUSTED_ROOT, so I'm wondering do you think that status should be handled the same as CERT_TRUST_IS_SELF_SIGNED?

[shiftkey]

@kevinsawicki yep, we can handle those two in the same way - looks like we get CERT_TRUST_IS_SELF_SIGNED when the certificate is tied to a specific domain, and CERT_TRUST_IS_UNTRUSTED_ROOT for a wildcard certificate that's untrusted.

[shiftkey]

Yep, I'm happy with the testing of this for those two scenarios above. Let me know if there's anything else left to do to get this merged 🤘

[shiftkey]

@kevinsawicki friendly bump 🤜

[kevinsawicki]

Thanks @shiftkey 👍

[coreybutler]

Correct me if I'm wrong, but it looks like this only supports importing certificates to the operating systems' trust chain? If this is the case, self signed certs will still throw up a nastygram in Firefox, which relies exclusively on its own certdb.

[shiftkey]

Correct me if I'm wrong, but it looks like this only supports importing certificates to the operating systems' trust chain?

Yes, because this is what an Electron app relies on for it's certificate validation.

[coreybutler]

Got it, thanks.

I have an Electron app that spins up local Express servers and generates self-signed certs on the fly. Handling trust chain support for the OS wasn't too taxing, but Firefox support was pretty gnarly... I was hoping for a cleaner approach :-) I may still use this for working with OS trust chains though.

Great work on all of this.