azuread_application_certificate: For certificate, the default value of start_date is the “creation date” of the certificate, whereas for symmetric key, the default value is the current timestamp when TF apply is executed.

[chennagouda14]

Community Note

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

Terraform (and AzureAD Provider) Version

Terraform v1.0.0 provider registry.terraform.io/hashicorp/azuread v2.20.0

Affected Resource(s)

• azuread_application_certificate

Terraform Configuration Files

• For example, if the certificate is issued on 7th July 2022 & if it is valid for 1 year which means that the expiry date(end date) would be 8th July 2023.
• So the terraform configuration is as follows:
  • start_date is optional parameter & it is not specified.
  • specified type as AsymmetricX509Cert because it is a certificate.

resource "azuread_application" "example" {
  display_name = "example"
}

resource "azuread_application_certificate" "example" {
  application_object_id = azuread_application.example.id
  encoding              = "pem"
  end_date              = "2023-07-08T00:00:00Z"
  type                  = "AsymmetricX509Cert"
  value                 = file("cert.pem")
}

Expected Behavior

• For Asymmetric certificate (when type=”AsymmetricX509Cert”):

  • As per above configuration, if start_date is not specified for a certificate then after terraform apply is executed, the start_date assigned must be the start date of the certificate when it was issued (it should not be the current timestamp when terraform apply is executed)
  • The same behaviour is observed when a certificate is uploaded on the Azure portal i.e. the start_date of the certificate is the creation date of the certificate & not the current timestamp when it was uploaded.

• For Symmetric key (when type=”Symmetric”):

  • If the start_date is not specified for a symmetric key then the start date for symmetric key should be the current timestamp when terraform apply is executed.

Actual Behavior

• For Asymmetric certificate (when type=”AsymmetricX509Cert”):

  • The Actual behaviour matches with the Expected behaviour for the certificate .i.e. when start_date is not specified for a certificate then the start_date assigned must be the creation date of the certificate when it was issued. The similar behaviour is observed on Azure portal.
  • But this behaviour is not as per the terraform documentation, because the documentation states that “when start_date is not specified then the current timestamp is used”.

  Please find the below output of terraform apply executed on 17th Aug 2022

  On Azure portal:

  On the azure portal, we can see that the start date mentioned for the certificate is the creation date of the certificate & not the current timestamp.

• For Symmetric key(when type=”Symmetric”):

  • The Actual behaviour matches with the Expected behaviour for the symmetric key & there is no issue. Terraform documentation is correct for Symmetric key type.

The terraform documentation for start_date parameter has a valid statement for Symmetric key but for Asymmetric certificate it is invalid statement. Terraform has not explicitly mentioned the behaviour for both Symmetric & Asymmetric type.

Can you please confirm if this is a bug or it needs correction in the terraform documentation?

Steps to Reproduce

1. terraform apply

References

• Terraform reference https://registry.terraform.io/providers/hashicorp/azuread/2.20.0/docs/resources/application_certificate

[manicminer]

Hi @chennagouda14, thanks for reporting this. The behavior you have encountered is the expected behavior, and is actually applied by the API and not by the provider. If our documentation is inaccurate then we'll definitely look to update this accordingly. Thanks!

[chennagouda14]

Thank you for the updates, looking forward for the updated version of the document highlighting this fix.

[github-actions[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.