Deploy and configure the Windows servers

Here are the high level steps to deploy and configure each Windows server that will become a Venafi server.

  1. Review the hardware and operating system requirements for the Windows servers.

    Hardware Requirements
    Feature Requirement

    Processor

    4 processing cores

    Memory

    16 GB RAM

    Disk Space (for the Trust Protection Platform application)

    5 GB

    The Trust Protection Platform application can be installed on a secondary partition.
    Software Requirements
    Feature Requirement

    Operating Systems
    • Microsoft Windows Server 2022 (server with user interface) is supported.

    • Microsoft Windows Server 2019 (server with user interface) is supported.

    • Microsoft Windows Server 2016 (server with user interface) is supported (and recommended for new installations).

    • Microsoft Windows 2012 Server R2 (server with user interface) is supported.

    Trust Protection Platform only supports English Language Installation Media from Microsoft. While it does support region setting configurations to ensure that date and times appear correctly, the Windows servers on which you install Trust Protection Platform must be derived from Windows English installation media.

  2. Where applicable, join your Windows server to your Active Directory domain.

    While a connection to Active Directory is not required for base functionality, it is required to use certain features such as Windows integrated authentication.

    Windows integrated authentication is supported in two ways in Trust Protection Platform:

    • Authentication to the database from the Venafi servers.
    • User authentication to the web interface for single sign-on (SSO).

  3. Enable web services, if needed.

    For each Windows server, decide if it is going to be supporting inbound web services or not. If the server will support web services, then the required windows server role and corresponding components are followed as outlined in the System Requirements guide.

    IIS can start its default web site before the Venafi site on the server, preventing the Venafi site from starting. You should remove the default web site.

    Some examples of web services are the Web Console, Web SDK, supporting connectivity from our agents, as well as some certificate protocols like ACME or SCEP. However, if you are deploying a Venafi server to a segmented network to discovery, validate, and install certificates and ssh keys, plan on leveraging partitioning to ensure that a particular Venafi server communicates with the internet or various network segments, then it is possible to configure those Venafi servers with no web services. In those cases, the IIS role does not need to be installed.

  4. Apply correct permissions for domain service accounts if leveraging Windows integrated authentication.

    For Windows Servers joined to the domain, you are likely to leverage Windows Integrated Authentication to authenticate to the Venafi database on your Microsoft SQL Server. You will need two domain services accounts and they need to be given the correct permissions on each Windows Server.

    If you haven't done so yet, create the accounts. Then apply the correct permissions in AD. For specific permissions details, see Windows permissions for database service accounts.

  5. If your industry requires, enable FIPS on your Windows server.

    Venafi Trust Protection Platform support Windows servers with Federal Information Processing Standard (FIPS) enabled.

    FIPS Resources

    IMPORTANT  Because FIPS is not supported for ACMEv2, you cannot have FIPS enabled on any server that is used for ACMEv2.

    How to Enable FIPS on Windows Servers

    1. On each server, open the Local Group Policy Editor by opening the gpedit.msc snap-in.
    2. In the snap-in navigate to Local Group Policy Editor > Computer Configuration > Windows Setting > Security Settings > Local Policies > Security Options.
    3. Find the policy System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.
    4. Change the option from Disabled to Enabled.

  6. Verify prerequisite software and components are installed.

    Venafi Professional Services maintains a script you can run on your Venafi servers to verify the appropriate prerequisites have been met for the server, and optionally install and configure any missing components. The accompanying README.txt file provides detailed information about using the script. The script and documentation are available on Venafi's Downloads site.

    If you choose not to run the script, we strongly recommend you look at the Third Party folder contained the Venafi Trust Protection Platformzip for helpful links for finding required common components that must be installed. The URL Rewrite Module only needs to be installed on Venafi servers configured for inbound web services. (See step 3, above.)

    Trust Protection Platform is a native 64-bit application. When integrating with HSMs to (1) encrypt private keys, credentials, and other secrets stored in the Venafi database, or (2) for the central generation or storage of private keys, you must install the 64-bit version of the HSM vendor's client software on each Venafi server in your deployment. These settings must be configured identically on all Venafi servers in the deployment. During installation of the Trust Protection Platform software, you will need to provide details on the HSM vendor client library.

    For example:

    Trust Protection Platform requires access to the 64-bit version of Cryptoki DLL.

    For SafeNet Luna SA devices, this is the path to the cryptoki.dll file.

    For Entrust nShield Connect HSM devices, this is the path to the cknfast.dll file.

    After selecting the DLL, click Load Slots. Trust Protection Platform will query the HSM and return the available slots.

    IMPORTANT  Trust Protection Platform requires the path to the DLL file to initialize the connection to the HSM device. This path will be used for all Trust Protection Platform servers in the cluster (connected to the same database). All servers in the cluster must have their DLL file in the same location.