Description of the Issue:
I am trying to connect to TLS 1.0 from the windows laptop to Windows IIS server. We have mutual authentication set-up at IIS.
Please see below the calls made for the handshake:
So it starts with client hello on frame no 4. And then in the next steps Server sends it’s certificate and ciphers are negotiated. And then on frame no 12, the handshake seems finished. And on frame no 13, client starts sending the application data.
But then again on frame no 14, Server sends a hello and we see a second handshake. Please can you answer my below query.
Question>> In mutual authentication, Client requests for Server Certificate. And then Server requests for the Client certificate. And when both of them has authenticated each other’s certificate, client starts sending application data. Isn’t this a normal process for mutual authentication?
Question>> On Frame 13, Client has already started sharing the application data. Then why is IIS asking for a second hand-shake on frame 21?
Question>> It seems the second hand-shake is for getting the client certificate ( Frame 24). But shouldn’t the Server ask for the Client certificate before frame 13.
In case you agree that this IIS behaviour is wrong, please can you suggest as how to fix this.
Thanks in advance.
This scenario happens if the server does not require mutual authentication for all resources but only when accessing specific resources. Thus:
The initial handshake without client certificates is done (frames 4..12).
The client sends the HTTP request (frame 13).
Based on the request the server realizes that the clients likes to access a resource which requires mutual authentication. The server thus requests a new handshake using the Hello Request (frame 14).
The new handshake is done, this time with client certificates (frames 15..25).
The server sends the HTTP response after the authentication of the client was successful (frames 26,29).
Related
I created a TLS server that authenticates the client, reads the client request and answers appropriately.
I want to test how my server reacts to bad tls handshake requests, errors and alerts. Is there a client that can test this on my server?
Thanks in advance
I'm working on an authentication method for my NodeJS API.
I'm using TLS certificates to verify the client connected to my API server.
My question is: can we have a way to authenticate the response back to the client? Can we use cert for this to(server to client)?
eg: When we call an API from our client we send the certificate with the request which is authenticated and if found valid the server sends the response, can we do it vice-versa, send a certificate in response and have the client validate the certificate.
The whole TLS protocol and the certificates are already built around this idea that you trust the server. I.e. the server during establishing of TLS connection provides a certificate that client can verify by checking if it trusts the CA that has issued the certificate.
Now while this is generally so, you can have libraries that allows to bypass this by not checking the certificate or checking but proceeding anyway, so you have to double check that is not the case. The browser does this automatically.
If you click on a green "Secure" button that is to the left in URL in Chrome e.g. you can click on "certificate" there and see the certificate that is provided by the server. If it's green, then it's trusted and all's good.
P.S. Neither the client not server sends the certificate the whole time back and forth with each request/response. They do it only once during establishing the connection that is called TLS handshake. It's relatively expensive process so you'd better keep the connection.
I am working on an M2M application where data volume is strictly limited and the mobile client has to set up at TLS connection frequently. Is there a standard way - or best practice - for the client to cache the server certificate chain such that the server does not need to send the entire chain on each connection setup?
I can think of a server that does not send along the (optional) certificate chain. The client proceeds as usual if it holds the chain in its local cache. But then, once the server certificates expire, the client must somehow tell the server that it has to send along the new chain.
Is there a possibility to configure popular TLS implementations in apache or ngix in the way described above?
Thanks very much for your help!
Uli
There is no way for the client to request the chain from the server on demand. There is a way to have a URL inside a certificate where it can get the issuers certificate, but then the client has to extract this URL and download the certificate on demand. Some desktop browsers do this, but most other SSL stacks don't.
But if client and server support session reuse, then the server has only sent the certificate and chain for the first connection in the session, but not when resuming a session.
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437
Based on the documentation Apache allows to request a client cert authentication for one directory and don't request it for another directory.
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients
How is it possible?
I assumed that first TLS/SSL does a handshake (including client certificate validation) and only after it, HTTP request is sent over secured channel. And this HTTP request contains a URL.
So, it looks like to get a URL (a diretory) you need to do (or skip) client certificate authentication.
So, it's not clear for me, how can Apache check URL first and decide later whether to request a client cert authentication or not.
It uses SSL/TLS renegotiation: the server sends a TLS Hello Request message to ask the client to trigger a new handshake by sending a new Client Hello message (and this time the server will send a Certificate Request after its Server Hello message).
The Hello Request message could in principle happen at any time during the HTTP exchange. For this particular feature, the server sends it just after receiving the request (therefore knowing which resource was requested), but before sending its response.