Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


SSL Proxy Logs

SSL Proxy Logs

SSL Proxy Logs

When logging is enabled in an SSalphaTable 1.

Table 1: SSL Proxy Logs
Syslog Type Description


Logs generated when a session is dropped by SSL proxy.


Logs generated when a session is processed by SSL proxy even after encountering some minor errors.


Logs generated if non-SSL sessions are initially mistaken as SSL sessions.


Logs generated when a session is allowlisted.


Logs used for reporting errors.


Logs used for reporting warnings.


Logs used for reporting general information.

You we can use SSL_PROXY_SESSION_WHITELIST and SSL_PROXY_INFO logs to check the URLs logged in. Example:

Check System Log Explorer for more details.

All logs contain similar information as shown in the following example (actual order of appearance):

The message field contains the reason for the log generation. One of three prefixes shown in Table 2 identifies the source of the message. Other fields are descriptively labeled.

Table 2: SSL Proxy Log Prefixes
Prefix Description


Logs generated due to errors related to the device or an action taken as part of the SSL proxy profile. Most logs fall into this category.

openssl error

Logs generated during the handshaking process if an error is detected by the openssl library.

certificate error

Logs generated during the handshaking process if an error is detected in the certificate (x509 related errors).

Sample logs:


These logs capture sessions that are dropped by SSL proxy, not sessions that are marked by other modules that also use SSL proxy services.

For SSL_PROXY_SESSION_WHITELIST messages, an additional host field is included after the session-id and contains the IP address of the server or domain that has been allowlisted.

Enabling Debugging and Tracing for SSL Proxy

Debug tracing on both Routing Engine and the Packet Forwarding Engine can be enabled for SSL proxy by setting the following configuration:

SSL proxy is supported on SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 devices and vSRX Virtual Firewall instances. Table 3 shows the supported levels for trace options.

Table 3: Trace Levels

Cause Type



Only error traces on both the Routing Engine and the Packet Forwarding Engine.


Packet Forwarding Engine–Only event details up to the handshake should be traced.

Routing Engine–Traces related to commit. No periodic traces on the Routing Engine will be available


Packet Forwarding Engine–Data transfer summary available.

Routing Engine–Traces related to commit (more extensive). No periodic traces on the Routing Engine will be available.


All traces are available.

Table 4 shows the flags that are supported.

Table 4: Supported Flags in Trace

Cause Type



Configuration-related traces only.


Enable tracing on the SSL-I plug-in.


Enable tracing on the SSL-Proxy-Policy plug-in.


Enable tracing on the SSL-T plug-in.


Enable tracing only for profiles that have enable-flow-tracing set.

You can enable logs in the SSL proxy profile to get to the root cause for the drop. The following errors are some of the most common:

  • Server certification validation error. Check the trusted CA configuration to verify your configuration.

  • System failures such as memory allocation failures.

  • Ciphers do not match.

  • SSL versions do not match.

  • SSL options are not supported.

  • Root CA has expired. You need to load a new root CA.

You can enable the ignore-server-auth-failure option in the SSL proxy profile to ensure that certificate validation, root CA expiration dates, and other such issues are ignored. If sessions are inspected after the ignore-server-auth-failure option is enabled, the problem is localized.