fortios_vpncertificate_ca ca attribute needs to be updated

[zippanto]

Hi,

A bit similar to issue #230. When you import or create a fortios_vpncertificate_ca resource on every subsequent apply terraform will try to update the resource ca attribute.

# fortios_vpncertificate_ca.SERVER-CA-1 will be updated in-place
  ~ resource "fortios_vpncertificate_ca" "SERVER-CA-1" {
      + ca                       = <<-EOT
            -----BEGIN CERTIFICATE-----
            .
            .
            .
            -----END CERTIFICATE-----
        EOT
        id                       = "SERVER-CA-1"
        name                     = "SERVER-CA-1"
        # (7 unchanged attributes hidden)
    }

The output of terraform show command shows no record of the ca attribute:

% terraform state show 'fortios_vpncertificate_ca.SERVER-CA-1'
# fortios_vpncertificate_ca.SERVER-CA-1:
resource "fortios_vpncertificate_ca" "SERVER-CA-1" {
    auto_update_days         = 0
    auto_update_days_warning = 0
    id                       = "SERVER-CA-1"
    last_updated             = 0
    name                     = "SERVER-CA-1"
    range                    = "vdom"
    source                   = "user"
    source_ip                = "0.0.0.0"
    ssl_inspection_trusted   = "enable"
}

We checked and the attribute is present in a configuration backup and visible in the CLI (only if you use show full-configuration though). However it seems it's empty when querying the API. So we are not sure if this issue needs to be raised further up the chain with the API team.

Please advise.

Thanks.

[MaxxLiu22]

Hi @zippanto ,

Thank you for raising this issue, I can reproduce it, I will talk to the Terraform and API teams to check if that is on purpose and let you know once there is any improvement.

Thanks, Maxx

[MaxxLiu22]

Hi @zippanto

This issue has been fixed in our latest Terraform FOS 1.19.0, ca would not show in console when apply again. I will go ahead to close this case, you are free to reopen it or another case if you have any other questions.

Thanks, Maxx

[zippanto]

Hi @MaxxLiu22

Unfortunately this is still not fully fixed. Please see below.

  # fortios_vpncertificate_ca.SERVER-CA-1 will be updated in-place
  ~ resource "fortios_vpncertificate_ca" "SERVER-CA-1" {
      ~ ca                       = (sensitive value)
        id                       = "SERVER-CA-1"
        name                     = "SERVER-CA-1"
        # (7 unchanged attributes hidden)
    }

The output of the terraform state show command:

% terraform state show 'fortios_vpncertificate_ca.SERVER-CA-1'
# fortios_vpncertificate_ca.SERVER-CA-1:
resource "fortios_vpncertificate_ca" "SERVER-CA-1" {
    auto_update_days         = 0
    auto_update_days_warning = 0
    ca                       = (sensitive value)
    id                       = "SERVER-CA-1"
    last_updated             = 0
    name                     = "SERVER-CA-1"
    range                    = "vdom"
    source                   = "user"
    source_ip                = "0.0.0.0"
    ssl_inspection_trusted   = "enable"
}

We also double checked the contents of the state file and the ca property does contain the certificate.

Please advise.

Thanks.

[zippanto]

Hi @MaxxLiu22

Could this issue be reopened please?

Thanks.

[zippanto]

Hi @MaxxLiu22

Are there any updates on this please?

Thanks.

[MaxxLiu22]

Hi @zippanto ,

I apologize for the delayed response. After investigation, the root cause is as you mentioned before: the API GET shows an empty value for ca. This may be marked as sensitive info and hidden from the API GET method. In the GUI, acquiring CA certificate content is another API monitor call api/v2/monitor/system/certificate/download/test2 . Additionally, the edit operation can't be achieved; GUI only supports creation and deletion.

I am wondering if you would like to use Terraform to manage an existing CA certificate. How about setting ca = ""? This will maintain consistency between the API GET info and the Terraform state file and will not actually unset the CA in your FGT unless you put valid CA certificate content here. That update operation is not allowed through the GUI. Alternatively, we could remove the requirement of ca since this argument is only required during creation. if you would like to get the content of ca, there is no existing Terraform FOS module to do that, but we could use generic module to achieve that for now. let me know if you need the scrip.

Let me know if these solutions are not suitable in your situation.

Thanks, Maxx

[zippanto]

Hi @MaxxLiu22,

I understand that this is ultimately a limitation on the API / firewall side and there is a good reason for this behaviour.

I don't think the proposed workarounds are appropriate. The workarounds essentially provide a create only functionality which defeats the purpose of using Terraform to manage resources and states.

As we see it this is the same situation that is presented when Terraform needs to manage a resource with password attribute. I believe the way that is addressed on those resources is that if you imported the state although it's the same password set in Terraform as on the firewall it will still have to overwrite it, because there is no way to check if the contents are the same. However after the first apply the provider will maintain a hash of the password in the state which will now be the same hash that is visible on the firewall CLI. If the provider then later on detects a change in the hash that is on the firewall it will update the resource on the firewall. Trying to do this with certificates will likely not work as there is no hash stored on the firewall for certificates.

Do you think this is something that you could propose to the API or other relevant firewall development team to address this issue?

Thanks.

[zippanto]

Hi @MaxxLiu22,

Just wondered if there is any update on this issue?

Thanks.

[MaxxLiu22]

Hi @zippanto ，

The API team has exposed the information of "ca" from FOS 7.4.6 and 7.6.1. The Terraform development team will remove the sensitive flag of it in the next release, meaning that "ca" will be treated like any other normal argument. Thank you for your patience and understanding.

[MaxxLiu22]

Hi @zippanto ,

This issue should have been addressed in version 1.22.1. Please feel free to give it a try at your convenience.

[zippanto]

Hi @MaxxLiu22,

Apologies earlier I commented on and closed the wrong issue so I'm reopening this again.

We have tested this with FortiOS 7.4.8 and it still seems to be an issue. We can see the provider has changed and it doesn't handle the "ca" attribute as sensitive, but it's still trying to update on every apply. The output of subsequent plan / apply now looks slightly different since the "ca" attribute is not sensitive, but it essentially still behaves the same way.

We also noticed a second issue which is related. If the certificate is created with Terraform, on the second apply there is a change in the "last_updated" attribute. After the second apply the update to the "last_updated" attribute won't be there anymore. Please see below.

# fortios_vpncertificate_ca.SERVER-CA-1 will be updated in-place
  ~ resource "fortios_vpncertificate_ca" "SERVER-CA-1" {
      ~ ca                       = <<-EOT
            -----BEGIN CERTIFICATE-----
            .
            .
            .
            -----END CERTIFICATE-----
        EOT
        id                       = "SERVER-CA-1"
      - last_updated             = 1234567890 -> null
        name                     = "SERVER-CA-1"
        # (12 unchanged attributes hidden)
    }

Thanks.

[MaxxLiu22]

Hi @zippanto ,

Thank you for the information.

Since the API team is now exposing the content of the CA, Terraform no longer treats it as sensitive and automatically removes the sensitive flag. However, due to minor differences between the locally defined CA and the version returned by the API, Terraform continuously detects changes. To resolve this, we are considering normalizing or reformatting the returned CA data to ensure consistency and eliminate unnecessary diffs.

As for the last_updated field, unsetting it to 0 does not appear to be meaningful. We are evaluating the removal of this unset operation in future updates, which should prevent Terraform from showing changes on the second apply.

Apologies for any inconvenience this may have caused. These fields are documented like any other general attributes in the API schema. However, we recognize that certain fields, like last_updated, may carry unique semantics in practice, even they are noted can be unset. We will explore handling such cases more granularly moving forward.

[MaxxLiu22]

Hi @zippanto ,

The issue of last_updated being unset to null should be addressed in Terraform FOS 1.22.2. Since this argument is not read-only and can be edited, Terraform resets it to 0 on the second apply. Please let me know if this works for you.

Thanks, Maxx

[zippanto]

Hi @MaxxLiu22,

I can confirm that the issue with last_updated is fixed in 1.22.2.

Thanks.