I am trying to workout how to configure a CXF consumer to use https, but use basic authentication.
I presume we need to attach our certificate using the httpj:engine-factory but whenever I try and do that the server generated the follwing error:
javax.net.ssl.SSLHandshakeException: null cert chain
EDIT: I believe what is happening is that the server is requesting a client certificate, but the client does not send one. For "One Directional" SLL, I don't think the server should be asking for a certificate from the client.
How do I prevent the server from requesting a client certificate?
Any assistance greatly appreciated.
You need to install certificate in your JVM trust store. Please go through below link:
How to solve javax.net.ssl.SSLHandshakeException Error?
It turned out to be quite simple. In the httpj:engine-factory, there is a setting for client authentication.
<sec:clientAuthentication want="false" required="false"/>
This controls whether the server requests a certificate from the client. I had copied this from samples with Bi-Directional SSL and these values were set to true.
Related
Hey everyone and thanks in advance for any feedback you might have on this.
Got a web application that is trying to authenticate an AD user via LDAPS. The application server in this case being the client and a DC with LDAPS being the server, during TLS handshake, client certificate authentication is requested by the DC and this process takes quite a long time to complete as it seems it is trying to iterate over each certificate that has "Client Authentication" enabled (and there are quite a few of them to go over).
Is there any way on the client (the web app server running Windows) to "force" or "suggest" what certificate gets presented first? If not, is there any way on the server (the DC with LDAPS enabled) to specify that the server only wants to see certificates from a specific CA?
I have had a look into TLS negotiation documentation and so far was not able to find an answer to this question.
The LdapConnection class has a SessionOptions property allowing to set a handler named QueryClientCertificate which can then return a certificate to use.
I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.
We have a web server running on linux machine where we configured 'SSLVerifyClient' as 'require' in ssl.conf file.
Does this needs client who is utilizing the service from web browser(like firefox or chrome) needs a certificate.
If yes, then it is not possible to distribute client certificate to every user as there can be some thousands of users, how to overcome this problem.
If no, then how the data passed over network is secure? I know that certificate helps in encrypting data so that no one who don't have certificate can read data.
Please help me in clarifying my doubts
If you don't use client certificate, the https connection is still safe:
Only the client and the server can read/write the content
The identity of the server is assured by a certificate authority
Client certificate only give you client authentication in the beginning of the connection. To encrypt the data, the public key of the server is used in the beginning (See public key encryption).
If you identify the client with cookies set after login/password submit, it is still safe: you have identify the client.
When SSLVerifyClient is set to require, the client MUST pass a client certificate. You would generate these via OpenSSL, and sign them with a certificate authority that you install via SSLCACertificateFile.
How you distribute those certificates is an issue you'll have to solve yourself.
So I encountered this issue (which I managed to resolve), and wanted to share the problem and solution, in case someone will experience the same issue.
The problem:
I configured a site on IIS 7 to require SSL and require client certificate, due to a need to implement a 2 way SSL.
I noticed the client certificate is sent from the client (I did this with sniffing wireshark packets).
The IIS server returned 403.16 Client Certificate Untrusted or Invalid.
Additional information:
The issuer of the certificate was in the trusted CAs store.
What else can cause this issue?
In my case,
The issue was with the enhanced key usage of the certificate, that was set to "server authentication".
When I issued the certificate, via the CA server of my org, I used a predefined web server template that had set the key usage to the above.
Issuing a new certificate with "client authentication" usage resolved the issue for me.
Hope it will help someone else who encounters a similar issue.
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