cancel
Showing results for 
Search instead for 
Did you mean: 

Introducing the Services Director Communications Channel

Introduction

Services Director 19.1 introduced a new communications channel to connect to Traffic Managers (vTM). This lets Services Director access the REST API of vTM via a secure authenticated link that is established by the vTM rather than the Services Director. This allows Services Director to manage vTMs deployed into networks that are not addressable by Services Director (e.g. networks behind NATs or firewalls).

 

This new secure communications channel is useful in a range of use cases – not just in NAT/firewall scenarios. However, the new mutually authenticated link introduces complexity when updating Services Director's server certificate. This document describes the Communications Channel, and shows how to update the certificates manually, using the GUI.

 

It is also possible to use a script to update the certificates - for information on this, see Automating Certificate Updates for the Services Director Communications Channel.

The Communication Channel mechanism

Configuration for the vTM/Services Director communication channel ("comms channel") is initially set up during the self-registration process that enrols a vTM into the Services Director's estate. This process requires the vTM to have been seeded with the Services Director's server certificate in order to authenticate it when connecting; the vTM establishes its own unique client key/certificate pair, and provides the client certificate to Services Director when making the self-registration request. Thus, given the sharing of client and server certificates, both parties have a means of authenticating future communications channel based links.

cm-sd-comms-channel.png



Updating the Services Director certificate

All comms channel links are mutually authenticated using the certificates as described above; the vTM will attempt to keep a connection to the Services Director alive constantly, reconnecting (and re-authenticating) if the link is lost or dropped. This is needs to be done carefully to ensure continued communication.

 

Previously, before the introduction of the new comms channel capability, the Services Director server certificate held by vTM was used during the self-registration process only, with the result that the server certificate in use by Services Director could be updated without any implications for vTMs already in the estate. Now, for vTMs using the comms channel, updating Services Director to use a new server certificate can cause problems; as the vTMs still hold the old server certificate, when they attempt to reconnect the comms channel, the vTM will not be able to authenticate the Services Director, and the establishment of the comms channel will fail. While this failure does not affect Universal FLA licensing, Services Director will be unable to perform monitoring, metering, backup/restore operations or any other activity requiring the vTM's REST API. (NB. Although legacy FLA licenses do not use the comms channel, they do authenticate the Services Director using its server certificate, so would also be affected by an update).

 

The way to avoid this problem is to "prime" the vTM with the new server certificate so it can reconnect once the Services Director's server certificate is updated. The next section  shows how to update the certificates manually, using the GUI.

It is also possible to use a script to update the certificates - for information on this, see Automating Certificate Updates for the Services Director Communications Channel.

Manual update

For very small estates, where the administrator has direct access to the GUI of each managed vTM, and the risks of a short break in communications between Services Director and the vTM are small, it is possible to update the certificates manually.

 

The break in communication caused by a manual update will cause Services Director features such as monitoring, metering and vTM backups to fail for the affected vTMs (but not vTM licensing).

 

This is because Services Director will be unable to access the vTMs REST API, and resulting failures in metering, vTM backups, and monitoring. If the "Auto Cleanup vTMs" feature is enabled, a monitoring failure would result in deletion of the vTM from the Services Director's estate. As noted above, vTM instances using the Universal FLA will continue to be licensed, unaffected by a change in the server certificate, while vTM instances using legacy FLAs will be impacted by this change; legacy FLA customers planning to update their server certificate must obtain an updated legacy FLA.

Setting the new server certificate

In this case, the user can update the Services Director's server certificate. In the Services Director's GUI, select System> Service SSL Certificate, then click the link to update the certificate (see below):

cm-sd-cert-1.png



For all vTM instances using a comms channel link to this Services Director, this will cause a comms channel disconnection; the vTMs in question will start reporting connection errors, and repeatedly do so until their certificates have been updated:

cm-sd-cert-2.png



Given access to their GUIs, each vTM instance can be updated easily to use the new server certificate. Under System> Licenses> Services Director Registration, paste the new Services Director server certificate into the box for remote_licensing!server_certificate, and press the "Save and register" button. Once this is done, the vTM event log should show a new "Self registration successful" message, and no further "SD Communications Channel Aborted" should appear (see below).

cm-sd-cert-3.png



This procedure should be repeated for each vTM in the estate.


Version history
Revision #:
3 of 3
Last update:
‎08-05-2019 04:56:AM
Updated by:
 
Contributors