fastly_tls_activation silently removes mutual_authentication if it is configured elsewhere

[landrew57]

Terraform Version

# Copy-paste output from `terraform -v`
$ terraform -v
Terraform v1.8.5
on darwin_arm64
+ provider registry.terraform.io/fastly/fastly v5.10.0
+ provider registry.terraform.io/hashicorp/tls v4.0.5

Affected Fastly Terraform Resource(s)

Please list the affected resources, for example:

• fastly_tls_activation when the certificate_id is changed and mutual_authentication_id is set.

Terraform Configuration Files

This assumes that there is a service in the Fastly account with the domain test.example.com configured. You will need to update all instances of test.example.com to an active domain on a service on your account to test this properly.

The activation should be updated by uncommenting the line that sets the certificate_id to the old or new certificate.

terraform {
  required_providers {
    fastly = {
      source  = "fastly/fastly"
      version = "5.10.0"
    }
    tls = {
      source = "hashicorp/tls"
      version = "4.0.5"
    }
  }
}

provider "tls" {
}

provider "fastly" {
}

### Certificate Setup Start

resource "tls_private_key" "key" {
  algorithm = "RSA"
}

resource "tls_self_signed_cert" "old" {
  private_key_pem = tls_private_key.key.private_key_pem

  subject {
    common_name = "test.example.com"
  }

  is_ca_certificate     = true
  validity_period_hours = 360

  allowed_uses = [
    "server_auth",
  ]

  dns_names = ["test.example.com"]
}

resource "tls_self_signed_cert" "new" {
  private_key_pem = tls_private_key.key.private_key_pem

  subject {
    common_name = "test.example.com"
  }

  is_ca_certificate     = true
  validity_period_hours = 360

  allowed_uses = [
    "server_auth",
  ]

  dns_names = ["test.example.com"]
}

resource "tls_self_signed_cert" "issuing" {
  private_key_pem = tls_private_key.key.private_key_pem

  subject {
    common_name = "issuing.test.example.com"
  }

  is_ca_certificate     = true
  validity_period_hours = 360

  allowed_uses = [
    "cert_signing",
    "server_auth",
  ]

  dns_names = ["issuing.test.example.com"]
}

### Certificate Setup End

### Fastly TLS configuration staet

resource "fastly_tls_private_key" "key" {
  key_pem = tls_private_key.key.private_key_pem
  name    = "example_example"
}

resource "fastly_tls_certificate" "old" {
  certificate_body = tls_self_signed_cert.old.cert_pem
  name             = "test.example.com_old"
  depends_on = [fastly_tls_private_key.key]
}

resource "fastly_tls_certificate" "new" {
  certificate_body = tls_self_signed_cert.new.cert_pem
  name             = "test.example.com_new"
  depends_on = [fastly_tls_private_key.key]
}

resource "fastly_tls_activation" "this" {
  certificate_id = fastly_tls_certificate.old.id
  # Uncomment the line below and comment the line above to change which certificate is active for that domain
  # certificate_id = fastly_tls_certificate.new.id
  domain         = "test.example.com"
}

resource "fastly_tls_mutual_authentication" "this" {
  cert_bundle    = tls_self_signed_cert.issuing.cert_pem
  name           = "test_example_cert_bundle"
  enforced       = false
  include        = "tls_activations"
  activation_ids = [fastly_tls_activation.this.id]
}

### Fastly TLS configuration end

Expected behaviour

certificate_id is updated when the fastly_tls_activation resource is modified

Actual Behavior

The certificate_id is left the same and the mutual_authentication_id is removed from the cert.

A curl to see the configuration after the first execution of terraform

$ curl  "https://api.fastly.com/tls/activations?R0tJdV7W9NbhUlaoikZqe1" -H "Fastly-Key: $(fastly profile token -q)" | jq '.data[] | {cert_id: .relationships.tls_certificate, mTLS: .relationships.mutual_authentication}'
{
  "cert_id": {
    "data": {
      "id": "6zNakjJJIMjuKZxRIflD14",
      "type": "tls_certificate"
    }
  },
  "mTLS": {
    "data": {
      "id": "ZROVxG8efsMGv1s9sTCR15",
      "type": "mutual_authentication"
    }
  }
}

The output of terraform plan after changing the certificate_id to use new rather than old.

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # fastly_tls_activation.this will be updated in-place
  ~ resource "fastly_tls_activation" "this" {
      ~ certificate_id   = "6zNakjJJIMjuKZxRIflD14" -> "Lz8HkbAqRq9CkvAURh1VJ0"
        id               = "R0tJdV7W9NbhUlaoikZqe1"
        # (3 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

A curl showing the configuration after that change was applied. Note the certificate_id is the same and the mutual_authentication_id has been removed.

$ curl  "https://api.fastly.com/tls/activations?R0tJdV7W9NbhUlaoikZqe1" -H "Fastly-Key: $(fastly profile token -q)" | jq '.data[] | {cert_id: .relationships.tls_certificate, mTLS: .relationships.mutual_authentication}'
{
  "cert_id": {
    "data": {
      "id": "6zNakjJJIMjuKZxRIflD14",
      "type": "tls_certificate"
    }
  },
  "mTLS": {
    "data": null
  }
}

Given the plan output, the activations should have had its certificate_ids updated. Given the state of the activations in Fastly, we should have been warned that the changes would remove the mutual_authentication configuration. Neither of those things happened.

Debug Output (optional)

I can provide this if needed, I'm just working on getting it ready.

Please provide a link to a GitHub Gist containing the complete debug output (see Terraform docs). Ensure any sensitive data is <REDACTED>.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. Uncomment the new line in the tls_domain_activation resource. Comment the old line
3. terraform apply

Important Factoids (optional)

Is there anything atypical about your account or set up that we should know?

[kpfleming]

The version of Terraform being used (1.7.4-dev) is not a current release, and isn't even a formal release. Can this problem be duplicated with 1.8.5 which is the current release?

[landrew57]

Hey @kpfleming apologies for the outdated version. I've just tested with

$ terraform -v
Terraform v1.8.5
on darwin_arm64
+ provider registry.terraform.io/fastly/fastly v5.10.0
+ provider registry.terraform.io/hashicorp/tls v4.0.5

and the behaviour is the same. Shall I update the description of the ticket?

[landrew57]

I have also raised fastly/go-fastly#532 which I think could be related to this issue.

[kpfleming]

Yes, it would be helpful to update the ticket description with the current-version test information. Thanks for doing that. I suspect you are correct that the go-fastly issue is the root cause.

[landrew57]

terraform-provider-fastly/fastly/resource_fastly_tls_activation.go

Lines 89 to 104 in e4c1f63

	err = d.Set("certificate_id", activation.Certificate.ID)
	if err != nil {
	return diag.FromErr(err)
	}
	err = d.Set("configuration_id", activation.Configuration.ID)
	if err != nil {
	return diag.FromErr(err)
	}
	err = d.Set("domain", activation.Domain.ID)
	if err != nil {
	return diag.FromErr(err)
	}
	err = d.Set("created_at", activation.CreatedAt.Format(time.RFC3339))
	if err != nil {
	return diag.FromErr(err)
	}

And some updates in here once that's merged I suppose.

[Integralist]

@landrew57 if you're able to provide DEBUG log output (e.g. FASTLY_DEBUG_MODE=true TF_LOG=DEBUG terraform apply) and share that with us (with sensitive information like API key REDACTED please), then that would help us understand what flow the TF provider went through. Thanks