Yes. I have to delete all such certificates in the popoup not just myphone to get it to work. Browsers only show the certificate selection UI when they have valid candidate client certificates to offer.

After seeing that behavior I read up on why this happens.

The issue is caused by IIS configured to send a TLS CertificateRequest before the handshake.
Once a connection has been established for the first time for a browser, IIS doesn't reissue that request. Also if the browser has no client certificates to offer, it doesn't launch the popup and sends back that it has no certificate to provide.

Its likely that under SSL Settings in IIS, client certificate requests are set to "Accept". This is because clicking cancel gives you access to the website and deleting all client certificates also works. If it was set to "Require" it would block access entirely. Most websites would set this to Ignore, unless they have a valid reason to request a client cert, which is usually on corporate intranets with special authentication requirements. That's the most likely suspect causing the issue, but there could in theory be something else causing the server to issue the CertificateRequest

If neither the sever has it's issue, nor the client has it's issue, the client can connect.
If the server has it's issue, but the client doesn't, the client can connect.
If the client has it's issue, but the server doesn't, the client can connect.
If the client has it's issue, and the server has it's issue, then the client can't connect.

So the problem is due to issues with both the client and the server, but both need to be present for the client to be unable to connect.

---

Grant
Darwin NT, Australia.

Different Systems and OS's all trying to access Gerasim.

Bill F
Can you list the specific operating systems that have this problem?

I'm interested in:
If it's Windows, what's the result of the "ver" command (it needs to be run in cmd).
If it's Linux/Unix, what's the result of the "uname -a" command.

k29000
Have you tried my recommendations?

@ Demis...

I only have access to one System tonight ...


Microsoft Windows [Version 10.0.26200.7840]

Thanks
Bill F

If neither the sever has it's issue, nor the client has it's issue, the client can connect.
If the server has it's issue, but the client doesn't, the client can connect.
If the client has it's issue, but the server doesn't, the client can connect.
If the client has it's issue, and the server has it's issue, then the client can't connect.

So the problem is due to issues with both the client and the server, but both need to be present for the client to be unable to connect.

That's correct.

There's another option: a man in the middle (MITM) interfering with the connection (specialized DPI equipment).
But I'm not yet ready to say that this is the problem.

I showed above (in the Curl program) how the connection works within our country (Gerasim's server and I are in different cities and have different providers. Sometimes I can't even connect to the server for administration. Meanwhile, an external resource, outside the country, shows the server is online when tested. But at that moment, neither the site nor the connection works for me.)
Let's see what information k29000 will hopefully give us.

@ Demis...

I only have access to one System tonight ...


Microsoft Windows [Version 10.0.26200.7840]

Thanks
Bill F

Ok.

Have you tried my recommendations?
(https://numberfields.asu.edu/NumberFields/forum_thread.php?id=667&postid=4215)

k29000
I have one more request for you:
Please show the output of the command:

curl -I https://gerasim.boinc.ru

(run from cmd, no need to elevate privileges)

* Connection #0 to host gerasim.boinc.ru:443 left intact
[/code]Phrase at the top:

schannel: disabled automatic use of client certificate

Seems to refute your last assumption (if I understand correctly).

My output is the same as yours. The schannel message means Schannel will not choose a client certificate automatically from the Windows certificate store if it is forced to supply one. It will require manual selection or approval. You can change that setting. Disabled is the default.

curl doesn't help us understand whether the server is requesting a certificate or not unfortunately. It also doesnt show us how strict the server is in the cases where one isn't supplied. curl is not verbose enough.

Connections in curl will work just fine, like web browsers after the first request or when the client has no certificates, because the server seems to be giving the opportunity for a client certificate to be optionally supplied, not requiring it.

I dusted off my Wireshark mental cobwebs because the only way we can see whats happening is to look at the packets for the handshake.
At first when I looked, none of the packets showed any Certificate Request as part of the handshake.

I then found a very old deleted blog post that explained that the way IIS implements client certificate requests, if it is configured to do so, is an initial handshake establishes an encrypted TLS connection, then the certificate request will happen in an encrypted channel, then the handshake will be renegotiated.

For reference, in case I need to dig this up again: https://web.archive.org/web/20160111233743/http://blogs.technet.com/b/nettracer/archive/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication.aspx

So then I configured wireshark to decrypt the traffic after establishing the first handshake and I was able to find the CertificateRequest.

Here is a video. This one I am talking, so make sure to have audio.
https://www.dropbox.com/scl/fi/zxg4dh54gpdmt1of12k5t/Gerasim-handshake-traffic.mp4?rlkey=hbls52i8mj8siv7swb4gui6v1&st=r1nzfk52&dl=0

My output is the same as yours.

Perfect!

The schannel message means Schannel will not choose a client certificate automatically from the Windows certificate store if it is forced to supply one. It will require manual selection or approval. You can change that setting. Disabled is the default.

Yes.
And let's note that it was the server that responded this way.

curl doesn't help us understand whether the server is requesting a certificate or not unfortunately. It also doesnt show us how strict the server is in the cases where one isn't supplied. curl is not verbose enough.

You're wrong about that.
And I can prove it.

Based on my information in the post:
https://numberfields.asu.edu/NumberFields/forum_thread.php?id=667&postid=4231

I will only use key lines from top to bottom.

We see:
1. After "Trying 79.164.218.120:443" we see "* schannel: disabled automatic use of client certificate"

2. "* Established connection to gerasim.boinc.ru (79.164.218.120 port 443)" - The connection has ALREADY been established, i.e. the SSL keys have been verified.

3. "* schannel: SSL/TLS connection renegotiated" - A re-negotiation occurred, this is normal (possibly a network error, the influence of DPI, the influence of other factors.)

4. "HTTP/1.1 200 OK" - This is already the server’s response and we see 200, that is, it was transmitted within a secure communication channel.
Otherwise there would be a 403 error here.

5. "Content-Length: 16093" - This is the current size of the page transferred from the server to the client over a secure channel.
That is, the data has arrived in full.

6. "* Connection #0 to host gerasim.boinc.ru:443 left intact" - We see that the SSL session remains open. (I didn't give any recommendations on how to close it immediately.)

Please be careful.
This is very important in the technical part.

You could check for yourself that the MS curl includes the SSL session with the prefix "https".

curl --help
curl --ssl-reqd -I https://gerasim.boinc.ru

and

curl -I https://gerasim.boinc.ru

They have the same response.

Connections in curl will work just fine, like web browsers after the first request or when the client has no certificates, because the server seems to be giving the opportunity for a client certificate to be optionally supplied, not requiring it.

I dusted off my Wireshark mental cobwebs because the only way we can see whats happening is to look at the packets for the handshake.
At first when I looked, none of the packets showed any Certificate Request as part of the handshake.

I then found a very old deleted blog post that explained that the way IIS implements client certificate requests, if it is configured to do so, is an initial handshake establishes an encrypted TLS connection, then the certificate request will happen in an encrypted channel, then the handshake will be renegotiated.

For reference, in case I need to dig this up again: https://web.archive.org/web/20160111233743/http://blogs.technet.com/b/nettracer/archive/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication.aspx

So then I configured wireshark to decrypt the traffic after establishing the first handshake and I was able to find the CertificateRequest.

Here is a video. This one I am talking, so make sure to have audio.
https://www.dropbox.com/scl/fi/zxg4dh54gpdmt1of12k5t/Gerasim-handshake-traffic.mp4?rlkey=hbls52i8mj8siv7swb4gui6v1&st=r1nzfk52&dl=0

I heard your comments in this video.
I've watched it several times.
So far, all I see is what I said earlier.

Moreover, last weekend I was visiting friends.
And I checked on their computer.
Yes, there was this certificate request.
It was checked in Mozilla.
I even took screenshots.
The problem was solved using the method I described earlier.

The schannel certifiicate disabled message is not a server-side setting. It controls client side behaviour to certificate requests

if you wish to see how the client behaves with it enabled, you can toggle it on with: curl -I -v --ssl-auto-client-cert https://gerasim.boinc.ru


Earlier I agreed that deleting all client certificates works.
But it is only a workaround and not the cause of the problem. The server shouldnt be asking the browser to launch the certificate prompt when client certs are available. IIS is sending an optional Certificate Request which is what I show in the video.

It should not be doing that. Did you check the IIS setting I mentioned in an earlier message?