I am using amazon web apis to generate federated user credentials e.g. GetSessionToken. It's working fine on my localhost machine but throw error on live server . Any guesses?
Error throws:
A WebException with status TrustFailure was thrown.
That does not sound like an AWS exception. It sounds like an SSL/TLS issue related to certificates.
I had a similar issue - is your date correct on your machine?
The AWS connection process will throw out the request if the date is wrong.
I answered a very similar issue here . In my case, the server I was receiving the error on did not have the correct cert in its trusted root certificate authorities. Adding the correct cert resolved the issue.
check certificate settings installed on Production machine
Related
I am new to WSO2 API Manager. I followed the Quick Start Guide to learn by deploying sample PizzaShackAPI.
https://docs.wso2.com/display/AM210/Quick+Start+Guide
As I click "Try It Out!", I am not getting the correct response as mentioned in the guide.
I am getting the below response and there is no log in the console initially.
Response Code
0
Response Headers
{
"error": "no response from server"
}
After I added Self Signed Certificate in Firefox as Add Exception, I am getting the below error in the console,
[2017-03-01 15:06:51,309] ERROR - SourceHandler I/O error: An established connection was aborted by the software in your
host machine
java.io.IOException: An established connection was aborted by the software in your host machine
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at org.apache.http.nio.reactor.ssl.SSLIOSession.receiveEncryptedData(SSLIOSession.java:371)
I guess it may be a certificate configuration issue. Please help me to resolve this issue.
I tried with creating my own API. Facing the same issue.
Error message "error": "no response from server" on API console is mostly due to CORS error. Could you please check your browser console and see the error there, Most likely you will see error related to cors.
Note: these changes are not advised for production environment, for production environment you want to provide all relevant information instead of allow all (*)
To allow all headers and origin edit repository/conf/api-manager.xml and change values for following:
<Access-Control-Allow-Headers>*</Access-Control-Allow-Headers>
<Access-Control-Allow-Origin>*</Access-Control-Allow-Origin>
Second change to allow all host name and avoid any certificate host name validation.
Edit /repository/conf/axis2/axis2.xml and un comment HostnameVerifier and change value to AllowAll.
<parameter name="HostnameVerifier">AllowAll</parameter>
Restart API Manager and test again.
We are working on SP2016 on premise provider hosted add-in. Remote Events for the same was working fine in SP2013 with no issues. Once, upgraded to 2016 when installing the app. We get the following error.
This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server."
We are using self signed certificates (Root and child certificates). We are following the same process what used to work for SP 2013.
Anyone with similar issues?
Any help would be greatful
I am also experiencing issues with https and SharePoint 2016, something has changed with authentication between 2013 and 2016.
I managed to debug one of our apps in http, and found where it was calling to authenticate the user, for internal use i have http site for authentication. External i am using a proxy.
I am configuring our API Manager, but running into troubles authenticating via OAuth, seems to be an issue with the API Key Manager. I haven't dug into it yet, but does this come with the API Manager (as I have assumed) or is this a separate installation?
I had the same issue when using the wso2 api manager on a Amazon hosted machine, turn out that Thrift was not working correctly because some problem with multicasting and broadcasting.
What I did to get it working was to switch from ThriftClient to WSClient. If you have a huge amount of requests coming in then Thrift is the recommended solution from wso2 but in any "normal" case you will not have any differences between thrift and WS.
Here is how you switch:
Shut down the API Manager
Open up <api manager install dir>\repository\conf\api-manager.xml
Find ThriftClient
Change this to
<KeyValidatorClientType>WSClient</KeyValidatorClientType>
Start the API Manager
You may get some Warnings while starting up but, try it before you jump to the conclusion that it doesn't work.
Hope it helps!
you can use APIM manager product in a distributed setup as keymanger,gateway,store,publisher..but all functionality come in a single distribution.. ..
Go through the documentation for further guides
I was facing the same issue. Everything started when I created my own jks in order to use SSL without a self-signed certificate. I successfully created the jks and changed it in the carbon file. When I started the server, everything seemed ok; but when I used SOAPUI to test an API call, I got this (in the logs of the api manager):
APIAuthenticationHandler API authentication failure due to Unclassified Authentication Failure
I started digging what was the problem by enabling Debug level in the log4j.properties file, and then tried again a tested with SOAPUI and I got:
APISecurityException: Could not connect to <my api ip address> on port 10397
Then, I read the comment of OneMuppet and I checked that file and I found that the Thrift config has a host option, so I uncommented it:
<KeyValidatorClientType>ThriftClient</KeyValidatorClientType>
<ThriftClientPort>10397</ThriftClientPort>
<ThriftClientConnectionTimeOut>10000</ThriftClientConnectionTimeOut>
<ThriftServerPort>10397</ThriftServerPort>
This Line --> <ThriftServerHost>localhost</ThriftServerHost>
<EnableThriftServer>true</EnableThriftServer>
Save, restarted the server and everything start working correctly.
I got the same below issue after my installation, when i try to invoke the api service it is throwing below error:
900900 Unclassified Authentication Failure Error while accessing backend services for API key validation
After some random checks i have seen the axis2.xml file in /repository/conf/axis2 there it is refering a differnt ip's instead. I change these ip's to my local ip and restarted. The issue is resolved now.
I was facing the same issue. when I was trying to setup API Manager as an API Gateway in a different machine as per the steps given here,
https://docs.wso2.com/display/AM250/Publish+through+Multiple+API+Gateways
Once the setup is done and when I am trying to use this gateway URL, I was getting the below response,
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
After changing the KeyValidatorClientType value to WSClient from ThriftClient on the <api manager install dir>\repository\conf\api-manager.xml
It started working fine. And I was able to get the expected response.
If you changed the admin password, then you also have to update the repository/conf/api-manager.xml file with the new password. The 2 places I have changed (so far) are:
<AuthManager>
and
<APIKeyManager>
but there are other admin usernames in that file. No doubt, I'll get to them....
I keep getting Connection Failed when trying to request data from a page that is on an https:// domain. I did install the ssl cert using the built-in section of the railo admin at https://[mydomain]/railo-context/admin/server.cfm?action=services.certificates however I still get Connection Failed. How should I go forward with debugging this? I have confirmed that this server in particular does have access to the domain I am trying to request from.
You probably need some additional certs installed as Jason has said. Take a close look at the cert and it's chain. Go to the cert issuers site and look for some documentation.
To troubleshoot you can add some logging to your jvm args. I think it's something like:
-Djavax.net.debug=all
The results are either in the OUT log or the server.log. This post on SSL 3.0 has some debugging tips. It's possible that your cert needs to handshake at a lower security level than CF allows (SSL 2.0 instead of 3.0/TLS for instance) and that could cause this behavior - but it's more likely that you simply need an intermediate cert installed.
The problem ended up being the permissions weren't setup properly on the machine. After we had the server administrator fix our permissions to access the Railo-Tomcat Service Control, the requests started working. I'm assuming he fixed some other permissions while he was in there.
I have a jax-ws web service developped using netbeans 7 and glassfish 3.1.2 .
I configured the web service to use Username authentication with symmetric keys security and default keystore.
When I test my web service in localhost everything work fine but when I delployed it in remote test server it didnt' work .
First I got exception complaining about Key used to decrypt EncryptedKey cannot be null so I uploaded the local keystore.jks and cacerts.jks to the remote server.
Now I'm gettinh those exceptions:
Server side:
WSITPVD0035: Error in Verifying Security in Inbound Message. com.sun.xml.wss.impl.PolicyViolationException: com.sun.xml.wss.impl.WssSoapFaultException: Invalid Security Header at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:151) at
com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.createMessage(SecurityRecipient.java:1003) at
com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:248) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage(WSITServerAuthContext.java:588) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:361) at
com.sun.xml.wss.provider.wsit.WSITServerAuthContext.validateRequest(WSITServerAuthContext.java:264) at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:173) at
com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144) at
com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119) at
com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:961) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:910) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:873) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:775) at
com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:386) at
com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:640) at
com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:263) at
com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:163) at
org.glassfish.webservices.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:120) at
org.glassfish.webservices.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:91) at
org.glassfish.webservices.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:200) at
org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:131) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:770) at
com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1059) at
com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.invokeFilterChain(ServletAdapter.java:999) at
com.sun.grizzly.http.servlet.ServletAdapter.doService(ServletAdapter.java:434) at
com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:384) at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at
com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354) at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at
com.sun.grizzly.ContextTask.run(ContextTask.java:71) at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at
java.lang.Thread.run(Thread.java:662) Caused by: com.sun.xml.wss.impl.WssSoapFaultException: Invalid Security Header at
com.sun.xml.ws.security.opt.impl.util.SOAPUtil.newSOAPFaultException(SOAPUtil.java:159) at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.processSecondaryPolicy(MessagePolicyVerifier.java:220) at
com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:144) ... 43 more
Client side:
Exception in thread "AWT-EventQueue-0" javax.xml.ws.soap.SOAPFaultException: Invalid Security Header
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:126)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:123)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
How can i fix this ?
Thanks .
The stack trace does not look familiar to me but maybe your problem is the certificate itself.
When you create a certificate you should set a 'server name'. This will be used by the client to check if the certificate's 'server name' match with the URL 'server name'. If the server names does not match the client should abort the connection because it can be an stolen certificate!!!. For more info, check this tutorial
Example with a java client: if you create a certificate for 'localhost' the client
verification will pass if and only if it access the web service using an URL
like 'https://localhost/stuff...'. So, if you tries to access the same application with the same client but using the IP like 'https://10.0.0.1/stuff...', a verification error should arise.
NOTE: The default configuration of a java web service client do this check, but If you want to bypass this client side verification please check this post
Try to check if this is the problem you are having. If it is the case you have several solutions:
Create a certificate for the server where you are deploying the
application
Disable client side verification
PS: I never did something special on the server-side to solve this kind of issues. Installing the correct certificate should be enough
In my case the problem was in CommandMap. Need to add "application/ciphervalue" handler in CommandMap, because WSIT does it only once while loading CVDataHandler class.
See com.sun.xml.ws.security.opt.impl.util.CVDataHandler static block for more details how to add.