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?
Related
I am trying to implement mutual authentication for the communication between aws api gateway and my server. I want to use the client side certificates that amazon offers for authentication. I know that my server is configured correctly because previously I was using a lambda function and mutual authentication was working.
I have exported the (.PEM) certificate and added it into a truststore. I have configured my Jetty server to use that truststore for authentication. I have set client-auth to :need. I know my server is set up correctly because it was working with with my self-implemented mutual SSL. All I did was change the truststore. When I test my method gateway returns a 200:
{ "message": "Unknown endpoint error."}
Here is an excerpt from the server log files. It appears that the server side handshake completes, but there is an error with the client certificate.
pConnection#3a0a2e84{FILLING} server-side handshake completed
2015-09-28 13:04:29,856 DEBUG [qtp1980278840-19]
o.e.j.i.ChannelEndPoint - flushed 45
SelectChannelEndPoint#2c05eeb2{ec2-xx-xxx-xxx-x.compute-1.amazonaws.com/5x.xxx.xxx.x:43942<->4000,Open,in,out,-,-,0/200000,SslConnection}{io=0,kio=0,kro=1}
2015-09-28 13:04:29,856 DEBUG [qtp1980278840-19]
o.e.j.i.s.SslConnection -
SslConnection#50e2de43{NOT_HANDSHAKING,eio=0/0,di=-1} ->
HttpConnection#3a0a2e84{FILLING} flush exit, consumed 0 2015-09-28
13:04:29,856 DEBUG [qtp1980278840-19] o.e.j.i.s.SslConnection -
SslConnection#50e2de43{NOT_HANDSHAKING,eio=0/-1,di=-1} ->
HttpConnection#3a0a2e84{FILLING} unwrap Status = BUFFER_UNDERFLOW
HandshakeStatus = NOT_HANDSHAKING
I have solved this problem. The server logs I posted are misleading. No handshake occurs because the server certificate I was using was self signed, not signed by a trusted CA. As of 9/28/2015, aws api gateway requires a certificate signed by a trusted certificate authority. Because my cert was self signed, the server (and client) handshakes do not complete. Hopefully this problem will be solved in future versions.
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.
When I used set doc=db.GetDocumentByURL(url,1,1,,,,,False) to get a page/file under http, it returned the web page/file successfully as a Notes document.
But when I used set doc=db.GetDocumentByURL(url,1,1,username,password,,,False) to get an ssl page/file under https, where url is like "https://docs.google.com/document/d/xxxxoooo/edit", it failed and the remote console showed the error messages:
SSL Error: Keyring File access error
Connection interrupted: SSL Error: Bad or missing remote certificate
Can't db.GetDocumentByURL() access an ssl page/file? What should I do?
Assuming you are using Windows - make sure that IE can open the page. I've seen this problem in case the server's SSL certificate was self-signed and installing it in IE solved the problem.
I was wondering if I can set an activemq broker with a ssl connection with the sole purpose of encryption (similar to HTTPS considering that the client does not check the certificate).
In that sense, I've tried seting up the broker to use ssl connection, set its keystore and on.
And on the client side, I tried using the sample code from fusesource as basis but without setting the client trust store (I would like the client to accept every certificate).
With that configuration, I could not connect the client and I got the following error message in the broker's log:
2013-05-06 15:25:32,848 | ERROR | Could not accept connection :
javax.net.ssl.SSLException: No available certificate or key
corresponds to the SSL cipher suites which are enabled. |
org.apache.activemq.broker.TransportConnector | ActiveMQ Transport
Server: ssl://0.0.0.0:61617?trace=true
Is this error really because the client has not added the broker certificate to its truststore? If so, is there a way so that the client accept the connection even without a truststore?
There was an error in my SSL configuration in the broker which caused that error message. I am not sure exactly what was wrong because I have re-done the whole configuration following this tutorial and got it to run the broker without errors.
In order to get the ssl encryption but no authentication, I basically had to set my ssl connection to <transportConnector name="ssl" uri="ssl://0.0.0.0:61617?trace=true?needClientAuth=false"/>
and to either
add the certificate directly to the JVM as in Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
or create a trust manager that accept all certificates on the client as in Setting trust store programatically in ActiveMQSslConnectionFactory seems to fail
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.