We have an application running in WAS 8.5 server. The application has two external Service invocations, hitting 2 different third-party systems, in which one Service (Service2/Server2) requires Client Authentication.
Please refer the diagram for reference.
Server2 <-- Client --> Server1 Handshake Diagram
For Server1, we have shared a Client Certificate with them and the handshaking is perfect.
For Server2, which doesn't required Client Aunthentication, fails during handshaking. What we could find out that, during handshaking the server tries to authenticate the Client (Assuming that Client Authentication is SUPPORTED at Server2, but not REQUIRED). Since the Client KeyStore has the Client Certificate, it's being used for handshaking process, which is failing because this client certificate is not present at the Server2 Truststore.
My question is, whether is it possible to not send the Client Certificate to the Server2 even if the Server supports Client Authentication.
Hope this question is understandable.
Note1: We don't have any control over Server1 or Server2 and we don't expect any changes from these third-party Services to make this work.
Note2: Service2 works perfectly without Client Certificate in the Client Keystore. Please refer the diagram for Serer2-Client SSL Handshaking, which is perfectly working.
Client --> Server2 Handshake Diagram
Expecting help from someone who is proficient in Websphere SSL configurations.
Thank you,
Sanooj
In short:
You have to create 2 separate dynamic outbound SSL configs (see here for details) assuming your 2 external services have different URLs. The one that needs CertAuth will have cert in the keystore, the other will not have (you need 2 different SSL Configs).
Related
Is it possible to use Kafka with SSL encryption but with no server verification nor client authentication?
I know that by default the latter is disabled, but is it possible to also disable the former?
I encountered the similar problem. Since kafka is a java process, it will load the default jdk certs when running, which is under /usr/local/jdk/jre/lib/security/cacerts. if your server is trusted there, (in my scenario, my kakfa server is MSK, and is trusted already), then you don't have to config all the keys and certs.
So all in all, I only added kafka config of security.protocol=SSL and it worked.
What's the easiest way to get TCP Client/Server authentication via TLS/Certs/Keys in Go?
That is, I have a TCP server, and when a new client tries to connect to it, it should receive a certificate/key from the Server to allow it to connect again in the future without re-authenticating (or at least until the certificate expires). Both the client and the server should authenticate the other. OpenSSL isn't an option to create keys as the clients will be cross platform (Windows/macOS/Linux). Essentially, the server should only accept connections from known clients, and authorize new clients as needed (the clients can have some sort of known secret when installed).
Here's what I think the general flow is (correct me if I'm wrong)
Server: Get Cert/Key pair --> if they don't exist, create them --> listen on port --> receive connection --> verify Certificate is valid --> if not, reject --> if it is, continue to do what the server is supposed to do
Client: Get cert/key pair --> if they don't exist (i.e just installed), request from the server (Signed by the server) --> continue to connect as normal
This is still in the planning phase and open to all suggestions!
Thanks!
I am dabbling with WCF and SSL and have hit a bit of a problem.
I have a self-hosted WCF service and a basic client which connects to request a token.
I have it set up on my development machine it appears to communicating over SSL just fine.
But when I set it up on a different machine to test the deployment the client keeps getting nothing back from the service.
I assume it has something to do with the certificates I have set up as this is the only thing I think could be different.
I have used the netsh command to associate my port with an existing certificate that was already on the server. And it appears the same as my dev machine (where I created the certificate with makecert manually.
I initially tried to follow the same steps on the deployment server but failed as there was already a certificate with a common name of the server, so eve though the certificate generated when ever I tried to use the cert hash thumbprint of the newly generated certificate I was being given the :
SSL Certificate add failed, Error: 1312
A specified logon session does not exist...
The only way I could get the netsh http add to work was by specifying the cert hash of the existing certificate.
Is this my problem or a red herring? How do you debug issues like this?
Personally I just configure WCF tracing. It usually provides more user friendly info about a problem. Here's a how to link Configuring Tracing
Hope it helps!
I have a thick client written in VB6 that connects to an Sql Server 2005 Database. I want to secure the connection by using SSL between the client and DB.
I've looked at these links for details on "how to" configure it.
http://msdn.microsoft.com/en-us/library/ms189067%28SQL.90%29.aspx
Question
If I want to buy an SSL certificate to use in this scenario, do I just buy the standard SSL certificate sold for websites? I would imagine so, but I want to make sure.
I guess SSL certificates are standard and can be utilized anywhere as long as the client and server know how to use that protocol.
But in case I do buy a standard SSL certificate, what do I mention as far as my website domain address etc? - Since I'm going to use it between thick VB6 client and SQL Server 2005, I wasn't clear how to go about this.
Is there any other (easier) way of securing the connection between a thick client and Sql Svr DB? My requirement is to only make the connection secure....it doesnt have to be SSL.
Thanks
Amit
You need to use a certificate trusted by the client. You can choose between using one of the trusted certificate authorities (VeriSign, Thawte, GlobalSign) or deploy a root of trust on your clients. The DB client validates the certificate the same way all SSL certificates are validated, by verifying the Subject against the name used by the client to connect.
Given that a normal DB deployment you know what your clients are, then it makes a lot of sense to pre-deploy the certificate used on the client and save yourself the cost of a true SSL system trusted authority signed cert.
If your DB clients are open ended and can add themselves at will, then it doesn't make sense to have them connect to the DB directly. Point is that there must be a deployment step (a Setup) that adds the new client to be trusted on the back end, and this step can also deploy your own root certificate as a new trusted root on the client, or, if the client is paranoid about adding an entire root, just the certificate used by the server as a trusted cert.
I am trying to write a java application connecting to server connection channel with SSL enabled.
So far, I have been successfully connected to the channel by setting authentication to 'optional'. However, when I set it to be 'required', the connection fails.
Here is what I did:
Create key db for queue manager and keystore for the java client user.
Create key/self-signed certificates for the queue manager and the client user, with names prefixed ibmwebspheremq.
Export, exchange and import certificates for the queue manager and the client. (I did answered 'yes' when being asked whether I trust the queue manager cert).
The location and password to the truststore and keystore are set to point to the same keystore at the client side, where the orgininal created client user key and the imported queue manager key are.
With other settings being the same, if I switch back to 'optional' authentication, the connection works.
I think there is something I understand incorrectly about this ssl authenticaion but cannot figure out what.
Could someone kindly help me?
I beat my head against that wall for a couple of weeks. IBM L2 Support eventually clued me in. My issue here was that keytool will use DSA algorithm unless you specify RSA. This results in keys of length 1022 instead of 1024, which WMQ doesn't like. The fix was to specify -sigalg RSA when generating the certificate and everything works.
I've asked the IBM WMQ team and WMQ FTE team to add this to their Infocenter documentation.