Implementing SSL Orchestrator - Guided Configuration

Introduction

This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ.

Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on the SSL Orchestrator Guided Configuration and everything you need to know about it.

This article is divided into the following high level sections:

  • Configuration prerequisites
  • Deployment Topology
  • SSL certificate and key settings
  • Service properties
  • Security policy
  • Interception rule

Please forgive me for using SSL and TLS interchangeably in this article.

Software versions used in this article:

BIG-IP Version: 14.1.2

SSL Orchestrator Version: 5.5

BIG-IQ Version: 7.0.1

Configuration Prerequisites

From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration. This is the default landing page when SSL Orchestrator is not configured. The configuration options are presented on this page. Notice the Required Configuration settings on the top right. For DNS click the link to configure.

Enter the IP address of the DNS server you wish to use and click Add. You can add multiple DNS servers. Click Update when done.

Click SSL Orchestrator > Configuration. For NTP click the link to configure.

Enter the IP address or hostname of the NTP server you wish to use and click Add. You can add multiple NTP servers. Click Update when done.

Click SSL Orchestrator > Configuration. For Route click the link to configure.

Name it. In this example it’s default_route. Enter the correct Destination and Netmask. In this example we’re using 0.0.0.0 as this is a default route. Enter the Gateway IP Address, in this example 10.0.0.1.

Click Finished.

Click SSL Orchestrator > Configuration. The Required Configuration section should look like the following.

Deployment Topology

We are now ready to begin the Guided Configuration. Click Next at the bottom.

Choose the Topology you would like to deploy. In this example we will configure an L3 Outbound Topology.

Name the Topology. For the Protocol choose Any. Select L3 Outbound then click Save & Next

Note: some of the available Topologies might be greyed out if not supported by your platform. As an example, virtual machines don’t support L2.

SSL Certificate and Key Settings

Leave the Certificate Key Chain settings to their defaults. 

Edit the existing CA Certificate Key Chain by clicking the pencil icon.  

In a previous article you installed your own private key and certificate. Click the down arrow on the right to select that Certificate and Key. Click Done.

Click Save & Next

Notes: The difference between the Cert Key Chain and the CA Cert Key Chain:

Certificate Key Chain – the certificate key chain represents the certificate and private key used as the “template” for forged server certificates. While re-issuing server certificates on-the-fly is generally easy, private key creation tends to be a CPU-intensive operation. For that reason, the underlying SSL Forward Proxy engine forges server certificates from a single defined private key. This setting gives customers the opportunity to apply their own template private key, and optionally store that key in a FIPS-certified HSM for additional protection. The built-in “default” certificate and private key uses 2K RSA and is generated from scratch when the BIG-IP system is installed. The pre-defined default.crt and default.key can be left as is.

CA Certificate Key Chain – an SSL forward proxy must re-sign, or “forge” remote server certificate to local clients using a local certificate authority (CA) certificate, and local clients must trust this local CA. This setting defines the local CA certificate and private key used to perform the forging operation.

Service Properties

Click Add Service

You can choose from many pre-defined templates from different security vendors. In this example select Palo Alto Networks NGFW Inline Layer 2 then click Add.

Give it a name. Under Network Configuration click Add.

Here you define the VLANS that the Palo Alto is connected to (or will be connected to). You can use existing ones or create new VLANS. We will create new ones by choosing the Create New radio button.  Give each VLAN a unique name to help remember which device it’s connected to and in which direction data flows. Select the Interface from the drop-down menu. Click Done.

Enable the Port Remap option and leave the port at 80.

Click Save

Notes: SSL Orchestrator allows for the insertion of additional iRule logic at different points. An iRule defined at the service only affects traffic flowing across this service. It is important to understand, however, that these iRules must not be used to control traffic flow (ex. pools, nodes, virtuals, etc.), but rather should be used to view/modify application layer protocol traffic. For example, an iRule assigned here could be used to view and modify HTTP traffic flowing to/from the service.

Click Save & Next

Click the button to Add a Service Chain List

Give it a name. Click the arrow in the middle to move the Palo Alto Service to the Selected side. Click Save.

Note: When you have multiple Services in a Service Chain you can adjust the order that they are used.

Your screen should like the following. Click Save & Next.

Security Policy

The Security Policy is next. Notice you have the option to create new or use an existing one. By default, the policy should look like this.

The Name is populated automatically but can be changed. If you click the pencil icon to the far right of the Pinners_Rule you can see the contents of the rule.

The Pinners_Rule checks to make sure the content is SSL/TLS. It also checks the category “Pinners” which contains websites with Pinned Certificates. Sites in the category Pinners are automatically set to Bypass decryption. It is recommended to keep this setting.

Notes: If you have a URL categorization database you can also bypass decryption based on website category.

Conditions can be toggled between Match Any and Match All. Actions can be to Allow or Reject. Also note the Service Chain is bypassed by default. However, you can choose to send the encrypted content through the Security Chain.

Click Cancel.

The Pinners Category can be viewed/edited from SSL Orchestrator > Policies > URL Categories. Expand Custom Categories and you will see the Pinners category. Click Pinners (custom) to view and/or edit the sites.

Back to the Security Policy. Click the pencil icon to the far right of the All Traffic rule to edit it.  

Set the Service Chain to the one created previously, in this case it’s ssloSC_SecurityServiceChain. Click OK.

Click Save & Next at the bottom.

Interception Rule

Next is the Interception Rule. For Ingress Network select the VLAN that internal clients connect through. In this example select INTERNAL and click the arrow to move it to Selected. Note that you can also create VLANS from this screen.

Click Save & Next at the bottom.

Notes: L7 Interception Rules – FTP and email protocol traffic are all “server-speaks-first” protocols, and therefore SSL Orchestrator must process these separately from typical client-speaks-first protocols like HTTP. This selection enables processing of each of these protocols, which create separate port-based listeners for each. As required, selectively enable the additional protocols that need to be decrypted and inspected through SSL Orchestrator.

Egress Settings

For the Egress Settings Click Save & Next at the bottom.

Last is the Summary screen. You can review and edit any of the Configurations we just went through. Click Deploy when done. The next screen should look like the image below.

Click OK and you should see something like the following:

Notes: The Palo Alto Service is shown as DOWN in red. This is because we haven’t configured it yet. We’ll do that in the next article.

Summary

In this article you learned how to use the SSL Orchestrator Guided Configuration to do the following:

  • Configuration prerequisites
  • Deployment Topology
  • SSL certificate and key settings
  • Service properties
  • Security policy
  • Interception rule

Next Steps

Click Next to proceed to the next article in the series.

Published Jan 10, 2020
Version 1.0
  • Mostly correct. There are three primary reasons for exposing the Certificate Key Chain control in the UI:

    • Allowing you to specify your own template key. The built-in 'default.key' is an RSA2048/SHA256 key that is auto-generated when the BIG-IP system is installed, so will be globally unique in hardware platforms, but may be duplicated in virtual environments if the VE is cloned.
    • Allowing you to insert the template key into a hardware security module (HSM) solution. Server certificates (re)issued by the local CA cert/key are ephemeral (short-lived, in-memory only), so the security impact here is negligible. However for some environments where 'all' keys must be stored in an HSM, this option makes that possible.
    • Allowing you to specify multiple types of certs - for example RSA and ECC. In this way, if a client negotiates ECDHE with SSLO, SSLO can issue an ECC server cert.
  • Hi,

    Just to verify if I understood it correctly: Notes: The difference between the Cert Key Chain and the CA Cert Key Chain:

    So process of creating forget certificates looks like that:

    1. Key installed using Certificate Key Chain is used to generate CSR with copy of data from original site certyficate
    2. Key installed via CA Certificate Key Chain is used to sign CSR

    If above is true key set via Certificate Key Chain can be used to control type and size of key used to create forget certificate - Am I right?

    Piotr