We have Web Service deployed on WebSphere 8.5 that needs to communicate with LDAP over ssl. The ssl communication works only when the ldap certificates are imported in JRE cacerts store.
For other services we use, the certificate can be imported in CellDefaultTrustStore from the console, however the LDAP communication does not work by simply importing the certs on console in CellDefaultTrustStore.
Is there a specific configuration required to avoid using cacerts ? Appreciate any help in this regard.
Here is the code snippet making LDAP connection [ variable names updated ]
Hashtable env = new Hashtable();
env.put(DirContext.SECURITY_AUTHENTICATION, "simple");
env.put(DirContext.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_PRINCIPAL, bindUserName);
env.put(Context.SECURITY_CREDENTIALS, bindPassword);
// this is the url with ldaps://hostname
env.put(Context.PROVIDER_URL, url);
DirContext dirContext = new InitialDirContext(env);
Unfortunately I do not know the details about how your LDAP connection is being made. If it's going to the cacerts file, it suggests the JSSE default SSL Configuration is being used. So something about the call is making it go to the JSSE default and not use the WebSphere socket factories.
You probably want to leverage dynamic outbound SSL configurations.
Configure a trust store when your LDAP's cert.
(You probably have this already).
Create an SSL Configuration for communicating with LDAP
using trust store from step 1.
Create a dynamic outbound endpoint configuration using
the host/port info of your LDAP. Reference the SSL
configuration from step 2.
Related
When I check the definition of "WebhookClientConfig" of API of Kubernetes I found comments like this:
// `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.
// If unspecified, system trust roots on the apiserver are used.
// +optional
CABundle []byte `json:"caBundle,omitempty" protobuf:"bytes,2,opt,name=caBundle"`
in WebhookClientConfig
I wonder to know, what's exactly the "system trust roots "?
and I'm afraid the internal signer for CSR API of Kubernetes is not one of them.
It is a good practice to use secure network connections. A Webhook-endpoint in Kubernetes is typically an endpoint in a private network. A custom private CABundle can be used to generate the TLS certificate to achieve a secure connection within the cluster. See e.g. contacting the webhook.
Webhooks can either be called via a URL or a service reference, and can optionally include a custom CA bundle to use to verify the TLS connection.
This CABundle is optional. See also service reference for how to connect.
If the webhook is running within the cluster, then you should use service instead of url. The service namespace and name are required. The port is optional and defaults to 443. The path is optional and defaults to "/".
Here is an example of a mutating webhook configured to call a service on port "1234" at the subpath "/my-path", and to verify the TLS connection against the ServerName my-service-name.my-service-namespace.svc using a custom CA bundle
I am setting up the tomcat server which communicate with external system through SOAP web services(I am using the external system stubs and apache Axis2 library for that).
The external system is secured with ssl client/server authentication. The system provides me keystore file in .pfx format which contains two certificates.
Things I have tried:
I have extract those two certificates and added in my keystore. I added below entry in my tomcat/bin/catalina.bat file
set JAVA_OPTS = %JAVA_OPTS% -Djavax.net.ssl.trustStore=/pathtomykeystore/cacerts -Djavax.net.ssl.keyStore=/pathtomykeystore/cacerts -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.trustStorePassword=changeit
With above configuration my request fails with No X.509 client certificate HTTP header found in request.
I have enable ssl logs then I found that serverHelloDone is printed and after that it says
"No suitable client certificate could be found - continuing without
client authentication"
The same thing I have tried from SOAPUI Tool where I directly configure .pfx file as keystore and it is working fine there
The diff between Tomcat and SOPAUI logs is
SOAPUI can successfully competing Client authentication where tomcat is not.
also below lines are missing from tomcat ssl logs
keystore is:
keystoreType is: jks
keystore provider is
Update1:
I remove the keystore configuration from SOAPUI->project view-> WS Security Configuration -> keystore (This is working configuration) and added above mentioned JAVA_OPTS entries in soapui.bat file and now SOAPUI also giving a same error.
Anyone helps arround how soap ui pick and send the certificates from keystore configured in project view->keystore
I am rather confused by the purpose of the trustore file in a tomcat server.
I.e use of the truststoreFile parameter when setting up a TLS enabled connector.
According to the tomcat docs:
truststoreFile
The trust store file to use to validate client certificates. The
default is the value of the javax.net.ssl.trustStore system property.
If neither this attribute nor the default system property is set, no
trust store will be configured.
To me this is telling me that for an inbound connection to my tomcat server, this is where I would store certificates that a client would present. (e.g. a users browser)
Would I really put in 3rd party CA certificates here or other 3rd party server certificates, if my tomcat server wants to make an outbound connection to a TLS enabled server (e.g. an LDAPS server)
As per my understanding the place to do this is the cacerts file.
Is my understanding of the truststore wrong?
Yes, you are right, it is quite confusing.
If you need to make an outbound connection a 3rd party, you need to add the certificates to cacerts.
There is a very popular "signing, validation, etc." service for government-owned companies here in Spain, #firma, that just changed its wildcard server certificate and we had to add it to cacerts.
Looking to port Outbound SSL configuration from Websphere to JBoss. In my case, JBoss is the client. It wants to pass a client cert to a remote machine as part of a 2-way SSL communication.
In Websphere, you explicitly specify...
keystore / keystore password (where are the certs?)
certificate alias (which client cert to apply?)
matching outbound url pattern (when do i apply the client cert?)
You may have many of these configurations. Between these 3 pieces of info, the container can selectively choose when/which client certificate to include when making outbound SSL calls.
What is the JBoss way of doing the same thing as I described above ?
Can this be done by simply configuring your JRE ?
Are there parts of this that cannot be done in JBoss and/or java?
Thanks,
Wade.
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.