Bluecoat proxy ssl interception certificate

SSL Visibility supports several possible deployments with Blue Coat ProxySG running SGOS 6.7.1 or later.

General Requirements

To participate in SSL Offload, both SSL Visibility and ProxySG appliances must have valid licenses with birth certificates installed.

The ProxySG license should include the SSL feature. The ProxySG appliance must be running the SGOS 6.7.x release. The ProxySG appliance should be fully configured to process SSL traffic (SSL intercept rule set). The ProxySG appliance must be reachable at Layer2 from the SSL Visibility appliance.

A load balancer, or any other extra device, cannot be configured in the active loop with ProxySG appliances.

ProxySG Mode Deployment Topologies ProxySG mode supports several topologies, which are configurable after ProxySG Mode is enabled during SSL Visibility segment creation. Dual-Arm Proxy

The following two ProxySG mode options are dual-arm topologies, which are connected by a bridge or router. When these ProxySG-mode topologies are enabled without chaining, they are paired-port configurations; all traffic (including broadcast packets) is sent from each network port to the associated (paired) application port, and from each application port to the associated network port.

Active-inline Paired ProxySG Fail-to-Appliance

Active-inline Paired ProxySG Fail-to-Network

SSL Visibility supports multiple routed ProxySG devices that are connected using one or more switches in paired-port configuration to an SSL Visibility appliance. See Multi-Routed ProxySG Deployments for a configuration example.

Inline Bridged Deployment

In this example, network and application ports are paired. Traffic coming into each SSLV network port is sent to the associated application port.

Dual-Arm Proxy with Active Devices

When these ProxySG-mode topologies are enabled with chaining, all traffic is sent from the network port through the active device (A/B) to the ProxySG ports. All SSL traffic is inspected by the SSL Visibility appliance, as defined by the ruleset and Inspection Service configured for the segment. The following ProxySG mode options are enabled with devices in an active loop.

Active-inline Paired ProxySG Fail-to-Appliance Chained Appliance A

Active-inline Paired ProxySG Fail-to-Appliance Chained Appliance B

Active-inline Paired ProxySG Fail-to-Appliance Chained Appliance A/B

Active-inline Paired ProxySG Fail-to-Network Chained Appliance A

Active-inline Paired ProxySG Fail-to-Network Chained Appliance B

Active-inline Paired ProxySG Fail-to-Network Chained Appliance A/B One-Arm Proxy

The one-arm proxy option can be used in a virtually inline topology (such as WCCP) or physically inline (an explicit proxy).

Active-inline Multi-proxy Capable Fail-to-Appliance

In a one-arm proxy with a single proxy device attached and without chaining, the application port behaves as a paired port with the associated network port. If multiple proxy devices are attached, traffic is switched from the single network port to multiple application ports, based on the MAC of each attached proxy. Broadcast or multicast packets from the network port are sent to all application ports.

SSL traffic that is not destined for a proxy device is dropped. SSL traffic directed to a proxy device is inspected by the SSL Visibility appliance, as defined by the ruleset and Inspection Service configured for the segment.

Virtually Inline Deployment

In the example above, the SSL Visibility appliance is responsible for switching the traffic to the correct application port. ARP requests are periodically sent to resolve MAC addresses, and SSL Visibility maintains a proxy MAC to application port mapping table.

A load balancer, or any other extra device, must be configured as shown in the example, and not in the active loop with ProxySG appliances.

Out-of-Path Deployment

The following proxy mode option is a one-arm, network out-of-path topology. In this scenario, traffic is switched in both directions, from network ports to application ports and from application ports to network ports. Source MAC learning is employed on network ports. Traffic from application ports to network ports is switched based on the Layer2 switch table. If a MAC is not found, traffic is sent to both network ports. Broadcast and multicast traffic from one network port is sent to all application ports and to the second network port. Broadcast traffic from application ports is sent to both network ports.

SSL traffic that is not destined for a proxy device is cut through to the second network port. SSL traffic directed to a proxy device is inspected by the SSL Visibility appliance, as defined by the ruleset and Inspection Service configured for the segment.

Active-inline Multi-proxy Capable Fail-to-Network Out-of-Path with Active Devices Deployment

The following proxy mode options are one-arm, network out-of-path topology with devices in an active loop. The traffic is switched in both directions, from network ports to application ports and from application ports to network ports. This deployment option works exactly like an out-of-path deployment for all unicast, multicast, and broadcast traffic. SSL traffic not destined for a proxy device is sent to the second network port through the active devices. SSL traffic directed to a proxy device is inspected by the SSL Visibility appliance, as defined by the ruleset and Inspection Service configured for the segment. This inspected and decrypted traffic is sent to the proxy through the connected active devices.

Active-inline Multi-ProxySG Capable Fail-to-Network Chained Appliance A

Active-inline Multi-ProxySG Capable Fail-to-Network Chained Appliance B

Active-inline Multi-ProxySG Capable Fail-to-Network Chained Appliance A/B

After configuring any segment for ProxySG mode, you must add a ruleset (the ruleset will include an Inspect rule that points to an Inspection Service), and configure the Proxy Device IDs and IP Settings.