Terraform-provider-azurerm: frontdoor custom_https_configuration can't update certificate

[timja]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Affected Resource(s)

• azurerm_frontdoor

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp

resource "azurerm_resource_group" "example" {
  name     = "debug-frontdoor-timj"
  location = "uksouth"
}

data "azurerm_key_vault" "vault" {
  name = "***"
  resource_group_name = "***"
}

resource "azurerm_frontdoor" "example" {
  name                                         = "timj-debug"
  location                                     = "Global"
  resource_group_name                          = azurerm_resource_group.example.name
  enforce_backend_pools_certificate_name_check = false

  routing_rule {
    name               = "exampleRoutingRule1"
    accepted_protocols = ["Http", "Https"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["exampleFrontendEndpoint1"]
    forwarding_configuration {
      forwarding_protocol = "HttpOnly"
      backend_pool_name   = "exampleBackendBing"
    }
  }

  backend_pool_load_balancing {
    name = "exampleLoadBalancingSettings1"
  }

  backend_pool_health_probe {
    name = "exampleHealthProbeSetting1"
  }

  backend_pool {
    name = "exampleBackendBing"
    backend {
      host_header = "****"
      address     = "****"
      http_port   = 80
      https_port  = 443
    }

    load_balancing_name = "exampleLoadBalancingSettings1"
    health_probe_name   = "exampleHealthProbeSetting1"
  }

  frontend_endpoint {
    name                              = "exampleFrontendEndpoint1"
    host_name                         = "plum.timja.dev"
    custom_https_provisioning_enabled = true
    custom_https_configuration {
      certificate_source = "AzureKeyVault"
      azure_key_vault_certificate_secret_name = "plum-timja-dev"
      azure_key_vault_certificate_secret_version = "557c2ff331a74e00a413289f01b1b82e"
      azure_key_vault_certificate_vault_id = data.azurerm_key_vault.vault.id
    }
  }

}

Debug Output

The enableHttps endpoint isn't called

Expected Behavior

Certificate should be updated by updating the version field

Actual Behavior

Plan says it will change the version but it doesn't

Steps to Reproduce

1. terraform apply
2. update certificate version to a new one
3. terraform apply
4. observe cert hasn't updated

Important Factoids

I've taken a look through the code,
this line is the issue:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/frontdoor/resource_arm_frontdoor.go#L596

It only updates the https configuration if its state is disabled

If I change it to just:

if customHttpsProvisioningEnabled

Then it works

I ran it locally and after ~2hr it was updated

I ran it again and its still running after 20m so I don't think that calling this endpoint every time is a great idea,

I guess we need to check each field and see if there's been an update unless anyone has a better idea?

References

• #0000

cc @WodansSon

[WodansSon]

@timja, thank you for opening this issue, the Front Door API is a monolithic API where you pass your configuration to the top level controller and it figures out the order and what needs to be done and then queues the work for the sub systems to pick up. Therefore, the resource has been code in the way it has been for a reason, and as inconvenient as it is, given the current state of the API, it must be done in this order. To do what you would like to do with this PR the following steps should be taken:

• Disable Custom HTTPS (this may take up to 24 hours to complete)
• Update the keys in your key vault
• Enable Custom HTTPS (this may take up to 48 hours to complete)

There is a lot of work the front door API is doing behind the scenes, de-provisioning the cert, updating DNS records, etc... so, I know this is less than ideal, but until the service team updates the API architecture this behavior is currently by design.

Per the Front Door Service Team:
"AFD currently does not support autorotation and does not automatically detect if the customer has changed their cert in their key vault. If custom HTTPS is enabled, there's currently no way to automatically provision the new cert with no customer interaction. If a customer has updated their certificate, they would have to re-enable HTTPS with the new cert version, or as you suggested, disable and re-enable."

Unfortunately, due to the above reasons I would suggest closing this issue as by design.

[timja]

Hi @WodansSon

We don’t need an automatic way based on the cert appearing in key vault, we need terraform to be able to update it. And it’s absolutely possible to update it.

The api is monolithic except for the custom https configuration which can be updated independently there’s a separate API for it

The way you’re suggesting causes downtime which is absolutely not necessary.

It takes ~10-15 minutes for the cert to be updated, I haven’t checked that it’s actually on the front door at that time, but both the api and the portal say that it’s using the updated version.

[luigibk]

@WodansSon, thanks for getting back to us. I am not sure the scope of this issue and the attached PR is very clear, given your comments. First of all this does not change in any way the interaction between the provider and the part of the Frontdoor api that deals with creating and destroying resources. Its only aim is fixing the 2 main issues we are experiencing while using Custom https configurations, specifically:

1. Custom https configurations in frontdoor cannot be updated properly. See steps above to reproduce this bug. It boils down to a bad equality check, so after a certificate is updated in keyvault (e.g. renewed), running terraform again with the new certificate_secret_version value does not trigger an update of the custom https configuration.

2. Disabling/Enabling a custom https configuration, with the intention of updating its configuration, to replace, for instance, the current certificate_secret_version with a new one upon certificate renewal runs serially instead of in parallel. In some environments we have 25 frontend endpoints which all use the same *.domain certificate. When this certificate is renewed, all those custom https configurations should be updated in parallel by changing their certificate_secret_version in terraform. At the moment (i.e. after fixing the bug above) they are updated one after the other. Actually they just timeout at the 2nd or 3rd custom https configuration update, making the entire use case impossible to complete using terraform.

The API calls used in the related PR (https://github.com/terraform-providers/terraform-provider-azurerm/pull/7498) are:

• https://docs.microsoft.com/en-us/rest/api/frontdoorservice/frontdoor/frontendendpoints/get
• https://docs.microsoft.com/en-us/rest/api/frontdoorservice/frontdoor/frontendendpoints/enablehttps
• https://docs.microsoft.com/en-us/rest/api/frontdoorservice/frontdoor/frontendendpoints/disablehttps

which are clearly documented by Microsoft and available to use. Therefore it looks to me like there might be a misunderstanding on the scope of this issue and the related PR.

The issues above are current and make Terraform not really usable with custom https configurations where the certificate is stored in keyvault, so I find the idea of closing it as "by design" not really satisfactory, especially considering that what PR 7498 does can already be done using the portal. After many many clicks, the custom https configurations are updated in parallel there. I hope the above discussion provides some clarity on all this.

[WodansSon]

@timja @luigibk, I understand your concern and I know it is frustrating(and slow) having to disable and re-enable the custom HTTPS certs for the AFD(Azure Front Door) resource. I am currently consulting with the service team to see if the "_update in place_" scenario is supported and recommended by their team. I will reply once I have heard back from them, if this is supported by the service team I will finish my review of the PR. Thanks again and sorry this is taking so long, lots of people still out on vacation. 🙂

[WodansSon]

@timja @luigibk, I have heard back from the service team and here is what they said:

"_...AFD does support updating custom HTTPS cert on a frontend endpoint without revoking the original cert. If the customer has a new cert version in their key vault, they should be able to call the enableHttps API and pass in the new secret version..._"

So, this is a supported scenario per the service team. So, I will go ahead and finish looking at the PR, thanks again for your patience. 🚀

[hashibot[bot]]

This has been released in version 2.20.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.20.0"
}
# ... other configuration ...

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!