Follow

VSatellite Frequently Asked Questions

Information:

The purpose of this FAQ is to describe the purpose and functionality of a VSatellite service as it applies to the Venafi as a Service Control Plane. This article will showcase common questions about why a VSatellite is necessary and what functionality it provides. Security questions are not covered in this document.

Frequently Asked Questions:

What is a VSatellite?

A VSatellite is a customer hosted infrastructure component designed to provide certain functionality within the customers network such as private network discovery and integrations among other services. Although Venafi as a Service and its modules such as TLS Protect Cloud are cloud based services, it is generally undesirable to open inbound communications from the internet to internal secure networks. The VSatellite provides private services within a customer's network by making communications from the the customer network to Venafi as a Service, requiring only outbound communication and connectivity to managed endpoints. For more information, please refer to the VSatellite documentation here: https://docs.venafi.cloud/vsatellite/c-VSatellite-Management-about/. 

Top

What is the difference between a VSatellite and a VSatellite Worker?

A Vsatellite will function as a discovery engine and a feature hub within a customer's private network. One such feature is connectivity to private certificate authorities such as Microsoft Active Directory Certificate Services (ADCS). The VSatellite worker facilitates communication from a VSatellite to one or more ADCS hosts. As VSatellite is a Linux based machine it is unable to communicate natively via remote procedure calls (RPCs) which are required when remotely managing ADCS. To overcome this limitation, a VSatellite worker will be installed on an available Windows machine to host the VSatellite worker service. This service accepts command and control messages from a VSatellite and converts them into RPCs that can be understood by an ADCS host. In other words, its a VSatellite worker is a protocol converter gateway and is supplemental to a VSatellite.

Top

Why do I need a VSatellite?

A VSatellite performs many functions within the scope of Venafi as a Service. Broadly this includes discovery and validation, CA connectivity, provisioning and more. For discovery operations, a VSatellite is a central service that will scan target addresses (sockets) and return certificate information as well as perform validation checks against those certificates found. For CA connectivity, a VSatellite will be responsible for all private CA connections and those public CAs connected via ACME protocol. When pushing a new certificate to a target server, a VSatellite is the service performing that work. If you will scan only your public domain networks on the  standard TLS port (443), and not issuing certificates, a VSatellite may not be necessary. If you will be scanning your private network you will be best served by using a VSatellite. If you will be scanning your public network on ports other than 443 or any of those endpoints are white/black listed, you will need to use a VSatellite. If you want to schedule those network discovery scans you will need to use a VSatellite. If you will ne connecting to a CA with ACME or making use of the Automated Secure Keypair feature for private key generation and storage, you will need to use a VSatellite.

Top

What are the services hosted on a VSatellite?

A VSatellite hosts many features and the list will continue to grow over time as new functionality is added. As of this date of this article, VSatellite hosts these services:

  • Enhanced Discovery - this is discovery of private networks and possibly public networks if those public networks are black/white listed or running on non-standard ports. Enhanced discovery offers built in scheduling and certificate validation. Certificate validation means identifying the configuration status of the certificate such as incomplete certificate chains, hostname mismatches, and more. For more information on certificate validations, please see: https://docs.venafi.cloud/vaas/c-validating-certificates/.
  • Smart Discovery - this is a discovery feature targeting imported certificates where the names values  from the CN and SAN fields evaluated and a discovery process is attempted to determine installation location and validation status.
  • Automated Secure Keypair - this feature allows for private key creation and storage. Without this feature, users would need to create and secure their own private key and CSR external to TLS Protect Cloud's form based option (i.e. Certreq, OpenSSL) and submit them to TLS Protect Cloud. For more information, please see: https://docs.venafi.cloud/vaas/automated-secure-keypair/what-is-automated-secure-keypair/. 
  • ACME CA connectivity - TLS Protect Cloud has native communications provisions for several CAs such as Digicert, Entrust, and GLobalSign. Other CAs, such as LetsEncrypt or Sectigo (among many others) are instead serviced by ACME connectivity. ACME is a standard for automating certificate requests. When a CA is added to TLS Protect Cloud using an ACME interface, it is the VSatellite that facilitates this communication. For more information, please see: https://docs.venafi.cloud/vaas/certificates/ca/adding-acme-ca/.
  • Push Provisioning - TLS Protect Cloud provides three mechanisms for getting certificates to their endpoints: manual, pull and push provisioning. Manual means a users downloads and deploys a cert through external manual methods. Pull provisioning leverages an orchestration system such as Ansible or Terraform or Venafi's VCert will be used to pull a cert from inventory and deploy it on behalf of TLS Protect Cloud. Push provisioning utilizes the VSatellite to push the certificate to endpoints without additional infrastructure. For more information please see: https://docs.venafi.cloud/vaas/machines/provision-certificates/. 
  • Private CA connectivity - When connecting to a private CA, such as Microsoft's ADCS, the VSatellite along with a VSatellite worker (see above) are used to provide connectivity to and management of the private CA.

Top

What is the difference between VSatellite and Scanafi?

At first glance, VSatellite (enhanced discovery) and Scanafi (basic discovery) both provide discovery services for TLS certificates. The configuration pages both ask for the same information: IP/subnet/FQDN + ports to scan for certificates. But this is where the similarities end. Scanafi is a standalone ad-hoc utility while VSatellite is a scalable service with additional features such as validation, smart discovery, and scheduling capabilities. 

Scanafi represents the easiest and quickest way to get an internal scan of your network. A user will configure the scan in TLS Protect Cloud, then go to their workstation and run Scanafi from there. Scanafi is available for Windows, Linux, and Mac systems. To schedule Scanafi to run on a regular basis requires manual intervention and the creation of a scheduled task or cron job. Scanafi does not provide validation and does not automatically test if a target IP is also configured for an SNI/host-header name. 

VSatellite offers many features as noted above, but in this comparison, discovery is the only service we can compare. The discovery feature of a VSatellite will configure the scan in TLS Protect Cloud and define a running schedule from that same page. This means no additional manual steps are required and no scheduled tasks or cron jobs need be defined. VSatellite will also take the steps to see if IPs returned are configured with SNI/host-header configurations and will also provide validation. Finally, once running, a VSatellite will self update and attempt to heal itself should any problems be detected. 

Top

How do I obtain a VSatellite?

Venafi does not currently provide an image for a customer to download and deploy. Rather, a VSatellite is installed by an admin of TLS Protect Cloud on a customer supplied system (VMs are acceptable). Once the pre-requisites are met, the deployment can begin. For more information, please see: https://docs.venafi.cloud/vsatellite/t-VSatellite-deployNew/. 

What operating system will host a VSatellite and what are the requirements for it?

The pre-requisites for a VSatellite are defined here: https://docs.venafi.cloud/vsatellite/r-VSatellite-deployNew/. As of this writing, the following operating systems are supported for deployment of a VSatellite:

  • Ubuntu 18.04LTS and later
  • RHEL 7.9 and later

Other operating systems may work but will not be supported should any issues arise. Typically these scenarios (when not derivatives of the operating systems above) require the pre-installation of k3s and, the identification of the k3s config and all require the use of the "-dev" flag to bypass the OS check. Such a command would resemble: 

./vsatctl install --pairing-code xxxx --dev --vsat-kubeconfig <ABSOLUTE_PATH_TO_KUBE_CONFIG>

To perform the install, the basic requirements of the host system are:

  • Supported operating system. It is recommended to install the server version of the supported OS. There are no GUI requirements.
  • 10GB of available hard disk space on the root partition.
  • 4GB of RAM available to the OS, not just assigned to the VM.
  • 2 CPUs.
  • Virtual or physical systems may be used.
  • There are no virtual host requirements with respect to ESX, Hyper-V or others.

Top

Can I install a VSatellite into my own Kubernetes cluster?

At this time, installing to your own Kubernetes cluster is not supported. If you wish to test the service in your own Kubernetes cluster to test form compatibility and stability in your environment, the following command could be used:

./vsatctl install --pairing-code xxxx --dev --vsat-kubeconfig <ABSOLUTE_PATH_TO_KUBE_CONFIG>

Top

What are the network connectivity requirements for a VSatellite?

While no inbound communications are require for a VSatellite to function, it will have outbound and internal requirements.

Installation

During installation, your VSatellite host must have internet connectivity, there is no offline installation option. The basic installation command as seen in the installation pages does not include a "--venafi-registry" flag. as such it requires communication to Venafi on ports 443 and 9443 to several URLs as well as several open source projects. Alternatively, appending the "--venafi-registry" flag to the installation command will streamline the URL requirements. The --venafi-registry flag better secures and simplifies the installation of VSatellite by using only Venafi-hosted VSatellite artifacts.

Without the --venafi-registry flag:

  • Venafi as a Service endpoints:

    • dl.venafi.cloud:443
    • vsat-gw.venafi.cloud:9443
    • vsat-gw.venafi.cloud:443
    • vsat-login.venafi.cloud:443

With the --venafi-registry flag:

  • dl.venafi.cloud:443
  • registry.venafi.cloud:443
  • vsat-gw.venafi.cloud:9443
  • vsat-gw.venafi.cloud:443
  • vsat-login.venafi.cloud:443
  • rpm.rancher.io:443 (this applies ONLY when using RHEL on your target computer)

Discovery

For discovery, SSL/TLS services are typically thought of being on port 443 but there are several other service ports that may be in use in your network. Commonly observed services when defining your network scans are :

  • 443 - HTTPS
  • 25/485/587 - Secure SMTP
  • 636 - secure LDAP
  • 3389 - RDP
  • 5986 - WinRM with TLS
  • 8443/9443 - common alternative HTTPS

If you lack documentation on your network, a full range network scan can be performed (65,535 ports per IP), but beware this will take a very long time to complete. Once discovered, it would be recommended to fine tune your scans to target the known services and thus reduce network traffic and improve performance. 

VSatellite to VSatellite Worker and ADCS

If connecting to ADCS, you will make use of a VSatellite worker. The default port for VSatellite inbound communication defaults to port 8085 but can be changed during installation.

  • 8085 - Vsatellite to VSatellite worker, default port can be changed
  • 135 - RPC port mapper VSatellite worker to ADCS host
  • 49152-65535 - ephemeral ports, default, VSatellite worker to ADCS host

Push Provisioning

Push provisioning allows a VSatellite to deploy a certificate to a target system without extra components. The requirements vary based on the target device.

Windows (IIS, common key store)

  • 5985 - WinRM without TLS, default port can be changed
  • 5986 - WinRM with TLS, default port can be changed

F5 Big IP LTM

  • 443 - HTTPS, default port can be changed

Common KeyStore not on Windows (file placed in the file system)

  • 22 or others - SSH

VSatellite Management

  • 22 or others - SSH

VSatellite name lookup

  • 53 - DNS

Top

Should I be concerned about IDS or IPS systems when working with VSatellite?

The nature of network based discovery tends to trigger IDS and IPS systems; consider a single source scanning every IP on every port in your network. Generally speaking an exclusion should be created for network traffic emanating from the VSatellite(s) you have deployed to avoid a disruption to service. Clues that services have been disrupted include:

  • Unhealthy or Lost Connection VSatellite status (Settings | VSatellites)
  • Missing certificate installation data - installations fall off 10 days after having been discovered if no further discoveries have been or can be performed. 
  • Incomplete data - certificate you know and can verify are present where a scan is also configured to find them may not appear in inventory.
  • You are unable to download a previously generated private key.
  • You cannot request a new certificate when the request is made for the service to create the private key.
  • When you SSH into the box, you cannot ping or connect to anything else.

Top

How many VSatellites should I deploy?

At a minimum, 2 VSatellites are recommended. Specifically, VSatellites will automatically share their Data Encryption Key (DEK) with each other. This DEK is responsible for secure storage of the private key data. Loss of the DEK and the hosts that are using it will result in loss of access to existing private key data and the inability to create new private key data. 

Beyond concepts of high availability, the other primary considerations are network routability and WAN bandwidth/infrastructure. If some segments are not routable between each other, but do have internet access and should be scanned, you will want to deploy a VSatellite to each of those networks. WAN connectivity is of concern when bandwidth is limited and/or latency is high. While a VSatellite consumes very little traffic when idle, large network scans have the potential to saturate a WAN link. 

Be advised that it is easy to add more VSatellites later should they be needed. The advice is to start with a minimum number of hosts (2), add more based on the routability and bandwidth configurations and grow from there after a period of monitoring. 

Top

Was this article helpful?
0 out of 0 found this helpful

Comments