The environment configuration file for each component includes an SSL CONFIG section that has configurations to set up the SSL connector for the component. In addition, the configurations are used to configure the following:

• Either custom certificates that you have generated manually or certificates that the Installer has generated can be used for reverse proxy.

  • If you choose to use the custom certificate that is either CA-signed or self-signed, which you’ve generated, place the certificate inside the ssl directory mentioned in the option HOST_SSL_VOL(defaults to ${HOST_WORKING_DIR}/ssl). If the ${HOST_WORKING_DIR}/ssl directory is not present, create the directory.

  • You can also allow the Installer to generate the self-signed certificate. When starting the Installer/proxy_launcher.sh script, set the CREATE_SELF_SIGNED_SSL_CERT option to true. For more information, see Configure proxy hardware resources and other critical runtime options. If the required certificate and key names aren’t present in the ssl directory, the Installer generates the certificate and includes it in the ssl directory mentioned in the option HOST_SSL_VOL(defaults to ${HOST_WORKING_DIR}/ssl). The Installer doesn’t overwrite the existing files.

  These certificates are used to configure the SSL connector for individual component configurations.

• Supported TLS protocol versions

• Supported TLS ciphers

• SSL session cache size and timeout

• SSL stapling configurations

• Mutual TLS authentication for upstream connections: By default, this option is disabled. To enable this option, modify the following configurations:

  • Set the NGX_PRXY_SSL_VERIFY option to "on"

  • NGX_PRXY_SSL_TRUST_CRT → Trust file containing certificate of upstream being proxied. Certificate from this file will be verified by NGINX against what is provided by upstream during the TLS handshake.

Note

Self-signed certificates are to be used only for testing and development purposes and CA-signed certificates are mandatory for production deployments. If the certificate received from the CA isn’t a certificate chain containing all the respective certificates, compose all the relevant certificates into a single certificate chain file.

The Installer validates the configurations that are provided through the .env files and stops the deployment if it identifies certain common errors. This is done to prevent lengthy debugging on the configurations provided, which can be easily identified in the validation phase.

The following are the errors which are currently identified and reported during the validation phase.

Proxy instance launcher logs can be located at ${HOST_WORKING_DIR}/logs/openresty_launcher.log. During the NGINX startup, check the logs to see if there are any error information inside the container instance.

Openresty pid file is also located in the same folder at ${HOST_WORKING_DIR}/logs/openresty.pid.

You can locate the Nginx access and error logs for a given proxy instance at the logs directory inside the proxy working directory as ${HOST_WORKING_DIR}/logs/access.log and ${HOST_WORKING_DIR}/logs/error.log. Check these log files for any debugging information about the OpenResty® startup.

To identify the Digital Routing task requests, the reverse-proxy server generates access logs with the trackingId field. The following is an example snippet of the access.log with the trackingId field:

[09/Feb/2023:07:24:25 +0000] conn_stats:"7 : 1" client:"35.168.152.254" host:"pccedrdmzproxy-cc.cisco.com" host_addr:"173.39.15.27" host_to_upstream:"pccedrdmzproxy-cc.cisco.com->10.10.10.95:8445" 
user:"-" server_block:"173.39.15.27:443" request:"POST /drapi/v1/tasks HTTP/1.1" requestid:"-" server_cache_bypass:"-" cookie:"-" user_agent:"Apache-HttpClient/4.5.2 (Java/1.8.0_242)" 
referer:"-" cache_status:"-" rsp_status:"201(201)" body_bytes_sent:"56" time_taken:"0.021(0.022)" up_connect_time:"0.002" up_header_time:"0.022" up_bytes_sent:"1297" up_bytes_rcvd:"852" trackingId:"WebexConnect_ea54eac0-1d2a-4e09-9fa2-cb212dad13df"

If there are failures in the Digital Routing task requests, the reverse-proxy server generates error logs with the trackingId field only when you set the trace level to debug.

To enable the debug trace level for the reverse-proxy server:

1. In the "<reverse_proxy_installed_dir>/conf" directory, locate and open the nginx.conf file.

2. In the nginx.conf file, find the statement [error_log ${NGX_LOG_DIR}/error.log info;].

3. Change the trace level from info to debug as follows: [error_log ${NGX_LOG_DIR}/error.log debug;].

4. Reload the reverse-proxy server for the change to take effect.

The following is an example snippet of the error.log with the trackingId field:

2023/02/14 08:01:59 [debug] 206#206: *5 [lua] log_dr_requests.lua:4:  conn_stats:5:1 client:172.16.102.61 host:173.39.15.27 host_addr:173.39.15.27 host_to_upstream:173.39.15.27->10.10.10.95:8445 
user:nil server_block:pccedrdmzproxy-cc.cisco.com:443 request:GET /drapi/v1/tasks?from=0 HTTP/1.1 requestid:nil server_cache_bypass:nil cookie:nil user_agent:PostmanRuntime/7.29.2 referer:nil 
cache_status:nil rsp_status:200(200) body_bytes_sent:46 time_taken:0.004(0.005) up_connect_time:0.002 up_header_time:0.005 up_bytes_sent:3411 up_bytes_rcvd:733 trackingId:WebexConnect_ea54eac0-1d2a-4e09-9fa2-cb212dad13df

A separate log file is maintained to track the IPs that block the running proxy instance at ${HOST_WORKING_DIR}/logs/blocking.log. This file can be supplied to the tools such as fail2ban to automate the blocking of IP addresses at IP table level.

Client IPs are blocked if a client makes several failed authentication requests in a given time interval.

Syslogs are released by the reverse-proxy. By default, syslogs are pushed to the local endpoint. However, proxies can be configured to push this to the remote endpoint.

Syslogs are released when the client IP is blocked by the reverse proxy.

Reverse-proxy provides provision to host the static files as required at ${HOST_WORKING_DIR}/html. You can add any of the static files that must be accessed through proxy such as proxymap.txt. These files are accessible through a static file access endpoint provided by the proxy. The endpoint hostname and the port are configurable through the core.env file.

By default, you can access the static files deployed on the reverse-proxy at the URL https://[ip-of-proxy-host]:10000/staticfile.

To configure access from a different port, use the NGX_PRXY_STATIC_FILES_PORT option provided in the core.env file.

The static file port isn’t opened by default in the IP tables. If necessary, it must be explicitly opened by the administrator. The same must be opened in the DMZ firewall to access from the internet.

Note	While enabling access to this port over the internet, you must be cautious as this port isn’t covered under DOS preventive measures.

Each and every proxy instance caches the files as specified by different components inside the ${HOST_WORKING_DIR}/cache directory. Inside the cache directory, every upstream has a separate directory where the cache files for that upstream is present. The sample on how the cache is maintained is as follows:

${HOST_WORKING_DIR}/cache
|- client_temp
|- proxy_temp
|- finesse125.autobot.cvp
|- desktop
|- layout 
|- openfire 
|- rest 
|- shindig 
|- cuic126.autobot.cvp
|- cuic
|- cuicdoc

To get the latest upstream resources, the cache has to be cleared. Administrator can either do this manually by clearing all the files inside each and every directory as required or can run the script provided inside the container to clear the cache automatically.

podman exec <PROXY_INSTANCE_NAME>
        /usr/local/openresty/nginx/sbin/openresty_launcher.sh clear_cache

Caching behaviors such as cache expiration, cache sizes, and so on, can be configured from the individual component env files. The configuration options for different components' env files are as follows:

• Finesse

  • NGX_FIN_DESKTOP_CACHE_SIZE

  • NGX_FIN_DESKTOP_CACHE_MAX_SIZE

  • NGX_FIN_DESKTOP_CACHE_INACTIVE_DURATION

  • NGX_FIN_SHINDIG_CACHE_SIZE

  • NGX_FIN_SHINDIG_CACHE_MAX_SIZE

  • NGX_FIN_SHINDIG_CACHE_INACTIVE_DURATION

  • NGX_FIN_OPENFIRE_CACHE_SIZE

  • NGX_FIN_OPENFIRE_CACHE_MAX_SIZE

  • NGX_FIN_OPENFIRE_CACHE_INACTIVE_DURATION

  • NGX_FIN_REST_CACHE_SIZE

  • NGX_FIN_REST_CACHE_MAX_SIZE

  • NGX_FIN_REST_CACHE_INACTIVE_DURATION

  • NGX_FIN_LAYOUT_CACHE_SIZE

  • NGX_FIN_LAYOUT_CACHE_MAX_SIZE

  • NGX_FIN_LAYOUT_CACHE_INACTIVE_DURATION

• CUIC

  • NGX_CUIC_CACHE_SIZE

  • NGX_CUIC_CACHE_MAX_SIZE

  • NGX_CUIC_CACHE_INACTIVE_DURATION

  • NGX_CUICDOC_CACHE_SIZE

  • NGX_CUICDOC_CACHE_MAX_SIZE

  • NGX_CUICDOC_CACHE_INACTIVE_DURATION