2.1. Topology Prerequisites¶
2.1.1. What it is¶
There are a few things required by the SSL Orchestrator Guided Configuration workflow that cannot be configured within its workflow. This section details these component prerequisites.
2.1.2. How to build it¶
The following components are required before starting any SSL Orchestrator workflow:
Certificates - TLS decryption requires certificates. SSL Orchestrator will use different types of certificates depending on forward or reverse proxy topology types.
Forward Proxy - for outbound traffic flows where the remote resource owns the encryption keys, SSL Orchestrator must re-issue (forge) the remote server certificate from a local certificate authority (CA). In the forward proxy flow, the F5 BIG-IP will first fetch and validate the real remote server certificate, then create a new locally issued version of that certificate. Upon client-side TLS handshake, SSL Orchestrator will present this locally issued server certificate to the client. The client in turn must trust the local certificate authority. For forward proxy topologies, SSL Orchestrator minimally needs a CA certificate and its private key. The CA certificate should have the following minimal attributes:
keyUsage: certificate extension containing “keyCertSign” and “digitalSignature” attributes. basicConstraints: (18.104.22.168) indicating “CA = true” (or Yes), marked as Critical.
In organizations that have a Certificate Authority service deployed, it is a recommended practice to issue a subordinate CA to SSL Orchestrator. A subordinate is a CA certificate that is issued by a higher-level CA, which may be the self-signed “root” CA, or another subordinate. When issued by another subordinate, a multi-level chain of CAs is created:
Root CA -> Subordinate CA -> Subordinate CA
This multi-level CA approach provides additional scale to large enterprise CA infrastructures, and also an additional level of protection, as it further removes the valuable root CA from direct involvement in day-to-day activities. In an SSL forward proxy topology, SSL Orchestrator uses a CA certificate and private key to re-issue (forge) remote server certificates, thus the internal client must trust this local issuing CA. The client might not, however, possess all of the CA certificates needed to build a complete trust chain (issuer CA to the root CA). There are two options here:
Install all of the CA certificates on client devices.
Use certificate chain bundles to pass subordinate CAs to the client during the TLS handshake. A certificate chain bundle is a flat text file containing a set of PEM-encoded certificates. This file can contain all of CA certificates up to but not including the root CA, which must be installed and trusted explicitly. Please refer to https://support.f5.com/csp/article/K13302 for additional information on creating certificate chain bundles.
Section 4.4 provides instructions for creation various types of certificates.
Reverse Proxy - for inbound traffic flows where the F5 BIG-IP owns the encryption keys, SSL Orchestrator performs standard decryption based on the end-entity (server) certificates provided. An end-entity server certificate should match the DNS hostname that clients use to access the site. For Internet-accessible applications, a reverse proxy certificate is typically obtained from a commercial Certificate Authority.
Client-facing VLAN and self-IP - traffic ingresses to the SSL Orchestrator via at least one VLAN. For layer 3 topologies, the F5 BIG-IP must be configured with a client-facing VLAN and self-IP, which must be done outside of the SSL Orchestrator UI. An SSL Orchestrator topology can consume traffic from multiple VLANs as needed.
Server-facing VLAN and self-IP - traffic egresses the SSL Orchestrator via at least one VLAN. For layer 3 topologies, the F5 BIG-IP must be configured with a server-facing VLAN and self-IP, which must be done outside of the SSL Orchestrator UI. An SSL Orchestrator topology can egress traffic to multiple VLANs as needed.
ICAP service VLAN and self-IP - (optional) If an ICAP service will also be configured, and on a separate VLAN than the above, an ICAP-facing VLAN and self-IP must also be defined. F5 recommends configuring ICAP devices on a dedicated VLAN that is only accessible to SSL Orchestrator.
NTP server definition - time synchronization is required between F5 BIG-IP peers in a high availability (HA) configuration. NTP settings can be defined in the BIG-IP UI under System -> Configuration -> Device -> NTP.
SSL Orchestrator in a vCMP environment - F5 Virtual Multiprocessing (vCMP) is a hypervisor-based BIG-IP platform option, where (virtual) BIG-IP vCMP guests are managed by a hypervisor vCMP host. The host allocates system resources to vCMP guests as needed. SSL Orchestrator is supported in this vCMP model, with the one caveat that the VLANs used by inline security services must be created by the vCMP host system. In non-vCMP systems, the SSL Orchestrator configuration creates all of the necessary network objects for inline services. However, for vCMP systems, the host must create the VLANs. During service creation, you will choose an existing VLAN in lieu of creating one directly.