azurerm_app_service_managed_certificate - bind certificate to the defined hostname

[jackofallops]

Upgrade Notes:
azurerm_app_service_managed_certificate now requires the ssl_state property, which can be one of SniEnabled or IpBasedEnabled to define the SSL type for the certificate on the hostname it is bound to.

Cannot run in CI yet, but tests pass and resources are correctly configured:

=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicLinux
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicLinux
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicLinux
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicLinux (284.79s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicImport
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicImport
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicImport
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicImport (298.75s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicWindows
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicWindows
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicWindows
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicWindows (295.67s)
PASS

TODO:

• Add test coverage for Function Apps
• docs

Replaces #9415
resolves #4824

[jackofallops]

Function App test passing:

=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp (620.59s)
PASS

[mbfrahry]

Hey @jackofallops! This PR looks good but I'm worried about people upgrading their provider from the old version to this version and having to recreate the resource.

[mbfrahry]

Just to confirm, is this the default that's passed back from the API when we don't specify ssl_state. I'd just like to confirm that this won't cause a recreation of this resource when people upgrade the provider

[jackofallops]

You have to pick one, and it can only be applied here (the binding itself rejects a value here unless the thumbprint is also supplied at creation). Strictly speaking, this is Required, but we try to avoid introducing new properties as such. So it's a call one way or the other... This will only have a value for customers that have manually bound the cert to the hostname, and we can add an upgrade note to the changelog to cover this change?

[jackofallops]

Updated tests passing:

=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicLinux
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicLinux
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicLinux
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicLinux (293.41s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_updateSSLState
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_updateSSLState
=== CONT  TestAccAzureRMAppServiceManagedCertificate_updateSSLState
--- PASS: TestAccAzureRMAppServiceManagedCertificate_updateSSLState (337.41s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_requiresImport
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_requiresImport
=== CONT  TestAccAzureRMAppServiceManagedCertificate_requiresImport
--- PASS: TestAccAzureRMAppServiceManagedCertificate_requiresImport (321.81s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicWindows
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicWindows
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicWindows
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicWindows (276.41s)
=== RUN   TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
=== PAUSE TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
=== CONT  TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp
--- PASS: TestAccAzureRMAppServiceManagedCertificate_basicFunctionApp (279.54s)
PASS

[AdamCoulterOz]

@jackofallops The binding operation is against a different resource than the certificate (a modification of a part of an existing hostname_binding), so not sure why we aren't creating a new binding resource which will supersede the binding part of the hostname_binding resource, and handle all certificate bindings (deprecating those fields in the existing resource). That was the start of what I proposed in #8069

There was an explicit example of another use case where this would be useful (not just for managed certificates), when using lets encrypt... #8069 (comment)

I've also just submitted a PR #9701 which patches the existing managed_certificate resource, as ARM forces it (overrides what value you provide) for the resource group to be that of the service plan its hosted in. We need to be careful that the (real) certificate ID and the hostname_binding it patches could be in different RGs. This complexity is bypassed (as well as forming the basis for the initial point) if you use the resource proposal and interface I created for this in PR #9415

[jackofallops]

@jackofallops The binding operation is against a different resource than the certificate (a modification of a part of an existing hostname_binding), so not sure why we aren't creating a new binding resource which will supersede the binding part of the hostname_binding resource, and handle all certificate bindings (deprecating those fields in the existing resource). That was the start of what I proposed in #8069

There was an explicit example of another use case where this would be useful (not just for managed certificates), when using lets encrypt... #8069 (comment)

I've also just submitted a PR #9701 which patches the existing managed_certificate resource, as ARM forces it (overrides what value you provide) for the resource group to be that of the service plan its hosted in. We need to be careful that the (real) certificate ID and the hostname_binding it patches could be in different RGs. This complexity is bypassed (as well as forming the basis for the initial point) if you use the resource proposal and interface I created for this in PR #9415

Apparently I'd taken too narrow a view of what we were looking to achieve, my apologies, I'd not considered the additional cases. I was out at short notice Friday, I'll pick this back up asap today.

[jackofallops]

Closing this in light of additional use cases. Will work with @AdamCoulterOz to update #9415 to cover these.

[ghost]

This has been released in version 2.40.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.40.0"
}
# ... other configuration ...

[ghost]

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!