TechLibrary

Navigation Back up to About Overview

OBSOLETE-Example: Creating a Configuration Workflow for SSL Proxy

SSL proxy works transparently between the client and the server. All requests from a client first go to the proxy server; the proxy server evaluates the request, and if the request is valid, forwards the request to the outbound side. Similarly, inbound requests are also evaluated by the proxy server. Both client and server think that they are communicating with each other; however, it is the SSL proxy that functions between the two.

SSL proxies provide encryption and decryption by sitting between the server and the client. Because SSL proxies are hidden from both the server and the client, secret keys are shared between the two in order to decrypt the SSL traffic. Proxies are known as “forward proxies” because proxy servers are used to hide any detail information from the servers.

Integrity, confidentiality, and authenticity of traffic is validated through Public Key Infrastructure (PKI) that includes digital certificates issued by the Certificate Authority (CA), certificate validity and expiration dates, details about the certificate owner and issuer, and security policies.

Requirements

Before you begin:

Overview

The configuration example in Figure 1shows how to configure a workflow for SSL proxy that includes configuring a root CA, creating a whitelist of addresses, creating an SSL profile, and enabling SSL proxy service on traffic by means of a policy.

Figure 1: SSL Proxy Configuration Workflow

SSL Proxy Configuration
Workflow

Configuration

Generating and Configuring a Root CA

Step-by-Step Procedure

In this example, you generate and then import a certificate that is used as the root CA by the device. There are two ways of generating a root CA certificate:

  • Generating self-signed root CA certificates in the SRX Series device.
  • Generating self-signed root CA certificates using openssl.
  1. Generate a self-signed root CA certificate in the SRX Series device.

    A root certificate can be generated on the device using a self-signed certificate that has the CA attribute set to true.

    To enable CA:TRUE while generating a self-signed certificate, you must enable the add-ca-constraint using the following command:

    user@host> request security pki local-certificate generate-self-signed

    The following sample output shows other possible completions:

    user@host> request security pki local-certificate generate-self-signed ?
    Possible completions:
      certificate-id       Certificate identifier
      domain-name          Fully qualified domain name
      email                Email address of the entity owning the certificate
      ip-address           Static IP address of the device
      subject              DC=<Domain component>, CN=<Common-Name>, OU=<Organizational-Unit-name>, O=<Organization-name>, L=<Locality> T=<state>, C=<Country>
    + add-ca-constraint  Certificate can be used for signing other certificates
  2. Generate an SSL certificate using openssl.

    This section of the example uses the openssl command to generate an SSL certificate. Typically openssl is installed under /etc/pki/tls.

    Note: You should run the openssl command on a UNIX device because Juniper Networks Services Gateways do not support the openssl command.

    1. Create two folders, keys and certs (if the folders already do not exist) in the following paths:
      mkdir /etc/pki/tls/keysmkdir /etc/pki/tls/certs
    2. Change to the openssl directory.
      cd /etc/pki/tls
    3. Create a CA certificate key. The following command 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.
      % openssl genrsa -des3 -out keys/ssl-proxy-ca.key 2048
    4. Generate the certificate. The following command creates the CA certificate based on the CA private key created in step c. 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.
      % openssl req -new -x509 -days 1095 –key keys/ssl-proxy-ca.key -out certs/ssl-inspect-ca.cer
    5. (Optional) Export the CA public key in DER format. The following command exports the CA’s public key in DER format. The DER format is used to import the CA as a trusted CA and is required for the client to trust the certificates signed by the SRX Series device.
      % openssl x509 -in certs/ssl-inspect-ca.cer outform DER -out certs/ssl-inspect-ca.der

      Note: Junos OS supports loading of CA certificates in X509, PKCS #7, DER, or PEM formats.

    6. Import the CA private and public keys into the SRX Series device. Copy the ca.key and ca.cer to the /var/tmp directory 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-inspect-ca.key filename /var/tmp/ssl-inspect-ca.cer passphrase password
  3. From configuration mode, configure the loaded certificate as root-ca in the SSL proxy profile.
    user@host# set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca

Configuring a Trusted-CA

Step-by-Step Procedure

Import the trusted CA certificate profile-ca1.crt from your browser’s certificate store on to your SRX Series device. The certificate configured under the trusted CA is used for validating the server certificate chain. The certificate that is configured under the trusted CA must first be loaded using the PKI commands.

Note: Use the ignore-server-auth-failure option if you do not want to import the entire CA list and you do not want dropped sessions.

  1. From configuration mode, configure the CA profile profile-ca1 used for loading the certificate.
    user@host# set security pki ca-profile profile-ca1 ca-identity profile-ca1
  2. From operational mode, load the certificate using the PKI commands.
    user@host> request security pki ca-certificate load ca-profile profile-ca1 filename profile-ca1.crt
  3. From configuration mode, disable the revocation check.

    Note: Certificate revocation list (CRL) checks are not yet supported; we recommend that you disable revocation checks.

    user@host# set security pki ca-profile profile-ca1 ca-identity profile-ca1 revocation-check disable
  4. From configuration mode, configure the loaded certificate as a trusted CA in the SSL proxy profile.
    user@host# set services ssl proxy profile ssl-inspect-profile trusted-ca profile-ca1

    Note: More than one trusted CA can be configured for a profile.

  5. (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 under set security pki using the following command from configuration mode.
    user@host# set services ssl proxy profile ssl-inspect-profile trusted-ca all

    Note: Alternately, you can import a set of trusted CAs from your browser into the SRX Series device. For more information, refer to the Knowledge Base article KB23144. See .

Loading a CA profile group

Step-by-Step Procedure

Configuring a Trusted-CA shows how to load a CA profile. Alternately, you can also load a CA profile group. Use the following steps to load a CA profile group:

  1. Get the list of trusted CAs in a single PEM file, for example IE-all.pem. Save the PEM file in a specific location, for example, /var/tmp. For more information, refer to the Knowledge Base article KB23144. See http://kb.juniper.net/InfoCenter/index?page=content&id;=KB23144.
  2. Load the trusted list to the device using the following command (the group name identifies the profile group):
    user@host> request security pki ca-certificate ca-profile-group load ca-group-name <group-name> filename /var/tmp/IE-all.pem
  3. View information about all certificates in a CA group using the following command:
    user@host> show security pki ca-certificates ca-profile-group <group-name>
  4. Delete a CA group using the following command (the command unloads all certificates that belong to that group):
    user@host> clear security pki ca-certificates ca-profile-group <group-name>
  5. (Optional) Attach individual CA groups or “all” CA groups (or CA profiles) to an SSL proxy profile using the following command:
    user@host# set services ssl proxy profile ssl-inspect-profile trusted-ca

    The following sample output shows other possible completions:

    user@host# set services ssl proxy profile ssl-inspect-profile trusted-ca ?
      Possible completions:
      <ca-profile-name>   Select CA profile/profile-group name
      [                  Open a set of values
      all                Select all CA profiles.  <----------------------------- select all ca-profiles under ‘security pki ca-profile’
      IE-all             [security pki ca-profile-group <*>]  <-------  select a ca-profile-group
      IE-all_1_sysgen    [security pki ca-profile <*>]	   <-------   select ca-profile
      IE-all_2_sysgen    [security pki ca-profile <*>]	     
    ----<more>------
    

Creating a Whitelist of Exempted Destinations

Step-by-Step Procedure

SSL proxy is enabled by means of a security policy defined using whitelist addresses and address sets. Whitelists comprise addresses that are exempted from the SSL proxy. Whitelist addresses and address sets must be created under the global address book.

The following type of addresses (from global address-book) are supported:

  • IPv4 addresses (plain text). For example:
    user@host# set security address-book global address <address-name> <ipv4-prefix>
  • IPv4 address range. For example:
    user@host# set security address-book global address <address-name> range-address <range-low> to <range-high>
  • IPv4 wildcard. For example:
    user@host# set security address-book global address <address-name> wildcard-address <a.d.d.r/netmask>

    Noncontiguous netmasks are not supported. For example:

    • 5.0.0.1/255.255.0.0 is supported.
    • 5.0.0.1/255.255.0.255 is NOT supported.
  • IPv6 address (plain text). For example:
    user@host# set security address-book global address <address-name> <ipv6-prefix>
  • DNS name. For example:
    user@host# set security address-book global address <address-name> dns-name <domain-name>

For example, if you want to exempt all sessions to www.juniper.net from undergoing SSL proxy processing, then you would include www.juniper.net in the whitelist. The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see .

  1. Configure the domain in the address book.
    user@host# set security address-book global address ssl-inspect-exempt dns-name www.juniper.net

    Note: For the sake of brevity, this example uses a domain name. You can also configure IP addresses (IPv4 and IPv6), IP address range (IPv4 and IPv6), or wildcards (IPv4).

  2. Configure the address in the SSL proxy profile.
    user@host# set services ssl proxy profile ssl-inspect-profile whitelist ssl-inspect-exempt

Setting ignore-server-auth-failure and Logs

Step-by-Step Procedure

If ignore-server-auth-failure is set, 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 if any errors are encountered.

The logs option can be set to receive some or all of the logs. Logs contain information on the following: logical system name, SSL proxy whitelists, policy information, SSL proxy information, and so forth.

  1. Configure the ignore-server-auth-failure option.
    user@host# set services ssl proxy profile ssl-inspect-profile actions ignore-server-auth-failure
  2. Configure the logs option.
    user@host# set services ssl proxy profile ssl-inspect-profile actions log all

    The following sample output shows other possible completions for the logs option:

    user@host# set services ssl proxy profile ssl-inspect-profile actions log ?          
      Possible completions:
        <[Enter]>            Execute this command
        all                  Log all events
        errors               Log all error events 
        info                 Log all information events 
        sessions-allowed     Log ssl session allow events after an error
        sessions-dropped     Log only ssl session drop events
        sessions-ignored     Log  session ignore events 
        sessions-whitelisted  Log ssl session whitelist events 
        warning              Log all warning events
    
  3. Optionally, you can also configure the following SSL profile elements:
    • preferred-ciphers–Ciphers are divided in three categories depending on their key strength: strong, medium, or weak.
    • custom-ciphers–If you do not want to use one of the three categories, you can select ciphers from each of the category to form a custom cipher set.
    • enable-flow-tracing–Allows you to enable debug tracing.

Exporting a Certificate to a Specified Location

Step-by-Step Procedure

Currently, 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).

  1. Using the following command, you can now export the certificate to a specific location (within the device) using the specified format (DER/PEM):
    user@host> request security pki local-certificate export

    The following sample output shows other possible completions:

    user@host> request security pki local-certificate export ?
    Possible completions:
       + certificate-id   Certificate identifier.
       + filename         Filename of the new certificate. Provide absolute path.
       + type             Type of certificate.
    
    user@host> request security pki local-certificate export type ?
    Possible completions:
       + der            DER format.
       + pem            PEM format.

Applying an SSL Proxy to a Policy

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

set security policies from-zone trust to-zone untrust policy P1 match source-address anyset security policies from-zone trust to-zone untrust policy P1 match destination-address anyset security policies from-zone trust to-zone untrust policy P1 match application junos-httpsset security policies from-zone trust to-zone untrust policy P1 then permit application-services ssl-proxy profile-name ssl-inspect-profile

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 .

To create a policy that enables SSL proxy:

  1. Enable SSL proxy service on a traffic stream by means of a policy.
    user@host# set security policies from-zone trust to-zone untrust policy P1 match source-address anyuser@host# set security policies from-zone trust to-zone untrust policy P1 match destination-address anyuser@host# set security policies from-zone trust to-zone untrust policy P1 match application junos-httpsuser@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services ssl-proxy profile-name ssl-inspect-profile

Results

From configuration mode, confirm your configuration by entering the show security policies and show services ssl proxy commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

user@host# show security policies
from-zone trust to-zone untrust {
            policy P1 {
                match {
                    source-address trust;
                    destination-address untrust;
                    application junos-https;
                }
                then {
                    permit {
                        application-services {
                           ssl-proxy {
                                profile-name ssl-inspect-profile;
                            }
user@host# show services ssl proxy
 profile ssl-inspect-profile {
            trusted-ca [profile_ca1 ca-google ca-geotrust ca-digicert-3 ca-cyber-trust ca-digicert-root-ca ];
            root-ca ssl-inspect-ca;
            whitelist ssl-inspect-exempt;
            actions {
                 ignore_server_auth_failure;
                 logs {
                      all; 
                 }
            }     
        }

Note: For application junos-https, SSL proxy detects an SSL session based on the dynamic application identified for that section; for more information on dynamic application identification, see . If you know any webservers that are running nonstandard ports, you can use a custom Junos OS application to identify the application. However, if the webservers are not known, for example on the Internet, use application any. Non-SSL sessions that come across the policy rule are ignored by SSL proxy. A syslog SSL_PROXY_SESSION_IGNORE is sent out for these sessions. We recommend that you use application “any” with caution because this can result in a lot of traffic, incurring initial SSL proxy processing and thereby impacting performance.

Verification

Verifying SSL Proxy Information

Purpose

Verify that the SSL proxy is correctly configured.

Action

From operational mode, enter the show services ssl proxy statistics command. This command displays the counters for the SSL traffic.

user@host> show services ssl proxy statistics
sessions matched                      30647
        sessions whitelisted                      0
        sessions bypassed:non-ssl                 0
        sessions bypassed:mem overflow            0
        sessions created                      25665
        sessions ignored                          6
        sessions active                           0
        sessions dropped                          0
        

Published: 2014-05-13