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.
Related
I created a message flow having rest request node to connect to an API. API security enabled received the following error:
BIP3165S: An error occurred whilst performing an SSL socket operation.
Operation: connect. Error Text: javax.net.ssl.SSLHandshakeException:
com.ibm.jsse2.util.j: PKIX path building failed:
com.ibm.security.cert.IBMCertPathBuilderException: unable to find
valid certification path to requested target.
How do I solve this issue in my message flow?
I disabled SSL but still received the same error.
What is the SSL client and server endpoints? Assuming this connection is:
WAS (server) <------SSL------> API (Client)
In one-way SSL, the solution is to add the root or intermediate certificate (from the WAS server's chain) to the client's trust store.
"PKIX path building failed" usually indicates that the SSL client was unable to authenticate the SSL server (remote host). To authenticate the server, the client needs to have the server's root or intermediate certificate in its trust store.
If this is happening with traditional WebSphere as the client, we can try to add the signer certificate with retrieve from port.
If mutual authentication is enabled, the issue can be with the server being unable to authenticate the client.
Either way, an SSL exception should not occur with SSL disabled. Maybe the server wasn't re-started after disabling SSL? Maybe SSL wasn't disabled correctly (on both endpoints)? Maybe the API was still trying to use HTTPS with SSL disabled?
I've been attempting to get mutual authentication working between Keycloak and OpenLDAP. I've configured the truststore on Keycloak under security realms, which works. I can view the certificate on requests. I've also configured OpenLDAP's truststore/keystore and set it to demand a client certificate. When using ldapsearch I can provide Keycloak's cert which allows me to connect. I've also verified that Keycloak accepts OpenLDAP's cert by changing OpenLDAP to not demand a client certificate, which allows Keycloak to connect (albeit after fixing the truststore). At this point, it appears everything is fine except Keycloak doesn't present it's certificate while acting as a client, and I get the following error in OpenLDAP.
TLS trace: SSL3 alert write:fatal:handshake failure
TLS trace: SSL_accept:error in error
TLS: can't accept: error:140890C7:SSL routines:ssl3_get_client_certificate:peer did not return a certificate.
Unfortunately I cannot share details about the configuration or environment beyond the above due to project constraints.
I am trying to connect to a t3 url which I am told has a blank username and password but, I don't know how to pass an empty username and password in the connect() call. How can I do this?
When I do connect('', '', 't3://hostname:port'), WLST tries to connect to the given url using username 'weblogic' which I don't know where it is getting from?
--- UPDATE ---
Please ignore the above... See Sandra's comment.
The script I am trying to run is the one shown in WebLogic Server JMS WLST Script – Who is Connected To My Server. Although I have lightly modified it to pass username, password and url as arguments into the script...
I have saved the script to a file named: listJmsQueueConsumers.py and I run the script as follows:
$ source /opttest/bea/wlserver_10.3/server/bin/setWLSEnv.sh
$ java weblogic.WLST listJmsQueueConsumers.py "username" "password" "t3://ip-address:port" where, the username, password and url are the admin's username, password and url pointing to weblogic server's administrator port.
Now, when I run the script, I get the following error:
Caused by: java.net.ConnectException: t3://ip-address:port: Destination unreachable; nested exception is:
java.net.SocketException: Connection reset; No available router to destination
I have also tries running the script with the same url but using protocol t3s and, when I run the script using t3s, I get:
Caused by: java.net.ConnectException: t3s://ip-address:port: Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException: [Security:090542]Certificate chain received from bc2-06-v1.compass.cnsonline.net - ip-address was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.; No available router to destination
I am pretty sure the ip address and port I use are the server's ip address and administrator port but I am not sure what the errors actually mean. Do I need some sort of SSL certificate to connect via t3s protocol?
You will need import the certificate from the WebLogic server to the local keystore being used by your local Java client JVM. I use a tool called KeyStore Explorer (http://keystore-explorer.sourceforge.net/) to do this. Other good options are listed here How to properly import a selfsigned certificate into Java keystore that is available to all Java applications by default?
My application requires client authentication for a specific URL, after client authentication succeeds the application itself also does some verification on the client certificate subject (using spring security x509 filter). I wanted to configure tomcat to force client authentication (clientAuth=true) for the specific URL, but based on this post it seems I can't do this only using tomcat - configure tomcat for client authentication only for specific URL patterns.
My question is, if I use clientAuth=want, will the following be as below when the server requests a certificate:
If device has an identity certificate but not trusted by the CA configured in tomcat truststoreFile, no certificate will be passed and the request will fail in the spring security filter (certificate will be null)
If device has an identity certificate trusted by the CA configured in tomcat truststoreFile, but is invalid (not sure what validations are done) or expired, either the authentication will fail in tomcat (before the security filter) or as in option 1 no certificate will be passed and the request will fail in the spring security filter (certificate will be null)
Is there a security hole I may be missing using this configuration of want + security filter? I guess the question is - if a certificate is eventually passed from the device to the server, the server will always validate it (not expired, trusted etc) even when using clientAuth=want and will not allow the client to continue if the certificate is invalid? The case where no certificate is passed is covered by the security filter that will check the certificate is not null..
Thanks!
Your assumptions in both 1. and 2. are correct. Tomcat will not allow untrusted or invalid certificates through to your application. If you get a null certificate, you can assume that either no certificate was passed, or an untrusted/invalid certificate was passed.
On the project I am working on we have the same requirement as you: client certificates for certain URLs only. We found out by experimentation how "clientAuth=want" works.
I am trying to run a test of the SAML2 SSO using WSO2 Identity Server 4.0.0 M7 but am not successful.
I tried to use the 3.2.3 binary but ran into the bug about long hostnames and the identity.xml file (http://stackoverflow.com/questions/9600392/unable-to-configure-wso2-identity-server-for-openid).
These are the examples I'm using:
http://sureshatt.blogspot.com/2012/08/saml20-sso-with-wso2-identity-server.html
http://wso2.org/library/articles/2010/07/saml2-web-browser-based-sso-wso2-identity-server
I've stood up a new Tomcat7 server and configured it for HTTPS, which works cleanly in the browser. The certs are signed by our trusted enterprise CA and both the private key and chain certs are installed.
Same for the WSO2-IS host which has a new wso2carbon.jks with the private key signed by the same CA. I've exported the host cert from wso2carbon.jks and imported same into the client-truststore.jks. The trusted CA-signed certs are also in client-truststore.jks (at this point just to be sure). They are also in wso2carbon.jks (used to trust the CA reply).
I've changed the HostName and MgtHostName in carbon.xml to match the CN in the private key; the Carbon console comes up cleanly with no SSL issues and I can log in using the 'admin' user with no problem. From there I've updated the SSO configuration using the above example links as guides. That works with no errors.
When I go to each site (e.g., saml2.demo, avis.com, etc.) they redirect perfectly to IS to authenticate. However when I log in I get the error in the log "Issuer details are not valid. Issuer details should be registered in advance". And then I'm stuck.
What have I missed?
Have you done the 5th step of the topic 2 Configuring the WSO2 Identity Server ? Please check the value you've registered as the Issuer is as same as the one that comes in the SAML Authentication Request message.