How to disable xFlow/Service Point on non-secure ports so end users will always use secure port
Article ID: 211686
Updated On:
Products
Issue/Introduction
After using the instructions in the documentation to configure xFlow for SSL (Enable Secure Socket Layer for xFlow Interface), the non-SSL ports are found to be still active. For example, netstat shows both 9002 and 9444 active and attached to the same process:
C:\Program Files\CA\xFlow\APPS\Services>netstat -aon | findstr "9002 9444"
TCP 0.0.0.0:9002 0.0.0.0:0 LISTENING 10492
TCP 0.0.0.0:9444 0.0.0.0:0 LISTENING 10492
TCP [::]:9002 [::]:0 LISTENING 10492
TCP [::]:9444 [::]:0 LISTENING 10492
<xflow>\APPS\logs\xFlowService.log shows:
[<date> <time>] Working Directory = C:\PROGRA~1\CA\xFlow\APPS\\Services\incidentmicroservice-17.0.479\bin
[<date> <time>] App Home Directory = C:\PROGRA~1\CA\xFlow\APPS\\Services\incidentmicroservice-17.0.479
[<date> <time>] Service Batch Path = C:\PROGRA~1\CA\xFlow\APPS\\Services\incidentmicroservice-17.0.479\bin\incidentmicroservice.bat
[<date> <time>] Service PID File = C:\PROGRA~1\CA\xFlow\APPS\\Services\incidentmicroservice-17.0.479\bin\RUNNING_PID
[<date> <time>] Service Port = 9002
[<date> <time>] Starting Micro Service....
[<date> <time>] Setting redirect output & error logs for the process....out =C:\PROGRA~1\CA\xFlow\APPS\\logs\incidentservicestdout.txt $ err =C:\PROGRA~1\CA\xFlow\APPS\\logs\incidentservicestderr.txt
[<date> <time>] Micro Service Started
And, it is possible to login to xFlow using both ports:
http://localhost:9002
https://localhost:9444
Tried editing <xflow>\APPS\ServiceConfig.xml, and updating port 9002 to 9444 there, then restarted xFlow. It says the service is started but the ports aren't engaged:
C:\Users\Administrator>netstat -aon | findstr "9002 9444"
<no results returned>
<xflow>\APPS\logs\xFlowService.log does not show the incidentmicroservice starting at all.
<xflow>\APPS\logs\incidentMS.log shows
ERROR - 2024-10-24 14:56:50 [akka.io.TcpListener] - Bind failed for TCP channel on endpoint [/0.0.0.0:9444]
java.net.BindException: [/0.0.0.0:9444] Address already in use: bind
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:459)
at java.base/sun.nio.ch.Net.bind(Net.java:448)
at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80)
Tried editing <xflow>\APPS\ServiceConfig.xml, and removing the line for the incident microservice, then restarted xFlow. It says the service is started but the ports aren't engaged:
<xflow>\APPS\logs\xFlowService.log shows:
[<date> <time>] Working Directory = C:\PROGRA~1\CA\xFlow\APPS\\Services\null\bin
[<date> <time>] App Home Directory = C:\PROGRA~1\CA\xFlow\APPS\\Services\null
[<date> <time>] Service Batch Path = C:\PROGRA~1\CA\xFlow\APPS\\Services\null\bin\null
[<date> <time>] Service PID File = C:\PROGRA~1\CA\xFlow\APPS\\Services\null\bin\RUNNING_PID
[<date> <time>] Service Port = null
[<date> <time>] Starting Micro Service....
[<date> <time>] (start) Service exception = Cannot run program "C:\PROGRA~1\CA\xFlow\APPS\Services\null\bin\null" (in directory "C:\PROGRA~1\CA\xFlow\APPS\Services\null\bin"): CreateProcess error=2, The system cannot find the file specified
Tried configuring so that the ssl ports were the same as the original non-ssl ports. Result was that xFlow would not start correctly.
<xflow>\APPS\logs\xFlowService.log does not show the incidentmicroservice starting at all.
<xflow>\APPS\logs\incidentMS.log shows
ERROR - 2024-10-31 10:57:53 [akka.io.TcpListener] - Bind failed for TCP channel on endpoint [/0.0.0.0:9002]
java.net.BindException: [/0.0.0.0:9002] Address already in use: bind
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.base/sun.nio.ch.Net.bind(Net.java:459)
at java.base/sun.nio.ch.Net.bind(Net.java:448)
at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
at java.base/sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:80
Environment
Service Desk 17.1 through 17.4 RU3
Cause
Port 9002 is still open and be used. the documented steps do not touch the existing non-secure port 9002.
Resolution
The fix for this problem will be incuded in SDM v17.4 RU4
Additional Information
DE619829
Feedback
