I have osgi bundle which route message from webservice to remote ejb (on glassfish) by use of camel routing. In order to access remote jndi I need to set up truststore. How can I do that? Is it any configuration in camel route or I have to do it by system properties?
Without seeing your route, Have you tried the camel JSSE Utility?
you could try putting the following properties in the system.properties file within the etc folder:
javax.net.ssl.keyStore=<keystore location>
javax.net.ssl.keyStorePassword=<keystore password>
javax.net.ssl.trustStore=<truststore location>
javax.net.ssl.trustStorePassword=<truststore password>
Related
I am running a JMS point to point sampler for TIBCO EMS queue testing. I have added all the tibco ems jars to jmeter lib folder. Configured the queue details, context factory, user credentials in JMS sampler.
When hitting the TIBCO ems with tcp request for queue, it is working. But while hitting with SSL url it is failing to connect.
I tried below way to attach the Self signed certificate given by tibco team
added the .pem file (only begin and end certificate) to JAVA JDK cacerts file and opened Jmeter in command line with -Djavax.net.ssl.keystore=cacerts with password. The SSL request failed to connect with tibco ems server
extracted the certificate from server through openssl -connect commands, copied the begin & end certificate sections to .cer file and used keytool to add them to trustore. Started jmeter with this truststore. the JMS sampler still failed.
I understand the SSL certificate is not getting attached with JMS sampler when we are running it. Can some one help out with steps to successfully attached the SSL certificate to the JMS request.enter image description here
Looking into Configuring EMS over SSL on Application Servers I think you need to provide the following Java System properties:
com.tibco.tibjms.naming.security_protocol=ssl
jsse.providerClass=com.ibm.jsse2.IBMJSSEProvider2
com.tibco.tibjms.ssl.expected_hostname=xxxx
com.tibco.tibjms.ssl.enable_verify_host_name=false
com.tibco.tibjms.ssl.enable_verify_host=false
com.tibco.tibjms.ssl.trusted=/path/to/your/certificate.pem
The properties can either be put into system.properties file (lives in "bin" folder of your JMeter installation) or passed via -D command-line arguments like:
jmeter -Dcom.tibco.tibjms.naming.security_protocol=ssl -Djsse.providerClass=com.ibm.jsse2.IBMJSSEProvider2 ....
References:
Java Secure Socket Extension (JSSE) Reference Guide
TibjmsContext
TibjmsSSL
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line
I currently have a WildFly 9 cluster up and running with access to my application over port 8080, I would like to set up SSL and have access only on port 8443, but I cannot seem to find any documentation for where the security realm and https listener are placed in Domain mode.
I have the keystore and certificate all set up and was able to get https working in a demo using standalone mode, but I need to be able to do it in domain mode.
Can anyone help me out and share how they've accomplished this?
Solved it! It turns out for some reason JBoss was not registering my Security Realm and HTTPS listener. To do this you need to use bin/jbosscli and the commands:
RUN THE "CONNECT" COMMAND FIRST
/host=master/core-service=management/security-realm=SSLRealm/:add()
---where SSLRealm is the name of the realm
/host=master/core-service=management/security-realm=SSLRealm/server-identity=ssl/:add(keystore-path=Keystore.jks, keystore-relative-to=jboss.domain.config.dir, keystore-password=password)
---this assumes the keystore lives in the domain/configuration directory
Restart the server.
I then ran into issues figuring out the command to register the HTTPS listener, but I found the WildFly web console at serverURL:9990 has a way to do it too:
Once logged in to the webconsole
Configuration->Profiles->for each profile which is used->Undertow->HTTP->View
From there
HTTP Server->default-server->view
Finally
HTTPS Listener->ADD enter a name like: default-https, Security Realm: the name chosen for the security realm (for this example SSLRealm), Socket Binding: https and click save
Restart again
You should now have access at your serversURL:8443
To set it up on slave servers you should only need to copy the keystore to each slave servers domain/configuration and then add the security realm replacing /host=master/ with /host=slave/ in the command. And then restart the server.
Double check the Domain.xml file on the slave has the https listener you created originally in the webconsole (it should automatically be put into all of the clusters domain.xml files)
I have read the posts that are about this subject but I have not found any one that helps me.
I have an adapter that invokes a service using HTTPS.
It works if I do the SSL configuration using the server/conf/worklight.properties file with the properties: (after importing the backend server certificate in the default.keystore)
ssl.keystore.path=conf/default.keystore
ssl.keystore.type=jks
ssl.keystore.password=worklight
But if I comment those properties and edit the server.xml with this configuration:
<feature>ssl-1.0</feature>
<keyStore id="worklight" location="${server.config.dir}/default.keystore" password="worklight"/>
The adapter does not work and fails with the error:
Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
The "${server.config.dir}/default.keystore" file and "conf/default.keystore" file are the same file.
Is it possible to invoke https services from adapters in the Worklight Studio Liberty Profile Server without using the worklight.properties file and making the SSL configuration directly in the server.xml?
Worklight is not seeking SSL certificates in liberty key store. If the certificate is selfsigned it should be added to the keystore defined into worklight.properties or into default OS/JVM keystore.
I am planning to secure my jetty by SSL implementation. But I want to use my tomcat certificates, rather than the default jetty certificates. My jetty version is 8.x. I did a search on web regarding the ssl configuration on jetty. and i found this. Please suggest is it possible for me to use tomcat trustore instead of default jetty?
A java keystore is a keystore unless you are using some specific Tomcat implementation of a keystore. Jetty uses the default keystore bits that java itself provides, it should be a simple matter of configuring Jetty to look for the correct file, provide the necessary authentication bits to open it and any alias you may need to specify which key in the keystore to use. That documentation is for Jetty 9/9.1 and may be a bit different than the specifics for 8. You can get to the 8 documentation through the hub:
http://www.eclipse.org/jetty/documentation/
I'm using Spring Security for X.509 preauthentication.
To make sure the client sends its certificate per HTTP request, is it necessary to:
Modify pom.xml to set <wantClientAuth> and <needClientAuth> to true
Set Apache's SSLVerifyClient to require reference
Based on reading, the web server must tell the client-side to sends its certificate in order for the client to actually send it. I'm confused if Spring Security AND Apache configuration is required to achieve this.
Spring Security configuration has nothing to do with whether the client sends a certificate or not. That's decided at the SSL protocol level and hence by the negotiation between the client and the server. Your question is a bit unclear in that it refers to a maven pom and an Apache configuration without explaining how your system is set up. Are you running the maven Jetty plugin with an Apache server in front?
Spring Security's X.509 authentication won't work if the SSL connection doesn't terminate at the servlet container. So if you have HTTPS between the client and Apache, and a non-SSL connection from Apache to the servlet container, then the client certificate won't normally be available.
If you are using an AJP connector, then you can configure Apache to pass the certificate on to the back end using the ExportCertData option. If you aren't, you can still take the exported certificate and pass it as a request header (you'll find examples of this elsewhere on SO). You would also need to customize the Spring Security X.509 code to extract the certificate from the header, rather than the standard java property name which it uses by default.