CODEWITHSUNDEEP
wso2wso2-api-manager
Adam
Adam

Reputation: 6743

How to Configure WSO2 APIM to use Plain HTTP Internally

We are upgrading from 2.6 to 4.2. We are using ansible to do manage the installation/deployment. We have a problem: while it works on our (devs) local VMs, on the server while the UI, API registration, etc all work it fails to call any back-end APIs. We can see that what is timing out is an internal call within WSO2 to itself. The WSO2 logs show the log extract below while a packet capture shows a request from a port on the machine where the APIM is running to port 8243 on the same machine is timing out - and nothing is leaving the machine to try and actually call the back-end (which is on a different server - we can manually call the backend from the WSO2 machine without problem).

We think it might be a certificate issue. Trying to call that port ourselves results in a certificate error since it's presenting the self-signed cert. Our setup is a single-node WSO2 APIM behind a reverse proxy (we use Apache HTTPD for the reverse proxy) so we could use plain HTTP for the calls from the proxy to WSO2 and within WSO2 (since no such calls will leave that machine). However, I can't see how to configure that. Can anyone help? If that isn't possible, how can we supply our SSL certs to WSO2 so it uses a valid cert? The closest I can find to either in the WSO2 docs is how t control which TLS ciphers are allowed but maybe I am missing something.

If we are on totally the wrong track, and anyone has any other ideas, then any suggestions very welcome. The log extract is

TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.passthru.SourceHandler} - http-incoming-36: Timeout
TID: [] [] [2023-05-16 10:42:38,078]  INFO {org.apache.synapse.transport.passthru.SourceHandler} - Writer null when calling informWriterError
TID: [] [] [2023-05-16 10:42:38,078]  WARN {org.apache.synapse.transport.passthru.SourceHandler} - STATE_DESCRIPTION = Socket Timeout occurred after accepting the request headers and the request body, INTERNAL_STATE = REQUEST_DONE, DIRECTION = REQUEST, CAUSE_OF_ERROR = Connection between the client and the EI timeouts, HTTP_URL = /integrations/scim/carcwso2/v1/integrations/scim/v2/Users/apiuser, HTTP_METHOD = GET, SOCKET_TIMEOUT = 180000, CLIENT_ADDRESS = /10.0.100.60:33982, CONNECTION http-incoming-36 Correlation ID : 1b58ec31-3bbd-4e5e-a197-d18f67424aef
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.passthru.connections.SourceConnections} - Shutting down connection forcefully http-incoming-36
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.http.conn.LoggingNHttpServerConnection} - http-incoming-36: Shutdown connection
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.http.nio.reactor.ssl.SSLIOSession} - I/O session http-incoming-36-36 10.0.100.60:8243<->10.0.100.60:33982[ACTIVE][:r][ACTIVE][][NOT_HANDSHAKING][0][0][0]: Shutdown
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.passthru.SourceHandler} - http-incoming-36: Closed
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.passthru.SourceHandler} - http-incoming-36: Keep-Alive connection was closed:  Remote Address : null
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.passthru.connections.SourceConnections} - Shutting down connection forcefully http-incoming-36
TID: [] [] [2023-05-16 10:42:38,078] DEBUG {org.apache.synapse.transport.http.conn.LoggingNHttpServerConnection} - http-incoming-36: Shutdown connection
TID: [] [] [2023-05-16 10:42:38,079] DEBUG {org.apache.http.nio.reactor.ssl.SSLIOSession} - I/O session http-incoming-36-36 [CLOSED][][CLOSED][][NOT_HANDSHAKING][0][0][0]: Shutdown
TID: [] [] [2023-05-16 10:42:38,200] DEBUG {org.wso2.andes.kernel.disruptor.inbound.InboundEventManager} - [ Sequence: 3337 ] SAFE_ZONE_DECLARE_EVENT' published to Disruptor

Upvotes: 0

Views: 247

Answers (1)

Adam
Adam

Reputation: 6743

We have (we think) found the underlying problem. We therefore do not need to change the SSL configuration and this question is now moot. It was not a difference in the hosting environment but in the configuration. Namely that the WSO2 admin user (in the environment we were using to test on the real servers) included a # in the password and we therefore fell foul of https://github.com/wso2/product-apim/issues/12186

If we change the password to something with any # characters it seems to work. We will continue to test.

Upvotes: 0

Related Questions