A
Avest-Systems
Guest
Hello.
We are monitoring windows insider preview to check in advance the updates that can cause incompatibility issues with our software and recently we have stumbled upon an unexpected issue: Internet Explorer (v11.1000.19608.0) can't reliably do https with a server if the latter requires clientAuthentication. When accessing the URL, IE is offering the user to pick up his personal certificate, as it always did before, than it asks for PIN to the smartcard with the private key, but then it is no guarantee that handshake will be successfully done - it may, and it may not, without any obvious predictability.
When such a handshake ends up unsuccessfully, we can see through server logs that client (IE) did not really provide user certificate (and TLS certVerify handshake message) in spite of fact that the certificate was chosen by the user and the PIN-code was provided.
As far as I can see, this first comes up with update specified in the title (10.0.19608). From our experience, older version, including all of the actual ones that are in circulation now don't show this kind of behavior.
It seems to me that there is smth with AcqureCredentialsHandle call, which no longer receives user certificate for SChannel credentials, even if certitifcate was chosen via GUI.
Can anyone direct me or suggest what am I doing wrong?
Continue reading...
We are monitoring windows insider preview to check in advance the updates that can cause incompatibility issues with our software and recently we have stumbled upon an unexpected issue: Internet Explorer (v11.1000.19608.0) can't reliably do https with a server if the latter requires clientAuthentication. When accessing the URL, IE is offering the user to pick up his personal certificate, as it always did before, than it asks for PIN to the smartcard with the private key, but then it is no guarantee that handshake will be successfully done - it may, and it may not, without any obvious predictability.
When such a handshake ends up unsuccessfully, we can see through server logs that client (IE) did not really provide user certificate (and TLS certVerify handshake message) in spite of fact that the certificate was chosen by the user and the PIN-code was provided.
As far as I can see, this first comes up with update specified in the title (10.0.19608). From our experience, older version, including all of the actual ones that are in circulation now don't show this kind of behavior.
It seems to me that there is smth with AcqureCredentialsHandle call, which no longer receives user certificate for SChannel credentials, even if certitifcate was chosen via GUI.
Can anyone direct me or suggest what am I doing wrong?
Continue reading...