9108599 created the issue

This is a duplicate of #8234, which has been closed as worksforme.

I have the exact same symptom and found the root cause. I will detail the root cause below and steps I did to resolve it. I have downloaded the source and modified it to get it to work.

Symptom: When trying to connect to a webdav server with two-factor authentication enabled windows is unable to find any certificates in the personal store to use to authenticate with, even when the root ca cert is installed in the trusted root CA path in windows cert manager.

Root Cause: The windows certificate manager uses EMAILADDRESS (tokenised as E=) in the distinguished name when querying for certificates. RFC1779 states that EMAILADDRESS should be emitted as a OID. The implementation of Keychain.cs uses X500Principal.RFC1779 to get the distinguished name of the certificate issuer. When the issuer root ca cert has EMAILADDRESS specified the resulting DN string uses the OID representation of EMAILADDRESS and so it never finds a corresponding signed cert that matches that issue DN.

Work around: Don't use EMAILADDRESS in the root ca cert or issued signed certificates (this is probably why you closed it as worksforme)

I have attached a modified Keychain.cs that I used to get it to work. I know my solution probably isn't the most robust approach, but for now it works for me. I simply took the issuer.toString and escaped the EMAILADDRESS= as E=, rather than using an X500Principal.getName call.

Attachments

• #8299.patch (16.3 KiB)
• Keychain.cs (14.7 KiB)