Terraform Enterprise displays x509: certificate is not valid for any names or x509: certificate is valid for (Replicated)

Introduction

Workspaces in Terraform Enterprise execute Terraform runs in ephemeral containers. During a run, the Terraform CLI communicates with the Terraform Enterprise API as part of its service discovery process.

By default, network traffic from the ephemeral run container routes to the load balancer and back to the Terraform Enterprise instance. The hairpin addressing feature, available since v202011-1, optimizes this by routing traffic directly to the private IP address of the Terraform Enterprise host, bypassing the load balancer.

This article addresses a certificate validation error that can occur when using hairpin addressing.

Problem

A Terraform run fails during backend initialization with an x509 certificate error. The error message indicates that the TLS certificate presented by Terraform Enterprise is not valid for the hostname specified in the configuration.

Two common variations of the error are:

Error: Failed to request discovery document: Get "https://tfe.example.com/.well-known/terraform.json": x509: certificate is not valid for any names, but wanted to match tfe.example.com

Error: Failed to request discovery document: Get "https://tfe.example.com/.well-known/terraform.json": x509: certificate is valid for tfe-test.example.com, not tfe.example.com

Prerequisites

• Terraform Enterprise v202011-1 or newer.
• The hairpin addressing feature is enabled.
• Terraform Enterprise is using a self-signed certificate generated by the Replicated management console.

Cause

The Replicated management console, which operates on port 8800, generates the self-signed TLS certificate used by both the console and the Terraform Enterprise application on port 443.

The x509 error occurs when the fully qualified domain name (FQDN) of the Terraform Enterprise instance is either missing from the certificate's Subject Alternative Name (SAN) field or does not match it. This mismatch can happen if the hostname was omitted or specified incorrectly during the initial installation or during a later update in the Replicated console settings.

Solutions

To resolve this issue, you must ensure the self-signed certificate includes the correct FQDN for your Terraform Enterprise instance. The solution depends on whether you are performing a new installation or updating an existing one.

Solution 1: Correct the Hostname During Installation

Ensure you provide the correct FQDN during the setup process.

• Manual Installation (Web UI) When prompted by the installation UI, enter the correct FQDN for Terraform Enterprise in the hostname field.

  

• Automated Installation In your /etc/replicated.conf bootstrap file, set the TlsBootstrapHostname property to the correct FQDN. This is required when TlsBootstrapType is set to self-signed.

  {
    "DaemonAuthenticationType": "password",
    "DaemonAuthenticationPassword": "your-password-here",
    "TlsBootstrapType": "self-signed",
    "TlsBootstrapHostname": "tfe.example.com",
    "BypassPreflightChecks": true,
    "ImportSettingsFrom": "/path/to/settings.json",
    "LicenseFileLocation": "/path/to/license.rli"
  }

Solution 2: Correct the Hostname Post-Installation

If Terraform Enterprise is already installed, update the hostname in the Replicated management console to regenerate the certificate.

1. Log in to the Replicated console at https://<TFE_FQDN>:8800.
2. Click the gear icon in the top-right corner and select Console Settings.

3. Update the Management Console Hostname field with the correct FQDN of your Terraform Enterprise application.

   

4. Scroll to the bottom of the page and click Save.
5. Restart the Terraform Enterprise application to apply the new certificate:
   1. Navigate to the Dashboard tab.
   2. Click Stop Now and wait for the application to stop completely.
   3. Click Start Now and wait for the application to restart.

Additional Information

• If you have configured Terraform Enterprise with an HTTP proxy, you must add the application's FQDN to the proxy bypass list. This ensures that traffic from the run container routes internally when hairpin addressing is enabled.
• For more details on enabling this feature, refer to the Hairpin Addressing documentation.