Skip to content

Set up Microsoft AD CS for issuing and importing certificates

The steps below will take you through everything you need to do to get your AD CS service integrated with TLS Protect Cloud. After completing these steps, you'll be able to import existing certificates and issue new certificates.

Before you begin

Have the following ready before you start:

  • Linux server to run VSatellite. See Pre-requisites for installing VSatellites for a list of system and network requirements.
  • Windows server to run VSatellite Worker. The server must meet the following minimum requirements:
    • Separate server from the server running AD CS
    • Windows Server 2019
    • Microsoft .NET Framework 4.7.0 or higher
    • Access to ports 135 and 49152 - 65535 on AD CS Service
    • VSatellite connectivity to the VSatellite Worker - port 8085 (default) or the custom port specified during VSatellite Worker installation
    • 4 GB RAM
    • 2 CPUs
    • 300 MB free disk space (before Worker install)
  • Completed AD CS configuration
  • IP or hostname of your Microsoft AD CS server
  • Username and password used to authenticate to Microsoft AD CS
  • Microsoft AD CS Issuing Certificate Common Name

Step 1: Connect your AD CS server to TLS Protect Cloud

First, we'll set up the connection between your Microsoft AD CS server and TLS Protect Cloud. If you don't already have a VSatellite or VSatellite Worker, these steps will walk you through those installations. If you do, then you can just select them during setup.

  1. Sign in to TLS Protect Cloud.
  2. Click Integrations > Certificate Authorities.
  3. Click New > Microsoft AD CS.
  4. Enter a Name for the Certificate Authority.

    Tip

    This is the name that will be used throughout TLS Protect Cloud for this CA.

  5. From the VSatellite Worker drop-down, select the VSatellite Worker to use in this configuration.

    If you don't have a VSatellite Worker yet, click the box below for instructions on setting one up.

    Don't have a VSatellite Worker yet? Follow these steps to set one up.

    Important

    The VSatellite Worker must not be installed on the same server running AD CS.

    1. Click Deploy VSatellite Worker.

      If you're installing the VSatellite Worker on a Windows server that has internet access, refer to "Online Installation" below. If the Server does not have internet access, refer to "Offline Installation" below.

      Online Installation

      1. Copy the VSatellite Worker installation command, and then run the script in a PowerShell prompt on the Windows server where you're setting up your VSatellite Worker.

      2. To use a port other than the default port 8085, replace the port number following the --port flag before running the installation command.

      Offline Installation

      1. Copy the VSatellite Worker download command, and run it in a PowerShell prompt from a machine with internet connectivity.

        This downloads the VSatellite Worker installer (VSatelliteWorkerInstaller.msi) and VSatellite Worker (vsatworkectl.exe).

      2. Move both files to the same directory on the Windows server you want to install VSatellite Worker on.

      3. After moving the files, copy the VSatellite Worker installation command, and then run the script in a PowerShell prompt on the Windows server you're setting up as your VSatellite Worker.

      To use a port other than the default port 8085, replace the port number following the --port flag before running the installation command.

    2. Follow the on-screen prompts to complete the installation.

    3. Check if the VSatellite Worker service is running on the Windows server by going to the Start menu and typing Services. From there, open the Services app, and in the Name column, look for VSatWorkerService.
    4. After the VSatellite Worker is up and running, return to the TLS Protect Cloud screen, and click Continue.
    5. In the VSatellite Worker server address, enter the FQDN or IP address of the Windows server where you installed the VSatellite Worker. Include the port number. The default port is 8085, but if you set a different port during installation, enter that port instead.
    6. Click Set.
    7. To complete the setup, the VSatellite Worker needs to be paired with a VSatellite. If you already have a VSatellite in place, you can select it from the VSatellite drop-down.

      If you need to set up a VSatellite, see the section below.

    Do you also need to set up a VSatellite? Follow these steps

    A VSatellite Worker needs to be paired with a VSatellite in order to communicate with TLS Protect Cloud.

    1. Click Deploy VSatellite. The Deploy a VSatellite page opens.
    2. From the VSatellite deployment script, click Copy Code to copy the entire command.
    3. Run the command on the Linux server you've set up to be your VSatellite. Follow the on-screen instructions to complete the installation.

      Note

      The installation may take up to 10 minutes.

    4. After installation, return to the Deploy a VSatellite screen in TLS Protect Cloud, and click Test Connection.

      Note

      Activating the VSatellite takes a few seconds. If Test Connection fails initially, click the button again to re-test the connection until it succeeds, and the Done button at the bottom of the screen is enabled.

    5. Click Done. You are returned to the Deploy VSatellite Worker page.

    6. The VSatellite drop-down should now show the VSatellite you just deployed. Click Pair to connect the VSatellite Worker to the VSatellite.
    7. Click Done. You are returned to the Connection page, and the VSatellite Worker drop-down is populated with the VSatellite Worker you just set up.
  6. Click Next.

Step 2: Enter your AD CS information

Next, we'll enter your Microsoft AD CS server information and credentials so that TLS Protect Cloud can authenticate to your AD CS server.

  1. In the AD CS administrative address field, enter the IP address or hostname of your Microsoft AD CS server.

  2. In the Common Name (CN) of the CA's certificate box, enter the Common Name of the Microsoft AD CS Issuing (root) Certificate.

  3. Enter the Username and Password to authenticate with Microsoft AD CS.

    AD CS Permissions

    The account you use must have Read, Issue and Manage Certificates, and Request Certificates permissions to the Microsoft AD CS server.

  4. Click Test credentials.

Step 3: Select AD CS issuance templates to map to TLS Protect Cloud

Now that the connection is made, we can set up certificate issuance through TLS Protect Cloud. This step is required only if you want to issue new TLS server authentication certificates through TLS Protect Cloud. If you just want to import existing certificates, see the import existing certificates steps below.

  1. Click in the Issuance templates field. After clicking in the field, TLS Protect Cloud queries your AD CS and returns a list of issuance templates from your AD CS server.

  2. Select the AD CS issuance templates that you want to map to TLS Protect Cloud.

  3. Click Add.

    TLS Protect Cloud tests all the templates you selected. Templates with a Passed result are available to map to Certificate Issuing Templates in TLS Protect Cloud. Those with a Failed result are not.

    Why did some templates fail?

    After adding templates, TLS Protect Cloud issues test certificates using each of the AD CS issuance templates. TLS Protect Cloud supports issuance through templates that:

    • Have Server Authentication set in the Application Policies setting of the Extensions tab on the issuance template
    • Allow issuing certificates using RSA keys
    • Supply the Subject Name in the request (can’t issue certificates with SN build from the AD)

    Issuance templates that are incapable of issuing such certificates fail the TLS Protect Cloud issuance test. This is expected. Some of the predefined (default) Issuance templates that will fail are:

    • DirectoryEmailReplication
    • DomainController
    • DomainControllerAuthentication
    • KerberosAuthentication

    Only the certificates that pass the test will be available when mapping AD CS templates to TLS Protect Cloud templates.

    However, issuance tests use a static 2048-bit CSR, and are expected to fail for AD CS templates that require larger key sizes. You will still be able to save the CA account settings, and issue certificates with ADCS templates with larger key sizes.

  4. Click Next.

On the Statistics tab of your Microsoft AD CS certificate authority, you see a summary of your certificates. Click on any number to open a pre-filtered Certificate Inventory page to see those certificates.

What's Next?

Now that your AD CS templates are mapped to TLS Protect Cloud, you can create a Certificate Issuing Template and associate your AD CS templates with TLS Protect Cloud issuing templates.

Select Microsoft from the New Certificate Issuing template screen. The AD CS templates that passed validation will show up in the Product Option drop-down.

Step 4: Import existing certificates from AD CS

This step is required only if you want to import existing certificates from AD CS.

  1. Click in the Import templates box. After clicking in the box, TLS Protect Cloud queries your AD CS and returns a list of templates from your AD CS server.

  2. Select the AD CS templates that you want to import certificates from. Only certificates issued by the templates you select will be imported.

  3. Click Add.

  4. If you want to schedule the import to occur on a regular basis, click the AD CS Import slider, and then set the import interval. This option is available only if one or more AD CS templates were added in the previous steps.

  5. Under Import options, select whether you want to import revoked or expired certificates.

  6. Click Done.

TLS Protect Cloud imports the certificates.

On the Statistics tab of your Microsoft AD CS certificate authority, you see a summary of your certificates. Click on any number to open a pre-filtered Certificate Inventory page to see those certificates.

Troubleshooting

If you run into trouble getting the AD CS integration set up, contact Venafi Support.