SSL Orchestrator Use Case: Inbound SNI Switching with version 9.1
Introduction SSLO will generate a single set of SSL profiles for use in a topology. It may be useful, especially in an inbound gateway mode, to process traffic to multiple sites, requiring different server certificates. The use case is to employ native BIG-IP SNI switching in SSLO, such that an SSLO topology can select a correct client SSL profile and server certificate based on the incoming SNI. In this example we have a single web server with multiple IP addresses hosting different web site domains: en.appserverone.com resides on 10.1.10.90 en.appservertwo.com resides on 10.1.10.91 When an external client requests https://en.appserverone.com we want the SSL Orchestrator to use a specific keypair for the sessions and direct the traffic to 10.1.10.90.When an external client requests https://en.appservertwo.com we want the SSL Orchestrator to use a different keypair for the sessions and direct the traffic to 10.1.10.91. Configuration Steps Import Private Keys and Certificates Create Client SSL Profiles Create New SSL Configurations Add the Client SSL Profiles to the Interception Rule Import the Private Key and Certificate for the different web site domains From the BIG-IP Configuration Utility go to SSL Orchestrator > Certificates Management > Certificates and Keys. Click Import on the right. For the Import Type select Key. Give it a name, en.appserverone.com in this example.For the Key Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Click on the Key Name created in the previous step. Click Import. For the Certificate Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create a Client SSL Profile for each certificate/key pair From the BIG-IP Configuration Utility go to SSL Orchestrator > Components > Profiles > Client SSL. Click Create on the right. Give it a name, en.appserverone.com in this example.Select the Custom box on the far right then click Add for the Certificate Key Chain. Select the Certificate and Key created previously and click Add.A Passphrase and Chain can be specified if needed.Click Add when done. Select the Advanced option next to Configuration. Scroll down and find the Server Name field.Enter the FQDN that external clients will request, en.appserverone.com in this example. Note: when an external client requests https://en.appserverone.com their TLS Client Hello will contain an extension value for ‘server_name’ field with a value of ‘en.appserverone.com’.We’re instructing SSL Orchestrator to use this Client SSL Profile when it receives this type of request from a client. Scroll to the bottom and click Finished when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create New SSL Configurations In this example an Incoming L3 Topology already exists.From the Configuration Utility select SSL Orchestrator > Configuration > SSL Configurations. Click Add Give it a name, appserverone in this example.Deselect the check boxes for Forward Proxy and Default SNI. For the SNI Server Name enter the FQDN, en.appserverone.com in this example For Client-side SSL select the pencil icon to edit the Certificate Key Chains. Use the Drop Down menu to choose the correct Certificate and Key, en.appserverone.com in this example. Click Done Click Save & Next at the bottom. Click Deploy Click OK to the Success message Repeat this step as needed.In this example another SSL Configuration is added for en.appservertwo.com. Add the Client SSL Profiles to the Interception Rule From the Configuration Utility select SSL Orchestrator > Configuration > Interceptions Rules. sslo_L3_inbound. Select the correct rule, sslo_L3_inbound in this example. Click the pencil icon to edit the rule. Scroll down to the Server SSL Profiles.Select the Server SSL Profiles created previously and click the arrow to move them from Available to Selected. At the bottom click Save & Next. Click Deploy Click OK to the Success message Summary Congratulations! The configuration is now complete
Use switch for multiple conditions
Problem this snippet solves: You need to make load balancing or whatever else decision based on multiple context information like HTTP host header, URI, Referer header, cookie value, etc. How to use this snippet: This code allow to use a single switch command to manage multiple conditions instead of several nested if or switch conditions. Normal condition : switch -glob [HTTP::host] { "www.example.net" { if { [HTTP::header "Referer"] contains "host.example.net" } { # do action 1 } else { # do action 2 } } "www.example.com" { switch -glob [HTTP::header Referer] { "*host.example.com" { if { [HTTP::method] eq "GET" } { # do action 3 } } default { # do action 4 } } } } `</pre> Using the process described in this codeshare article : <pre>`switch -glob "[HTTP::host]|[HTTP::header Referer]|[HTTP::method]" { "www.example.net|*host.example.net*|*" { # do action 1 } "www.example.net|*" { # do action 2 } "www.example.com|*host.example.com*|GET" { # do action 3 } "www.example.com|*" { # do action 4 } } Code : when HTTP_REQUEST { switch -glob "[HTTP::host]|[HTTP::header 'Referer']|[HTTP::uri]" { "*|*REFERERPART*|*" - "*|*|*URIPART*" - "*HOSTPART*|*|*" { # do some action } "host.example.com|*www.example.net*|*" { # do some action } default { # do some action } } } Tested this on version: 11.3
