We have a websphere application that must connect to a webservice over https. Websphere Application server has version 8.5.5
We have the wsdl of the service, so we were able to create the client using the JAX-WS wizard in eclipse 4.5.
The SSL connection requires both accepting the server certificate and authentication with client certificate (private key).
The restriction we have is that the SSL configuration must be at application level, and not at server level. In a first time we were able to configure the server with the repective certificates in the default truststore and keystore, but that configuration was not accepted.
So we created a SSL configuration with a keystore that includes both the signer certificates of the server of the webservice and the personal certificate (with the private key) of the client. Type is JKS.
We suppose that we have to create in some way a "Web services Client security bindings" in Applications > Application Types > WebSphere enterprise applications > application_name > Manage Module > module_name > Web services: Client security bindings, but that list is empty:
Currently when we try to test the service client we get the exception:
exception: javax.xml.ws.soap.SOAPFaultException:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
You need to import the SSL certificate into the Web SPhere truststore, you can do it from here:
Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Retrieve from port
or
You can directly upload the certificate from:
SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Add signer certificate
Hope this solves your issue.
Related
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've read quite a few articles on the client certificate authentication in IIS but they mostly talk about the Required mode for the client certificate. In this case, the authentication is fully done on the web server side and the user is redirected to the error page in case the certificate is missing or invalid. What I need is to configure IIS to check the client certificate if it exists and pass the results as http headers to my backend. It can be easily done with nginx or apache web servers. The client authentication can be set up as optional. Then, the web server checks the certificate and pass the results of the check as SSL_CLIENT_CERT (PEM representation of the certificate) and SSL_CLIENT_VERIFY (the result of the check - SUCCESS, NONE,...) headers to the application backend. So, on the backend part, I can read the headers and use the values to do the actual authentication -- find a user in the database, issue an auth token. Is it possible in IIS? If yes, is there any documentation on how to bypass the certificate and the check state as http headers?
After a while, I'm writing an answer to my question.
IIS has to be set up with ARR extension to act as a reverse proxy. Then, the client certificate authentication can be enabled for the default web site. Here are several links to instructions how to achieve it:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/06/02/configure-application-request-routing-arr-with-client-certificates/
https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-with-client-certificate/
and couple of links to very solid explanations of the SSL/TLS handshake and certificates in general:
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
https://blogs.msdn.microsoft.com/kaushal/2013/01/09/self-signed-root-ca-and-intermediate-ca-certificates/
https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/
Basically, the Application Request Routing (ARR) extension should be enabled for the IIS to act as a proxy. Then, you set up proxy bypass routes. Next, you need to set up a valid server certificate for the IIS server and use it in the Default Web Site https bindings. The certificate should be issued by a CA which certificate should be placed into the Trusted Root Certification Authorities and Intermediate Certification Authorities of the Local Computer. Then, you should require SSL in the SSL settings of the Default Web Site with the client certificates setting equal to Accept. In this case, any client that connects to the web server will be asked for a valid client certificate that has been issued by the same CA as the server certificate.
Actually, IIS sends a list of distinguished names of root issuers that are trusted by the web server to the client browser. The browser finds an intersection of this names with client trusted certificate issuers and looks for valid certificates that have been issued by the issuers in the intersection. After that, the user selects one of them (or none) and the selected certificate is checked against the CA certificate. If the certificate passes the check the request is "redirected" to the backend application with the certificate in the X-ARR-ClientCert header. The name of the header can be changed in the Server -> Configuration Editor -> system.webServer/proxy -> clientCertHeaderName IIS parameter. In case the user selects (or has) none of the required certificates, the request is "redirected" to the app backend without the header.
Seems, there is no need in the SSL_CLIENT_VERIFY header with the state of the check at all. If the certificate is valid it is passed in the header. If the certificate is missing the header is empty. If the certificate is provided by the client but is invalid then the request fails and is not "redirected" to the backend app server at all. Seems, it is a rare case but I have an example.
Imagine, a server certificate is issued by a CA with a distinguished name XXX, and there is a client certificate YYY (on the client computer) that is issued by a CA with the distinguished name XXX but those CAs are not the same (one or both of them are self-signed). In this case, the YYY certificate is present in the certificate selection dialog that is shown by a browser but the certificate doesn't pass the further validation against the real web server CA.
That's it. Also, seems IIS has no way to require (or accept) a client certificate for some app endpoints (addresses) only. I haven't found any other option apart from enabling in for the whole web site.
IIS ARR can also be configured with a client certificate for the backend or upstream server. In this case users connecting to this IIS do not need to provide the certificate as it will be attached by IIS automatically.
This configuration is available on IIS server level only.
During the testing of the Travelocity sample application at Login screen, option2 OpenID, I get the following error at the client side:
0x704: I/O transport error: peer not authenticated
Any recommendation about the required steps to activate SSL protocol
support in the Travelocity sample application running under the Tomcat7?
More details from the Tomcat7 log:
SEVERE: Servlet.service() for servlet [ForwardingServlet] in context with path [/travelocity.com] threw exception [0x704: I/O transport error: peer not authenticated] with root cause
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.ibm.jsse2.ab.getPeerCertificates(ab.java:61)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at ...
Thanks for assistance.
As WSO2IS contains a self-signed certificate by default, So you need to configure its certificate as a trusted certificate to the sample application. We can configure a truststore file for the Tomcat server. you can add following two java parameters in to the "catalina.sh" file in /bin directory.
export JAVA_OPTS="-Djavax.net.ssl.trustStore=<PATH_TO_TRUST_STORE_FILE> -Djavax.net.ssl.trustStorePassword=<PASSWORD>"
As an example. Please note that the PATH_TO_TRUST_STORE_FILE file must contains the WSO2 server's certificate.
If your WSO2 server's certificate's CN value is not equal to the WSO2 Server's hostname, you would be probably hit by following error as well
hostname in certificate didn't match: !=. So, you need to make sure CN is equal to hostname as well.
I'm trying to set up a WCF-service with SSL on Azure.
Can someone please explain a bit about the differences of using certificates is these cases?
Certificate for https-binding in IIS
ServiceCertificate in Web.Config
ClientCertificate in Web.Config
Certificate in ServiceDefinition.csdef
Certificate in ServiceConfiguration.Local.cscfg
Certificate in ServiceConfiguration.Cloud.cscfg
More I should know about?
I want to publish several service-endpoints within the same role, some with SSL and some without. Do I need binding-certificates at all or is it service-certificates I should use?
Start by reading WCF Transport Security with Certificate Authentication and Configuring SSL for an application in Windows Azure
Certificate for https-binding in IIS - exactly what it says, the cert is used by IIS to create a secure binding on a site/service, typically on port 443
ServiceCertificate in Web.Config - WCF service-side binding cert used for WCF Transport Security with Certificate Authentication - private key cert used to authenticate client request signed with the corresponding public key
ClientCertificate in Web.Config - WCF client-side binding cert used for WCF Transport Security with Certificate Authentication - public key cert used to sign a request for authentication to a service using Transport Security with the corresponding private key
Certificate in ServiceDefinition.csdef - default certificate used to create a secure endpoint in Azure worker & web roles. NOTE: This is the certificate Azure installs in IIS to bind to the service endpoint (see #1)
Certificate in ServiceConfiguration.Local.cscfg - same as 4, just used in a "Local" build/deployment configuration
Certificate in ServiceConfiguration.Cloud.cscfg - same as 4, just used in a "Cloud" build/deployment configuration
I am using jboss as the server and my java program as the client, I have modified the server.xml file in jboss to send certificate from server to the client. this happens automatically, when the requesting client has the same domain as the domain in the server keystore.
But I want the jboss server to validate the client certificate also. How can I send the client certificate to jboss and receive it in jboss?
You are trying to achieve a two way ssl so lookup "jboss two way ssl".
The steps would be similar to setting up ssl on the server ; the only difference would be that you would need to import the client cert into the server truststore (assuming the client cert is self-signed).