Usere getting HTTP 502 error accessing secure Web server via Access Gateway with TLS 1.2 enabled

  • 7015539
  • 15-Aug-2014
  • 15-Aug-2014

Environment

NetIQ Access Manager 4.0
NetIQ Access Manager Access Gateway Service running on RHEL 6.5
TLS 1.2 OpenSSL enabled on Access Gateway as per https://www.netiq.com/documentation/netiqaccessmanager4/enable_tls_nam40/data/enable_tls_nam40.html

Reverse Proxy -> Web Servers -> Web Server Trusted Root: Do not verify enabled



Situation

Access Manager 4.0 setup and working well. To improve security, all SSL/TLS transactions were set to use TLS 1.2. Both the NAM Identity Server and Access Gateway Server components were updated as per the above doc to enable TLS 1.2 (installed the additional apache package using the install_AG_Openssl101.sh script). After making the changes, all proxy services except one worked.

Users accessing the problem secure Web server woul dget 502 errors, and the error_log file on the AG would report the following:


          [error] (502)Unknown error 502: proxy: pass request body failed to 10.175.121.57:443 (10.175.121.57)

          AMEVENTID#8: proxy: Error during SSL Handshake with remote server returned by


Tests were done adding a few SSL advanced options, but to no avail. These options included:


- SSLProxyCheckPeerCN off

- SSLProxyProtocol +SSLv2 +SSLv3 +TLSv1 +TLSv1.1

- SSLProxyVerify none


LAN traces show that the AG would close the TCP connection after the Server Hello Done is returned from the secure web server.

Resolution

Modified the Advanced Options for this proxy service to include the following:

SSLProxyCipherSuite ALL:!EDH:!DHE:!ECDHE:!ECDH:!ADH:RC4+RSA:!EDH:+HIGH:+MEDIUM:+LOW:!SSLv2:!3DES:!DES:+EXP

Cause

The cipher sent back from the Web server is something Apache failed to handle correctly, hence the TCP FIN to close the connection with the Web server.

By using the SSLProxyCipherSuite advanced option above, the list of supported ciphers the AG could negotiate was reduced. The Web server then responded with a cipher than AG supported and the SSL handshake was able to complete successfully.