Use of SSL Cryptographic Devices

The Traffic Manager software variant supports SSL hardware based on the RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), such as the Thales e-Security nShield Connect.

All Traffic Manager variants support the Microsoft Azure Key Vault service. Azure Key Vault is offered as a cloud based alternative to traditional hardware security modules. For Azure Key Vaults, observe the following conditions:

•The Traffic Manager supports using keys that are created by the Traffic Manager itself, or valid existing RSA keys migrated into the Azure Key Vault.

•The Traffic Manager supports "RSA-HSM" type keys. These keys are stored on secure hardware at the Azure Key Vault service.

•To create and use RSA-HSM keys, you must use a "Premium" service tier Azure Key Vault. For information and pricing for the available service tiers, see http://azure.microsoft.com/.

•In common with other secure hardware support, the Traffic Manager can use keys stored in an Azure Key Vault for SSL decryption (virtual servers) or SSL encryption (pools). The Traffic Manager cannot use stored keys for other purposes such as SSH or DNSSEC.

•If the Traffic Manager is configured to use FIPS mode (see FIPS Validation in the Traffic Manager), communications with the Azure Key Vault REST API operate in FIPS mode as well.

•To use the Azure Key Vault, the Traffic Manager's DNS must be able to resolve the hostnames of both the Azure Key Vault server and Microsoft’s login server. The Traffic Manager must also be able to establish outgoing TCP connections on port 443. If your Traffic Manager system is firewall restricted, you must ensure your firewall is configured to allow this communication channel.

For instructions on setting up and managing an Azure Key Vault, see http://azure.microsoft.com/en-us/documentation/services/key-vault/.

Using an HSM device or Azure Key Vault service offloads SSL computation (the RSA private key decryption) from the Traffic Manager system’s CPU onto the SSL cryptographic device to which you connect. Some PKCS#11 devices also provide hardware key management, so that the private key is stored securely on the hardware device and cannot be accessed directly without the correct authentication.

As RSA cryptographic operations being performed on an SSL cryptographic device or service are outside of the Traffic Manager FIPS 140-2 Cryptographic Boundary, you should independently ensure that your cryptographic device or service is sufficiently conformant to FIPS 140-2 for your requirements.

Some Traffic Manager variants, such as the virtual appliance, display a limited set of the following options based on the hardware and services supported for these variants.

Use of SSL devices might not improve the overall performance of your Traffic Manager system. Although such devices offload the RSA calculation from the main CPU cores, the overhead in communicating with the device is not negligible. The Traffic Manager is able to perform many thousands or tens-of-thousands of SSL calculations on general purposes CPUs. The primary benefit of many SSL devices is their ability to store the private key securely.

Configuring the Traffic Manager to Use an SSL Device

To configure the Traffic Manager to use an SSL device or service, click System > Global settings and then click SSL Hardware Support. Select the desired SSL device in ssld!library.

The following table describes the settings available:

Setting	Description
ssld!library	Set to "Microsoft Azure Key Vault" to instruct the Traffic Manager to use an Azure Key Vault service. To connect to an Azure Key Vault, click "Connect to Microsoft Azure Key Vault". Set to "PKCS#11" to instruct the Traffic Manager to use generic PKCS compliant hardware such as the Thales e-Security nShield Connect. Additional settings for PKCS#11 are: ssld!driver!pkcs11_lib: The system location that the Traffic Manager should search for the PKCS#11 interface library. Leave this field blank for the Traffic Manager to search standard system locations instead. ssld!driver!pkcs11_user_pin: The PIN required to create a user session on the SSL hardware. ssld!driver!pkcs11_slot_type: The form of security token the Traffic Manager uses to protect the SSL private key: Operator Card Set: A physical smart card set with a suitable card reader plugged into the Traffic Manager. The smart card might require an optional user PIN. Soft Card: A file on disk that performs the same operation as a physical smart card arrangement. The file requires a user PIN. Module Protected: The cryptographic module alone protects the key, with no smart card or user PIN. ssld!driver!pkcs11_slot_desc: (token types "Operator Card Set" and "Soft Card" only) Use this setting to provide the identifying label or name for the card you are using.
ssld!accel	Whether to use the SSL device defined on this page for all decryption operations. Set to "Yes" to force the Traffic Manager to use the SSL device for all operations. Set to "No" to mean the Traffic Manager only uses the SSL hardware when the private key is stored securely on it.
ssld!failure_count	The consecutive number of attempts that the Traffic Manager can make before assuming the session is invalid and trying to log in again (due to reboot, power failure, and so on).

Verifying Correct Operation of SSL Devices

The Diagnose page displays the results of checks that the Traffic Manager can communicate with the SSL device. Any errors or warnings are indicated.

If you have configured the Traffic Manager to use an SSL device that supports hardware key management, you can then:

•Create new private keys (and corresponding public certificates) on the device using the Traffic Manager. Follow the procedure referred to in Creating a New Self-Signed SSL Certificate to create a new self-signed Server or Client SSL certificate, making sure to select the Create private key on hardware option that is present when a key-management device is configured.

•Manually install private keys and public certificates from the hardware on the Traffic Manager. Follow the instructions for your hardware device to extract an encoded version of the private key and the public certificate. Then install them on the Traffic Manager using the Import Certificate tool in the relevant SSL Server Certificates and SSL Client Certificates catalog.

•Migrate existing private keys from the Traffic Manager onto a newly connected SSL device. To move the key, use the "Migrate certificate to Hardware Security Module" section on the relevant certificate edit page.

ATTENTION
If an attacker has already obtained a copy of your private key, migrating it to an SSL device from the Traffic Manager does not constitute a guarantee that it is now protected. For the highest security, Ivanti recommends using keys generated on the SSL device itself.

The Traffic Manager verifies that it can access and use any hardware-managed keys, and indicates an error on the System > Diagnose page and the Event Log if any problems occur.

Although client certificates and corresponding private keys might be marked as unavailable on the Diagnose page and in the Event Log, the pool using them cannot be marked as having any problems because the Traffic Manager never knows what client certificate will be asked for until it connects to a back-end SSL node that requires one.

Using the Connect to Microsoft Azure Key Vault Wizard

To connect to an Azure Key Vault, click the Connect to Microsoft Azure Key Vault wizard link at System > Global Settings > SSL Hardware Support.

However, before you activate the wizard, first obtain the following information:

•Azure Key Vault URL: The URL of your designated Azure Key Vault. For example, "https://dev.vault.azure.net".

•Client ID: The Identifier (ID) of your user account in the Azure Key Vault.

•Client Secret: An alpha-numeric string representing the password of your user account.

•A trusted Certificate Authority: (Optional) To protect your connections to the Azure Key Vault from "man-in-the-middle" attacks, you can instruct the Traffic Manager to validate the identity of the SSL certificate used by the Azure Key Vault REST API. Obtain the trusted Certificate Authority that signed Microsoft’s SSL certificates and store it in the Traffic Manager CA catalog prior to running the wizard.

For help obtaining this information, contact your support provider or see the Microsoft Azure Key Vault documentation at: http://azure.microsoft.com/en-us/documentation/services/key-vault/.

In common with other Traffic Manager wizards, the "Connect to Microsoft Azure Key Vault" wizard runs through a number of steps, each one providing a Back and Next button to navigate between them:

1.Introduction.

2.Enter the URL of your Azure Key Vault:

3.Enter your client credentials:

4.Select “Yes” to instruct the Traffic Manager to verify the SSL certificate of the Azure Key Vault REST API, or select “No” to disable verification:

5.Click Finish to connect to the Azure Key Vault using the settings shown.

If the Traffic Manager is successful, the SSL Hardware Support section updates to indicate the active Azure Key Vault connection.

Click Edit to rerun the wizard with alternative settings, or click Remove to disconnect the Traffic Manager from the active Azure Key Vault.

Connection failures, warnings, and errors relating to Azure Key Vault are reported on the Diagnose page and in the Event Log.

Identifying Keys and Certificates Stored on a Secure Device

After you have successfully connected to secure hardware or an Azure Key Vault, you can use the key and certificate files from the device as you would any other key pair (including editing the certificate). Provided the device is operating normally, the Traffic Manager delegates all cryptographic operations that require the private key to the device. In the Admin UI, the Traffic Manager identifies keys as being stored on secure hardware, or in the Azure Key Vault, as shown: