We have a java client (mule app) which is using hornetq client (v2.3.25.SP20) for connecting to the HornetQ remote server via the JNDI naming server (port 1099).
The connection is secured with SSL. The driver is requiring the javax.net.ssl.trustStore property to be set explicitly. Otherwise, it does not find the trust store.
We would like to specify a custom truststore for the session.
But setting a global property javax.net.ssl.trustStore may affect other applications. So, we are looking for the alternative.
I've coded a custom trust manager (X509TrustManager) which points to the custom truststore. But the issue is that it's used only for establishing connectivity with the JNDI server. Then, the actual connection object is taking the trust store location from the remote server (in case, of course, if javax.net.ssl.trustStore is not set).
The error HQ212007 is produced:
connector.create or connectorFactory.createConnector should never
throw an exception, implementation is badly behaved, but we will deal
with it anyway.
Unable to create NettyConnector for myserver:4447
Failed to find a store at remote server keystore location
Googling the error code, I've found very similar issue described with not solution provided here.
So, is there another way of specifying a path to a truststore for hornetq client when connectivng via JNDI, so, that it would not affect other applications running on the same VM system? Or, may be there is a way to disable the SSL certificate validation on the client side completely - this would work for us as well?
There are HornetQ-specific system properties to set SSL configuration parameters. Check out the documentation for HornetQ 2.4.0.
These properties were added after 2.3.0.Final but backported to the 2.3.x branch which is why they're available in 2.3.25.SP20 but aren't documented in the 2.3.0.Final docs.
In short, you can use these system properties instead of the global ones:
org.hornetq.ssl.keyStore
org.hornetq.ssl.keyStorePassword
org.hornetq.ssl.trustStore
org.hornetq.ssl.trustStorePassword
Related
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
I've created a Spring Boot application that I'm running as a poor man's daemon to call another Java service on another tomcat instance. I'm getting an SSL error when connecting to the other Java service but if I hit the other service with something like SoapUi(or Postman) using the same URL and headers I get an OK response. So something must be wrong with my Spring Boot configuration.
I'm using the same JKS for Spring Boot and SoapUI. I've tried using the cert in the application.properties as well as specifying it on the command line using -Djavax.net.ssl.keyStore as well as the related password parameter.
When I run the other service locally without SSL I can connect just fine via my Spring Boot application.
The SSL error I'm getting is: sun.security.validator.ValidatorException: Netscape cert type does not permit use for SSL server
Best I can think is that SoapUI(or Postman) identify's itself as a client application and my Spring Boot identifies itself as a server? So I think I'm asking how can I make Spring Boot identify itself as a client but I'm still not sure I understand the SSL error to begin with.
You have a multitude of problems. First off, soapui doesn't do verification of the server SSL certificate when it connects, java by default does not. You can however configure java client to also ignore server cert verification.
How to ignore depends on what client you use, apache httpclient is the most common one and you can find details on that in this thread.
Now, you should not really do that. Instead, you should have a trust store that contains the certificates that would validate the server cert. In that case you would be interested in truststore configuration, not a keystore - keystore is for other way around, when you're identifying yourself to some other party. You'd need to import the root CA and intermediate certificates to your trust store, then point to that in your configuration.
I'm using RoboMQ to build a MQ to MQ service over SSL. I've got a keystore (key.jks) and I'm setting the following system properties to configure the SSL:
javax.net.ssl.keyStore
javax.net.ssl.trustStrore
javax.net.ssl.keyStorePassword
However, our email server requires SSL and setting up SSL in this way in RoboMQ stops it from working - I guess because it overrides the default cacerts which has the certificates in that the email client needs.
How can I get these 2 things to play nicely together?
You are correct - setting the above system properties will override cacerts JVM
wide. You need to use a custom socket factory for the SSL MQ connections
The RoboMQ SDK provides support for this via:
com.am.robomq.sdk.camelSpring.RoboSSLSocketFactory
But the easiest way to build your Camel MQ endpoints is to use the MQ Connection Wizard:
http://www.robomq.com/product_manual/index.html#serviceBuilderPanel
It basically lets you to pick a connection factory from your connection palette
and then generates the Spring definitions needed by Camel.
I have done a lot of searches, but still can't find a solution.
In my projects, I'm using both Tomcat connection pooling and C3P0 connection pooling for postgresql. I rejected to use JDBC connection pooling because it's not suggested by postgresql officially.
Now I need to enable SSL/TLS on these pools. I thought this should be a pretty common need. I found examples on JDBC pooling, but not for tomcat or c3p0. I'm really wondering if tomcat and c3p0 poolings can configure SSL!
Does anyone have any resources on this topic that I can refer to?
SSL transport should be pretty much transparent to c3p0. just set up your postgres RDBMS to use SSL. the postgres JDBC driver supports SSL connections. if you are using a self-signed certificate though (rather than a certificate signed by one of the well-known certificate authorities), you'll have to either configure your JVM to recognize your self-signed certificate or the JDBC driver not to validate certificates.
You'll need to configure several postgres-specific JDBC Connection Properties. The easiest way to do this is by just appending the properties as standard URL-style params to your postgres-jdbc URL:
jdbc:postgresql://myhost.mydomain/mydb?ssl=true
Or (dangerously)
jdbc:postgresql://myhost.mydomain/mydb?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
Those should work if you are configuring user and password (as usual) via c3p0 configuration parameters. Alternatively, you can configure all of the Connection parameters in a Properties object. Here is how that would work for c3p0:
// obviously, imports should go where there should go
import java.util.Properties;
import com.mchange.v2.c3p0.ComboPooledDataSource;
// this is very close to the postgres docs
Properties props = new Properties();
props.setProperty("user", myUsername);
props.setProperties("password", myPassword);
props.setProperty("ssl","true");
props.setProperty("sslfactory","org.postgresql.ssl.NonValidatingFactory");
// this is c3p0-specific
ComboPooledDataSource cpds = new ComboPooledDataSource();
cpds.setJdbcUrl("jdbc:postgresql://myhost.mydomain/mydb");
cpds.setProperties( props );
// set any other properties you wish to override from values in config and/or defaults
The easiest way, I think, will be to just set jdbcUrl, user, and password in c3p0 config files and append ssl params to the end of your postgres jdbc URL.
Scenario: calling a client web service over SSL (https) with mutual SSL authentication. Different service endpoint URLs and certs (both keystore and truststore) for test vs. production environments. Both test and production environments run tomcat / JBoss clustered. Production environment has load balancing / BigIP, runs Blade and non-Blade machines.
Truststore is set (using -Djavax.net.ssl.trustStore=value) at startup. Keystore is set using System.setProperty("javax.net.ssl.keyStore", "value") in Java code. Web service call made using Axis2. All works fine in test environment, but when we moved to production environment (6 servers), it appears certs are not being forwarded for the handshake. Here's what we've done:
in test environment, handshake using test versions of certs has been working all along, with no ssl debugging enabled
confirmed in test environment that handshake with client production
endpoint succeeds (production certs,
both ours and theirs, are fine) --
this was done using
-Djavax.net.debug=handshake,ssl
confirmed that the error condition occurs on all 6 production servers
took one server out of the cluster, turned on ssl debugging for
just that one (with a restart), hit
it directly, handshake works!
switched to a different server without the debugging turned on,
handshake error condition occurs
turned debugging on on that second server (with a restart), hit it directly, handshake works!
From the evidence, it seems like somehow the debugging being enabled causes the certificates to be properly retrieved/conveyed, although that makes no sense! I wonder whether somehow the enabled debugging makes the system pay attention to the System.setProperty call, and ignore it otherwise. However, in local and test environments, handshake worked without debugging enabled.
Do I maybe need to be setting keystore on server startup like I'm setting truststore? Have been avoiding that because the keystore will differ for each of our test environments (16 of them).
Turns out that the debug setting was a red herring. What actually bit us was that there was an existing client with an SSL/basic authentication web service we call when one of their users logs in. Since in that context the keystore wasn't relevant, the javax.net.ssl.keyStore property doesn't get set -- but the SSL exchange still tries to load a keyStore (which ends up not loading any certs). Since, unfortunately, even if the javax.net.ssl.keyStore value is changed, it does not get reloaded, calls to the other client's web service sent along no keystore certs.
The solution was to set the keyStore property at server startup rather than at the point of the web service call. If at some point in the future we need to be able to use different keyStores in different contexts, it looks like we'd need to implement a custom SocketFactory.