WLS 12.1.2 is running under JDK 1.7_60 on Windows 7
To meet the requirement "Switch to HTTPS, but leave t3" the following steps are performed in admin console for managed server (where the apps reside)
Disable default listen port 7280 (http and t3)
Enable default SSL listen port 7282 (https and t3s)
In order to enable t3, create a custom Channel
Protocol: t3
Port: 7280
“HTTP Enabled for This Protocol“ flag is set to false
After that, we have https and t3s on port 7282 and t3 only on port 7280.
In this case, we have issues with deployment of applications.
The deployer fails to start/stop the apps.
The reason is the deployer still tries to send messages to managed server via http.
I turned on the deployment debugging and see the following messages in admin server log.
…<DeploymentServiceTransportHttp> …<HTTPMessageSender: IOException: java.io.EOFException: Response had end of stream after 0 bytes when making a DeploymentServiceMsg request to URL: http://localhost:7280/bea_wls_deployment_internal/DeploymentService>
… <DeploymentServiceTransportHttp> …<sending message for id '-1' to 'my_srv' using URL 'http://localhost:7280' via http>
If I disable the custom t3 Channel, everything is ok. The deployer sends messages to https://localhost:7282, as expected. But in this case, we have no t3 available.
Any help is much appreciated.
Thanks
Related
I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.
I try to configure my Kafka brokers to work under ssl. I have the following configuration in all brokers:
listeners=PLAINTEXT://0.0.0.0:9092, SSL://0.0.0.0:9093
advertised.host.name=my_host_ip
port=9092
ssl.truststore.location=/opt/kafka/kafka.server.truststore.jks
ssl.keystore.location=/opt/kafka/kafka.server.keystore.jks
ssl.key.password=123456
ssl.keystore.password=123456
ssl.truststore.password=123456
And some other definitions which are not related to my ssl configuration.
In the client configuration I have the following:
security.protocol=SSL
ssl.truststore.location=/opt/kafka_2.12-0.10.2.0/config/ssl/kafka/client.truststore.jks
ssl.truststore.password=123456
With port 9092 (no ssl) everything works well, but when I try to use port 9093 - I got the following error, and I can't post message to the Kafka topic:
2017-04-25T16:59:19.945801000Z [2017-04-25 16:59:19,857] ERROR [KafkaApi-2] Error when handling request {topics=null} (kafka.server.KafkaApis)
2017-04-25T16:59:19.945991000Z kafka.common.BrokerEndPointNotAvailableException: Broker `2` does not have listener with name `ListenerName(SSL)’
I have ssl connection between the machines (checked with openssl)
What can be the reason?
I think you're exposing port 9092, but your SSL is configured to listen to 9093. Also, if I remember correctly, advertised.host.name is a deprecated parameter in kafka 0.10.x
I'll suggest commenting out advertised.host.name=my_host_ip and port=9092 and putting advertised.listeners=PLAINTEXT://<ip>:9092, SSL://<ip>:9093
I am using IBM APIC 5.0
I have setup the following.
1. IBM HTTP Server, WAS Plugin routing to MicroGateway
2. MicroGateway, running on Collectives
3. IBM HTTP Server, WAS Plugin routing to Provider Application
4. Provider Application, running on Collectives
Scenario 1 - Invoke Provider App URL directly
HTTPS request to IHS1/Plugin
Configure API to invoke the URL directly (e.g. http://:9081), without SSL
IHS1/Plugin (svr1:443) > MicroGateway (svr1:9081) > Loopback App (svr2:9081)
This works.
Scenario 2 - Invoke Provider App, indirectly via HTTP Server
HTTPS request to IHS1/Plugin
Set host header accordingly (as described in KnowledgeCenter)
Configure API to invoke the IHS URL (e.g. https://svr1:443), with SSL
IHS1/Plugin (svr1:443) > MicroGateway (svr1:9081) > IHS2/Plugin (svr2:443) > Loopback App (svr2:9081).
503 error encountered.
The ihs2/plugin trace reveals the following:
[29/Sep/2016:12:55:59.40468] 00007ea3 fdd0b700 - ODR:DEBUG: matchVHost: enter - host=apidemo-57d22263e4b0171525a5042d-1474392568657.xxx, port=443
[29/Sep/2016:12:55:59.40470] 00007ea3 fdd0b700 - ODR:DEBUG: matchLongestURI: virtual host /cell/defaultCollective/vHostGroup/-vHost-apidemo-57d22263e4b0171525a5042d-1474392568657.xxx:-1 matched host apidemo-57d22263e4b0171525a5042d-1474392568657.xxx
This shows that the configured host header matches, and it is able to find the provider application server. Means that the dynamic routing works to certain extent.
[29/Sep/2016:12:55:59.40565] 00007ea3 fdd0b700 - ODR:DEBUG: checkIfTransportIsValid: endpoint name='/cell/defaultCollective/node/,%2Fhome%2Fusers%2Fadmin%2Fwlpn/server/apidemo-57d22263e4b0171525a5042d-1474392568657-1/transport/Https', port=9081 is valid
This shows that 9081 is a valid part and Https is selected.
[29/Sep/2016:12:55:59.40971] 00007ea3 fdd0b700 - ERROR: lib_stream: openStream: Failed in r_gsk_secure_soc_init: GSK_ERROR_SOCKET_CLOSED(gsk rc = 420) PARTNER CERTIFICATE DN=No Information Available, Serial=No Information Available
[29/Sep/2016:12:55:59.40982] 00007ea3 fdd0b700 - ERROR: GSK_INVALID_HANDLE
[29/Sep/2016:12:55:59.40998] 00007ea3 fdd0b700 - ERROR: ws_common: websphereGetStream: Could not open stream
Then come the error. It's can SSL error. I suspect that currently the Provider application is not enabled with SSL.
Question on how to resolve this
1) How do I enable the loopback app with SSL. I follow this instruction, but it does not work for me because my loopback app is deployed on Collectives.
https://github.com/strongloop/loopback-example-ssl
2) How do I configure the dynamic routing to use non-SSL http traffic instead?
I Have Tomcat run on HTTPS.
I have tried to deploy SIPML5 WebSocket Application To into my tomcat.
When I tried to connect Sip Servlets using ws :
ws://192.168.X.Y:5082
And Sip Servlets Config looks like :
<Connector port="5082"
ipAddress = "192.168.X.Y"
protocol="org.mobicents.servlet.sip.startup.SipProtocolHandler"
signalingTransport="ws"/>
I got an error :
SIPml-api.js:4 Mixed Content: The page at 'https://192.168.X1.X2:8443/CallCenterBK/CallCenterBK.jsp?sip=1' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.X.Y:5082/'. This request has been blocked; this endpoint must be available over WSS.
When I have changes my SIPML 5 Client to wss :
wss://192.168.X.Y:5082
And my sip servlets config looks like :
<Connector port="5082"
ipAddress = "192.168.X.Y"
protocol="org.mobicents.servlet.sip.startup.SipProtocolHandler"
signalingTransport="wss"/>
I got another error :
WebSocket connection to 'wss://192.168.X.Y:5082/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
And when I have set to sipml 5 client : wss://192.168.X.Y:5082
and config changed to :
<Connector port="5082"
ipAddress = "192.168.X.Y"
protocol="org.mobicents.servlet.sip.startup.SipProtocolHandler"
signalingTransport="ws"/>
I got an error :
WebSocket connection to 'wss://192.168.1.3:5082/' failed: Error in connection establishment: net::ERR_TIMED_OUT
What I did incorrectly ?
Any idea will be appreciated.
You configured the HTTPs connector with the certificate information, you need to do the same thing for the WSS connector. Unfortunately the configuration for that is located at the SIP Stack level, so you need to edit your standalone/configuration/mss-sip-stack.properties and add
gov.nist.javax.sip.TLS_CLIENT_AUTH_TYPE=Disabled
javax.net.ssl.keyStore=$TRUSTSTORE_FILE
javax.net.ssl.keyStorePassword=$TRUSTSTORE_PASSWORD
javax.net.ssl.trustStorePassword=$TRUSTSTORE_PASSWORD
javax.net.ssl.trustStore=$TRUSTSTORE_FILE
javax.net.ssl.keyStoreType=JKS
SIPML5 works fine with wss for sure. The problem is on your server side.
Make sure that 5082 port is listening (telnet)
Make sure that you have installed a valid SSL certificate to your
server
Make sure that 5082 is the secure (wss) port (On most servers the ws
unsecured and wss secured are listening on different ports)
I'm trying to get PingAccess set up as a proxy (let's call the PA host
pagateway) for a couple of applications that share a Web Session. I want all access to come via the PA pagateway and use HTTPS, but the back end systems are not HTTPS.
I have two sites defined, app1:8080 and app2:8080. Both are set to "secure" = no and "use target host header" = yes.
I have listeners defined on ports 5000 and 5001 that are both set to "secure" = yes.
The first problem I found is that when I access either app in this way (e.g. going to https://pagateway:5000), after successfully authenticating with PingFederate I end up getting redirected to the actual underlying host name (e.g. http://app1:8080), meaning any subsequent interactions with the app are not via PingAccess. For users outside the network they wouldn't even be able to do that because the app1 host wouldn't even be visible or accessible.
I thought maybe I needed to turn off "Use target host header" to false but Chrome prompts me to download a file that contains NAK, ETX, ETX, NUL, STX, STX codes, and in the PA logs I get an SSL error:
2015-11-20 11:13:33,718 DEBUG [6a5KYac2dnnY0ZpIl-3GNA] com.pingidentity.pa.core.transport.http.HttpServerHandler:180 - IOException reading sourceSocket
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
...
I'm unsure exactly which part of the process the SSL error is coming from (between browser and pagateway, or pagateway and app1). I'm guessing maybe app1 is having trouble with the unexpected host header...
In another variation I turned off SSL on the PA listener (I also had to change the PingAccess call-back URL in the PingFederate client settings to be http). But when I accessed it via http://pagateway:5000 I got a generic PingFederate error message in the browser and a different error in the PA logs:
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:148 - Invoking request handler: Scheme Validation for Request to [pagateway:5000] [/]
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:200 - Exception caught. Invoking abort handlers
com.pingidentity.pa.sdk.policy.AccessException: Invalid request protocol.
at com.pingidentity.pa.core.interceptor.SchemeValidationInterceptor.handleRequest(SchemeValidationInterceptor.java:61)
Does anyone have any idea what I'm doing wrong? I'm kind of surprised about the redirection to the actual server name, to be honest, but after that I'm stumped about where to go from here.
Any help would be appreciated.
Have you contacted our support on this? It's sounding like something that will need to be dug into a bit deeper - but some high level suggestions I can make:
Take a look at a browser trace to determine when the redirect is happening to the backend site. Usually this is because there's a Location header in a redirect from the backend web server that (by nature) is an absolute URL but pointing to it instead of the externally facing hostname.
A common solution to this is setting Target Host Header to False - so it will receive the request unmodified from the browser, and the backend server should know to represent itself as that (if it behaves nicely behind a proxy).
If the backend server can't do that (which it sounds like it can't) - you should look at assigning rewriting rules to that application. More details on them are available here: https://support.pingidentity.com/s/document-item?bundleId=pingaccess-52&topicId=reference%2Fui%2Fpa_c_Rewrite_Rules_Overview.html. The "Rewrite Response Header Rule" in particular will rewrite Location headers in HTTP redirects.
FYI - The "Invalid request protocol." error you're seeing at bottom of your description could be due to a "Require HTTPS" flag on your defined Application.
Do you have the same issue if you add a trailing slash at the end (https://pagateway:5000/webapp/)? Your application server will rewrite the URL based on what it thinks is the true host. This is to get around some security related issues around directory listing.
Which application server are you using? All app servers are unique, but I'll provide instructions on how to resolve this with Tomcat.
Add a global rule that forces the application server to use the external facing host name. Here is a sample Groovy script:
def header = exc?.request?.header;
header?.setHost("pf.pingdemo.com:443");
anything();
In Tomcat's server.xml, add scheme="https" to the connection:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="443" scheme="https" />
Cheers,
Tam