I noticed the default administrative port 8443 is using a weak ephemeral Diffie-Hellman public key exchange: prone to logjam-like vulnerabilities. So, I tried to change the cipher suites this port has associated, but as Policy manager itself uses this communication channel (port 8443), when I tried to apply the changes in “Manage Listen Port” > “8443” >Properties SSL/TLS
Policy Manager states “Unable to modify the listen port form the current admin connection” (actually, it had sense, it´s kind a bootstrapping condition)
How to change the 8443 configuration of TLS in order to work with a most secure set of cipher suites?, and also to work TLS1.2? And what is necessary to do in the Policy Manager to be able to connect to the new configuration?
Connect to Policy Manager on port 9443, and then you’ll be able to edit 8443 properties…
Sam Ucich | Sr. Principal Consultant, CA API Management
603.548.3841 | email@example.com
Thanks a lot, just myGateway.com:9443
From services we do recommend that we segregate out the ports like so:
8443 – only processes requests and that’s it.
9443 – We suggest to leave it as is
8080 – Processes http requests only
Create 2 new ports – Doesn’t have to be these port numbers.
7443 – Policy Manager access only
8180 – Ping port only
CA Technologies |885 West Georgia Street Ste 500 | Vancouver, BC V6C 3G1
Office: 1-778-328-5285 | Mobile: +1 778 980 0029 | Derek.Orr@ca.com
I prefer a slightly different setup where I create a new listen port 10443 with an external redirect from 443 which only has services (and WSDL service) enabled. On the external firewall we only open 443 to the gateway. This way you don't risk someone leaving the default config and having the Policy Manager accessible externally. Added benefit is that you don't have to enter the port number in the Policy Manager since 8443 is the default.
And in addition to this I apply as best practice (and default setup) that you use 3 interfaces (although many of our smaller customers don't have separated network segments to support this) :
That way you can bind the Policy Manager port to eth0 only and make sure outside access is never possible.
Of course don't forget to disable the Policy Manager option from the default listen port configuration on 8443 if you do use that port for service access.
You cannot modify the properties of a port on which you are currently connected. You therefore need to log into the gateway on port 9443 (for example), then modify the 8443 properties.
Create a 9443 listen port to log into:
Log off then log back in using this port:
Logged in on the 9443 port, you can now modify the 8443 port properties.
To enable TLS 1.2 on the CA API Gateway:
Just as an aside for other readers: Port 9443 exists on the API Gateway by default and exists expressly for this purpose. It is not recommended that the default ports be removed as it will inevitably require it to be re-added to make changes such as this. I believe that port 9443 is still present on this particular system but is just partially obscured by the dialog box. The default ports for the Gateway are: 8080, 8443, 9443, 2124.
myGateway.com:9443 is just an example. Of course, you'd have to use your own gateway domain.
VCSOFT: The discussion has moved a bit off-topic. Do you feel that the original request has been answered? If so then could you please mark it as answered and we can move this discussion to a new thread? Thanks!
Hi all !
Following VCSOFT question, I have an issue after upgrading TLS version support of the Gateway (from TLS 1.0 to 1.1).
I just changed the TLS version support in "Manage Listen Ports" menu (nothing about cipher suites). Then I was unable to connect using my user certificates (connect to Policy Manager or get requests from SOAPUI) -> SSL/TLS Handshake Error.
Should I renew my user certificates after TLS version upgrade ?
Not sure this is the root cause of your troubles this would request a deep Network capture analysis) , but TLS1.1 and 1.2 standard request the server side to send an "Acceptable client certificate CA names" list during SSL negotiation.
By default SSG is using it's default installation certificate CA as "Acceptable client certificate CA names".
If your client certificate has nothing to do with the default SSG CA, your client side may end the SSL negotiation without further notification.
A workaround for this is to set 2 "cluster wide properties" : "protocolProvider=SunJSSE and noAcceptedIssuers=true.
Hope this help.
Thank your for your help.
Could you be more precise about these two cluster wide properties ? I did not found them in Gateway documentation (I was searching for potential edge effects).
Have a nice day
Hi Nicolas AFONSO ,
Looks like we have the have concerns
Those 2 cluster wide properties has been provided to me by the L7 Dev Team through the L7 support team ...
I have asked the L7 support about potential edge effects as well and here is the L7 Dev Team reply:
If SunJSSE works then this is fine but you will want to upgrade to 8.4 with the latest patches to get the latest SunJSSE security fixes based on JDK 8. In prior JDK versions you need to make sure DHE ciper suites are disabled (in favor of ECDHE cipher suites) to avoid an issue where SunJSSE prior to JDK 8 always uses weak 768 bit ephemeral keys for DHE cipher suites.
You'll know you are having this problem if the latest version of Firefox refuses to connect to your HTTPS listen port, complaining about a too-weak DHE ephemeral key size.
Just for everybody's reference, we have a Knowledge Base (KB) article in our Support Portal for the Logjam vulnerability and how to mitigate it for the API Management products. That KB article is located at https://na32.salesforce.com/articles/Knowledge_Base/Diffie-Hellman-Key-Exchange-Security-Advisory-15-May-2015--Protocol-… and a user must be signed in to the Support Portal for a full detailed view. For those without Support Portal accounts, the quick answer to mitigating Logjam for API Gateway is this:
The TLS providers used by the API Gateway do not provide a sufficiently strong public key component when using ephemeral Diffie-Hellman key exchange. This results in some browsers blocking requests to API Gateways. This behavior can be addressed by disabling all cipher suites that are using plain Diffie-Hellman (DH) or ephemeral Diffie-Hellman (DHE) without elliptic curve cryptography (ECDH or ECDHE). Cipher suites can be adjusted via the SSL/TLS Settings tab of the Listen Port Properties dialog. The procedure for selecting suites is documented here: https://wiki.ca.com/display/GATEWAY84/Selecting+Cipher+Suites. This documentation is associated with version 8.4.00 but the procedure for selecting cipher suites is identical in previous supported versions.
The API Developer Portal does not use DHE_EXPORT ciphers and uses a sufficiently strong Diffie-Hellman public key. No action is required.
On a related note, we will be moving our KB articles to the standard CA system once we are fully integrated (from previous Layer 7 infrastructure) with the CA systems and we expect that to be in the very near future. I write this for anybody who comes across this post in the future months where we may have already moved over and the URL above likely will not work anymore. When that happens, please source the KB article from the standard CA system for KB articles on its website under the Support tab.
I finally solved my issue.
I wrote a post about that, for helping future users facing this problem : [TIP] SOAPUI / Policy Manager connections issue after upgrading TLS version support