Encrypt Traffic Using SSL Proxy and TLS
SSL proxy acts as an intermediary, performing SSL encryption and decryption between the client and the server. Better visibility into application usage can be made available when the SSL forward proxy is enabled.
SSL Proxy Overview
SSL proxy is supported on SRX Series devices only.
Secure Sockets Layer (SSL) is an application-level protocol that provides encryption technology for the Internet. SSL, also called Transport Layer Security (TLS), ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity. SSL relies on certificates and private-public key exchange pairs for this level of security.
SSL proxy is transparent proxy that performs SSL encryption and decryption between the client and the server.
How Does SSL Proxy Work?
SSL proxy provides secure transmission of data between a client and a server through a combination of following:
Authentication-Server authentication guards against fraudulent transmissions by enabling a Web browser to validate the identity of a webserver.
Confidentiality - SSL enforces confidentiality by encrypting data to prevent unauthorized users from eavesdropping on electronic communications; thus ensures privacy of communications.
Integrity- Message integrity ensures that the contents of a communication are not tampered.
SRX Series device acting as SSL proxy manages SSL connections between the client at one end and the server at the other end and performs following actions:
SSL session between client and SRX Series- Terminates an SSL connection from a client, when the SSL sessions are initiated from the client to the server. The SRX Series device decrypts the traffic, inspect it for attacks (both directions), and initiates the connection on the clients’ behalf out to the server.
SSL session between server and SRX Series - Terminates an SSL connection from a server, when the SSL sessions are initiated from the external server to local server. The SRX Series device receives clear text from the client, and encrypts and transmits the data as ciphertext to the SSL server. On the other side, the SRX Series decrypts the traffic from the SSL server, inspects it for attacks, and sends the data to the client as clear text.
Allows inspection of encrypted traffic.
SSL proxy server ensures secure transmission of data with encryption technology. SSL relies on certificates and private-public key exchange pairs to provide the secure communication. For more information, see Managing Certificates and Keys for SSL Proxy.
To establish and maintain an SSL session between the SRX Series device and its client/server, the SRX series device applies security policy to the traffic that it receives. When the traffic match the security policy criteria, SSL proxy is enabled as an application service within a security policy.
SSL Proxy with Application Security Services
Figure 1 shows how SSL proxy works on an encrypted payload.
When Advanced Security services such as application firewall (AppFW), Intrusion Detection and Prevention (IDP),application tracking (AppTrack), UTM, and SkyATP is configured, the SSL proxy acts as an SSL server by terminating the SSL session from the client and establishing a new SSL session to the server. The SRX Series device decrypts and then reencrypts all SSL proxy traffic.
IDP, AppFW, AppTracking, advanced policy-based routing (APBR), UTM, SkyATP, and ICAP service redirect can use the decrypted content from SSL proxy. If none of these services are configured, then SSL proxy services are bypassed even if an SSL proxy profile is attached to a firewall policy.
Types of SSL Proxy
SSL proxy is a transparent proxy that performs SSL encryption and decryption between the client and the server. SRX acts as the server from the client’s perspective and it acts as the client from the server’s perspective. On SRX Series devices, client protection (forward proxy) and server protection (reverse proxy) are supported using same echo system SSL-T-SSL [terminator on the client side] and SSL-I-SSL [initiator on the server side]).
SRX Series device support following types of SSL proxy:
Client-protection SSL proxy also known as forward proxy—The SRX Series device resides between the internal client and outside server. Proxying outbound session, that is, locally initiated SSL session to the Internet. It decrypts and inspects traffic from internal users to the web.
Server-protection SSL proxy also known as reverse proxy—The SRX Series device resides between the internal server and outside client. Proxying inbound session, that is, externally initiated SSL sessions from the Internet to the local server.
For more information on SSL forward proxy and reverse proxy, see Configuring SSL Proxy.
Supported SSL Protocols
The following SSL protocols are supported on SRX Series devices for SSL initiation and termination service:
TLS version 1.0—Provides authentication and secure communications between communicating applications.
TLS version 1.1—This enhanced version of TLS provides protection against cipher block chaining (CBC) attacks.
TLS version 1.2 — This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, TLS version 1.1 and TLS version 1.2 protocols are supported on SRX Series devices along with TLS version 1.0. Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the SSL protocol 3.0 (SSLv3) support is deprecated.
Benefits of SSL Proxy
Decrypts SSL traffic to obtain granular application information and enable you to apply advanced security services protection and detect threats.
Enforces the use of strong protocols and ciphers by the client and the server.
Provides visibility and protection against threats embedded in SSL encrypted traffic.
Controls what needs to be decrypted by using Selective SSL Proxy.
Logical Systems Support
It is possible to enable SSL proxy on firewall policies that are configured using logical systems; however, note the following limitations:
The “services” category is currently not supported in logical systems configuration. Because SSL proxy is under “services,” you cannot configure SSL proxy profiles on a per-logical-system basis.
Because proxy profiles configured at a global level (within “services ssl proxy”) are visible across logical system configurations, it is possible to configure proxy profiles at a global level and then attach them to the firewall policies of one or more logical systems.
Limitations
On all SRX Series devices, the current SSL proxy implementation has the following connectivity limitations:
The SSLv3.0 protocol support is deprecated.
The SSLv2 protocol is not supported. SSL sessions using SSLv2 are dropped.
Only X.509v3 certificate is supported.
Client authentication of SSL handshake is not supported.
SSL sessions where client certificate authentication is mandatory are dropped.
SSL sessions where renegotiation is requested are dropped.
On SRX Series devices, for a particular session, the SSL proxy is only enabled if a relevant feature related to SSL traffic is also enabled. Features that are related to SSL traffic are IDP, application identification, application firewall, application tracking, advanced policy-based routing, UTM, SkyATP, and ICAP redirect service. If none of these features are active on a session, the SSL proxy bypasses the session and logs are not generated in this scenario.
See also
Configuring SSL Forward Proxy
SSL Proxy Configuration Overview
Figure 2 displays an overview of how SSL proxy is configured. Configuring SSL proxy includes:
Configuring the root CA certificate
Loading a CA profile group
Configure SSL proxy profile and associate root CA certificate and CA profile group
Create a security policy by defining input traffic match criteria
Applying an SSL proxy profile to a security policy
Optional steps such as creating whitelists and SSL proxy logging
Configuring a Root CA Certificate
A CA can issue multiple certificates in the form of a tree structure. A root certificate is the topmost certificate of the tree, the private key of which is used to sign other certificates. All certificates immediately below the root certificate inherit the signature or trustworthiness of the root certificate. This is somewhat like the notarizing of an identity.
You can configure a root CA certificate by first obtaining a root CA certificate (by either generating a self-signed one or importing one) and then applying it to an SSL proxy profile. There are two ways you can obtain a root CA certificate—by using the Junos OS CLI on an SRX Series device or by using OpenSSL on a UNIX device.
Generate a Root CA Certificate with CLI
To define a self-signed certificate in CLI, you must provide the following details:
Certificate identifier (generated in the previous step)
Fully qualified domain name (FQDN) for the certificate
e-mail address of the entity owning the certificate
Common name and the organization involved
Generate a root CA certificate using the Junos OS CLI:
- From operational mode, generate a PKI public/private key
pair for a local digital certificate.user@host>request security pki generate-key-pair certificate-id certificate-id size size type type
Example:
user@host>request security pki generate-key-pair certificate-id SECURITY-cert size 2048 type ecdsa - Define a self-signed certificate.user@host>request security pki local-certificate generate-self-signed certificate-id certificate-id domain-name domain-name subject subject email email-id add-ca-constraint
Example:
user@host> request security pki local-certificate generate-self-signed certificate-id SECURITY-cert domain-name labs.abc.net subject DC=mydomain.net,L=Sunnyvale,O=Mydomain,OU=LAB,CN=SECURITY email lab@labs.abc.net add-ca-constraintBy configuring the add-ca-constraint option, you make sure that the certificate can be used for signing other certificates.
- From configuration mode, apply the loaded certificate
as root-ca in the SSL proxy profile.[edit]user@host# set services ssl proxy profile profile-name root-ca certificate-id
Example:
[edit]user@host# set services ssl proxy profile SECURITY-SSL-PROXY root-ca SECURITY-cert - Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.
Generate a Root CA Certificate with OpenSSL
To generate a root CA certificate using OpenSSL:
- Create folders keys and certs.mkdir /etc/pki/tls/keysmkdir /etc/pki/tls/certs
- Change to the openssl directory.cd /etc/pki/tls
- Create a CA certificate key.% openssl genrsa -des3 -out keys/ssl-proxy-ca.key 2048
This step creates an RSA key using the 3DES encryption named ca.key that is 2048 in length. You also need to enter a password that is used to encrypt the private key. This is critical to security if the key is lost because it will still be encrypted.
- Create a CA certificate based on the CA private key (created
in the previous step). % openssl req -new -x509 -days 1095 –key keys/ssl-proxy-ca.key -out certs/ssl-inspect-ca.cer
The expiration date for this certificate is 3 years or 1095 days. However, you can set it to a different value. When creating the certificate, you need to enter the password and the certificate information that includes distinguished name (DN), country name, and so forth.
- Import the CA private and public keys into the SRX Series
device. Copy the ca.key and ca.cer keys to the
/var/tmpdirectory on the SRX Series device. You can copy using SCP, or open the files and copy them into “vi” on the SRX Series device to create new files.user@host> request security pki local-certificate load certificate-id ssl-inspect-ca key /var/tmp/ssl-proxy-ca.key filename /var/tmp/ssl-inspect-ca.cer passphrase password - From configuration mode, apply the loaded certificate
as root-ca in the SSL proxy profile.[edit]user@host# set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca
- Import the root CA as a trusted CA into client browsers. This is required for the client browsers to trust the certificates signed by the SRX Series device. See Importing a Root CA Certificate into a Browser.
Configuring a CA Profile Group
The CA profile defines the certificate information for authentication. It includes the public key that SSL proxy uses when generating a new certificate. Junos OS allows you to create a group of CA profiles and load multiple certificates in one action, view information about all certificates in a group, and delete unwanted CA groups.
You can load a group of CA profiles by obtaining a list of trusted CA certificates, defining a CA group, and attaching the CA group to the SSL proxy profile.
- Obtain a list of trusted CA certificates by using one
of the following methods:
Junos OS provides a default list of trusted CA certificates that you can load on your system. The Junos OS package contains the default CA certificates as a PEM file (for example,
trusted_CA.pem). After you download the Junos OS package, the default certificates are available on your system.From operational mode, load the default trusted CA certificates (the group name identifies the CA profile group):
user@host> request security pki ca-certificate ca-profile-group load ca-group-name group-name filename defaultExample:
user@host> request security pki ca-certificate ca-profile-group load ca-group-name SECURITY-CA-GROUP filename defaultAlternatively, you can define your own list of trusted CA certificates and import them on your system. You get the list of trusted CAs in a single PEM file (for example
IE-all.pem) and save the PEM file in a specific location (for example,/var/tmp). See Knowledge Base Article KB23144.From operational mode, load the trusted list to the device (the group name identifies the CA profile group):
user@host> request security pki ca-certificate ca-profile-group load ca-group-name group-name filename /var/tmp/IE-all.pemExample:
user@host> request security pki ca-certificate ca-profile-group load ca-group-name SECURITY-CA-GROUP filename /var/tmp/custom-file.pem
- Attach the trusted CA or trusted CA group to the SSL proxy
profile. You can attach all trusted CA or one trusted CA at a time:
Attach all CA profile groups:
[edit]user@host# set services ssl proxy profile profile-name trusted-ca allExample
[edit]user@host# set services ssl proxy profile SECURITY-SSL-PROXY trusted-ca allAttach one CA profile group (the group name identifies the CA profile group).
[edit]user@host# set services ssl proxy profile profile-name trusted-ca ca-nameExample
[edit]user@host# set services ssl proxy profile SECURITY-SSL-PROXY trusted-ca orgA-ca-profile
You can easily display information about all certificates in a CA profile group:
You can delete a CA profile group. Remember that deleting a CA profile group deletes all certificates that belong to that group:
Importing a Root CA Certificate into a Browser
In order to have your browser or system automatically trust all certificates signed by the root CA configured in the SSL proxy profile, you must instruct your platform or browser to trust the CA root certificate.
To import a root CA certificate:
- Generate a PEM format file for the configured root CA.request security pki local-certificate export certificate-id root-ca type pem filename path/file-name.pem
- Import a root CA certificate into a browser.
From Internet Explorer (version 8.0):
- From the Tools menu, select Internet Options.
- On the Content tab, click Certificates.
- Select the Trusted Root Certification Authorities tab and click Import.
- In the Certificate Import Wizard, navigate to the required root CA certificate and select it.
From Firefox (version 39.0):
- From the Tools menu, select Options.
- From the Advanced menu, select the Certificates tab and click View Certificate.
- In the Certificate Manager window, select the Authorities tab and click Import.
- Navigate to the required root CA certificate and select it.
From Google Chrome (45.0):
- From the Settings menu, select Show Advanced Settings.
- From the Advanced menu, select the Certificates tab and click View Certificate.
- Under HTTPS/SSL, click Manage Certificates.
- In the Certificate window, select Trusted Root Certification Authorities and click Import.
- In the Certificate Import Wizard, navigate to the required root CA certificate and select it.
Applying an SSL Proxy Profile to a Security Policy
SSL proxy is enabled as an application service within a security policy. In a security policy, you specify the traffic that you want the SSL proxy enabled on as match criteria and then specify the SSL proxy CA profile to be applied to the traffic. Figure 3 displays a graphical view of SSL proxy profile and security policy configuration.
To enable SSL proxy in a security policy:
This example assumes that you have already creates security zones trust and untrust and creating a security policy for the traffic from trust zone to untrust zone.
- Create a security policy and specify the match criteria
for the policy. As match criteria, specify the traffic for which you
want to enable SSL proxy. [edit]user@host# set security policies from-zone trust to-zone untrust policy policy-name match source-address source-addressuser@host# set security policies from-zone trust to-zone untrust policy policy-name match destination-address destination-addressuser@host# set security policies from-zone trust to-zone untrust policy policy-name match application application
Example:
[edit]user@host# set security policies from-zone trust to-zone untrust policy SECURITY_POLICY match source-address anyuser@host# set security policies from-zone trust to-zone untrust policy policy SECURITY_POLICY match destination-address anyuser@host# set security policies from-zone trust to-zone untrust policy policy SECURITY_POLICY match application any - Apply the SSL proxy profile to the security policy.[edit]user@host# set security policies from-zone trust to-zone untrust policy policy SECURITY_POLICY then permit application-services ssl-proxy profile-name SECURITY-SSL-PROXY
Configuring SSL Proxy Logging
When configuring SSL proxy, you can choose to set the option to receive some or all of the logs. SSL proxy logs contain the logical system name, SSL proxy whitelists, policy information, SSL proxy information, and other information that helps you troubleshoot when there is an error.
You can configure logging of all or specific events, such as error, warning, and information events. You can also configure logging of sessions that are whitelisted, dropped, ignored, or allowed after an error occurs.
You can use enable-flow-tracing option to enable debug tracing.
Configuring Certificate Authority Profiles
A certificate authority (CA) profile configuration contains information specific to a CA. You can have multiple CA profiles on an SRX Series device. For example, you might have one profile for orgA and one for orgB. Each profile is associated with a CA certificate. If you want to load a new CA certificate without removing the older one then create a new CA profile (for example, Microsoft-2008). You can group multiple CA profiles in one trusted CA group for a given topology.
In this example, you create a CA profile called ca-profile-security with CA identity microsoft-2008. You then create proxy profile to the CA profile.
- From configuration mode, configure the CA profile used
for loading the certificate.[edit]user@host# set security pki ca-profile profile-name ca-identity ca-identity
Example:
user@host# set security pki ca-profile ca-profile-security ca-identity example.com - Commit the configuration.[edit]user@host# commit
- From operational mode, load the certificate using PKI
commands.user@host> request security pki ca-certificate load ca-profile profile-name filename filename
Example:
user@host> request security pki ca-certificate load ca-profile ca-profile-security filename srx-123.crt - From configuration mode, disable the revocation check
(if required).[edit]user@host# set security pki ca-profile profile-name ca-identity ca-identity revocation-check disable
Example:
[edit]user@host# set security pki ca-profile ca-profile-security ca-identity example.com revocation-check disable - From configuration mode, configure the loaded certificate
as a trusted CA in the SSL proxy profile. [edit]user@host# set services ssl proxy profile ssl-proxy-profile-name trusted-ca ca-profile-name
Example:
[edit]user@host# set services ssl proxy profile ssl-proxy-sample trusted-ca ca-profile-securityNote More than one trusted CA can be configured for a profile.
- (Optional) If you have multiple trusted CA certificates,
you do not have to specify each trusted CA separately. You can load all the trusted CA certificates using the following command
from configuration mode.[edit]user@host# set services ssl proxy profile ssl-proxy-profile-name root-ca ssl-inspect-causer@host# set services ssl proxy profile ssl-proxy-profile-name trusted-ca all
Note Alternatively, you can import a set of trusted CAs from your browser into the SRX Series device. See Knowledge Base article KB23144.
Exporting Certificates to a Specified Location
When a self-signed certificate is generated using a PKI command,
the newly generated certificate is stored in a predefined location
(var/db/certs/common/local).
Use the following command to export the certificate to a specific location (within the device). You can specify the certificate ID, the filename, and the type of file format (DER/PEM):
Ignoring Server Authentication
Junos OS allows you to configure an option to ignore server authentication completely. If you configure your system to ignore authentication, then any errors encountered during server certificate verification at the time of the SSL handshake are ignored. Commonly ignored errors include the inability to verify CA signature, incorrect certificate expiration dates, and so forth. If this option is not set, all the sessions where the server sends self-signed certificates are dropped when errors are encountered.
We do not recommend using this option for authentication because configuring it results in websites not being authenticated at all. However, you can use this option to effectively identify the root cause of dropped SSL sessions.
From configuration mode, specify to ignore server authentication:
See also
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, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 devices and vSRX instances. Table 1 shows the supported levels for trace options.
Table 1: Trace Levels
Cause Type | Description |
|---|---|
Brief | Only error traces on both the Routing Engine and the Packet Forwarding Engine. |
Detail | 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 |
Extensive | 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. |
Verbose | All traces are available. |
Table 2 shows the flags that are supported.
Table 2: Supported Flags in Trace
Cause Type | Description |
|---|---|
cli-configuration | Configuration-related traces only. |
initiation | Enable tracing on the SSL-I plug-in. |
proxy | Enable tracing on the SSL-Proxy-Policy plug-in. |
termination | Enable tracing on the SSL-T plug-in. |
selected-profile | 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.
See also
Transport Layer Security (TLS) Overview
Transport Layer Security (TLS) is an application-level protocol that provides encryption technology for the Internet. TLS relies on certificates and private-public key exchange pairs for this level of security. It is the most widely used security protocol for the applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging, and voice over IP (VoIP).
TLS protocol is used for certificate exchange, mutual authentication, and negotiating ciphers to secure the stream from potential tampering and eavesdropping. TLS is sometimes called as Secure Sockets Layer (SSL). TLS and SSL are not interoperable, though TLS currently provides some backward compatibility.
SRX Series devices provides TLS inspection that use the TLS protocol suite consisting of different TLS versions, ciphers, and key exchange methods. TLS inspection feature enables SRX Series devices to inspect HTTP traffic encrypted in TLS on any port.
Benefits of TLS
TLS ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity.
TLS Versions
Following are the versions of TLS:
TLS version 1.0—Provides secure communication over networks by providing privacy and data integrity between communicating applications
TLS version 1.1—This enhanced version of TLS provides protection against cipher-block chaining (CBC) attacks.
TLS version 1.2 — This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.
Starting with Junos OS Release 12.3X48-D30, SRX Series devices support TLS version 1.2. SRX Series devices running earlier release of 12.3X48-D30, supports TLS version 1.0.
Three Essential Services of TLS
The TLS protocol is designed to provide three essential services to the applications running above it: encryption, authentication, and data integrity.
Encryption—In order to establish a cryptographically secure data channel, the server and the client must agree on which cipher suites are used and the keys used to encrypt the data. The TLS protocol specifies a well-defined handshake sequence to perform this exchange. TLS uses public key cryptography, which allows the client and server to negotiate a shared secret key without having to establish any prior knowledge of each other, and to do so over an unencrypted channel.
Authentication—As part of the TLS handshake, the protocol allows both server and the client to authenticate their identity. Implicit trust between the client and the server (because the client accepts the certificate generated by the server) is an important aspect of TLS. It is extremely important that server authentication is not compromised; however, in reality, self- signed certificates and certificates with anomalies are in abundance. Anomalies can include expired certificates, instances of common name not matching a domain name, and so forth.
Integrity—With encryption and authentication in place, the TLS protocol does message framing mechanism and signs each message with a Message Authentication Code (MAC). The MAC algorithm does the effective checksum, and the keys are negotiated between the client and the server.
TLS Handshake
Each TLS session begins with a handshake during which the client and server agree on the specific security key and the encryption algorithms to use for that session. At this time, the client also authenticates the server. Optionally, the server can authenticate the client. Once the handshake is complete, transfer of encrypted data can begin.
Encrypting Syslog Traffic with TLS
TLS protocol ensures the syslog messages are securely sent and received over the network. TLS uses certificates to authenticate and encrypt the communication. The client authenticates the server by requesting its certificate and public key. Optionally, the server can also request a certificate from the client, thus mutual authentication is also possible.
A certificate on the server that identifies the server and the certificate of certificate authority (CA) issued by the server must be available with the client for TLS to encrypt syslog traffic.
For mutual authentication of client and the server, a certificate with the client that identifies the client and the certificate of CA issued by client must be available on the server. Mutual authentication ensures that the syslog server accepts log messages only from authorized clients.
Configuring the TLS Syslog Protocol on SRX Series device
This example shows how to configure the Transport Layer Security (TLS) syslog protocol on SRX Series devices to receive encrypted syslog events from network devices that support TLS syslog event forwarding.
Requirements
Before you begin, enable server certificate verification and encryption or decryption capabilities.
Overview
TLS syslog protocol enables log sources to receive encrypted syslog events from network devices that supports TLS syslog event forwarding. The log source creates a listen port for incoming TLS syslog events and generates a certificate file for the network devices.
In this example, you will configure a syslog collector associated with one SSL-I profile. Each SSL-I profile will enable the user to specify things like preferred ciphers suite and trusted CA certificates. Multiple SSL-I profiles can be configured and associated to different collector servers.
Configuration
CLI Quick Configuration
To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure TLS syslog protocol:
- Set the log mode to stream.[edit security]user@host# set log mode stream
- Set the format for remote security message logging to
sd-syslog (structured system log).[edit security]user@host# set log format sd-syslog
- Set the host source interface number.[edit security]user@host# set log source-interface ge-0/0/1.0
- Set security log transport protocol tls to be used to
log the data.[edit security]user@host# set log transport protocol tls
- Specify the TLS profile name. [edit security]user@host# set log transport tls-profile ssl-i-tls
- Set the log stream to use the structured syslog format
for sending logs to server 1.[edit security]user@host# set log stream server1 format sd-syslog
- Set the category of server 1 logging to all .[edit security]user@host# set log stream server1 category all
- Set server host parameters by entering the server name
or IP address.[edit security]user@host# set log stream server1 host 192.0.2.100
- Define the protocol version all for SSL initiation access
profile.[edit services]user@host# set ssl initiation profile ssl-i-tls protocol-version all
- Attach all CA profile groups to the SSL initiation profile
to use when requesting a certificate from the peer.[edit services]user@host# set ssl initiation profile ssl-i-tls trusted-ca all
- Define the SSL initiation access profile to ignore the
server authentication failure.[edit services]user@host# set ssl initiation profile ssl-i-tls actions ignore-server-auth-failure
Results
From configuration mode, confirm your configuration by entering the show security log command. If the output does not display the intended configuration, then repeat the configuration instructions in this example to correct it.
If you are done configuring the device, enter commit from configuration mode.
Verification
To verify that the configuration is working properly, enter the show log command on the syslog server.