Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fortios_vpncertificate_ca ca attribute needs to be updated #312

Open
zippanto opened this issue Jan 10, 2024 · 7 comments
Open

fortios_vpncertificate_ca ca attribute needs to be updated #312

zippanto opened this issue Jan 10, 2024 · 7 comments

Comments

@zippanto
Copy link

zippanto commented Jan 10, 2024

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
Copy link

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
Copy link

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
Copy link
Author

zippanto commented Feb 26, 2024

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
Copy link
Author

Hi @MaxxLiu22

Could this issue be reopened please?

Thanks.

@MaxxLiu22 MaxxLiu22 reopened this Mar 15, 2024
@zippanto
Copy link
Author

Hi @MaxxLiu22

Are there any updates on this please?

Thanks.

@MaxxLiu22
Copy link

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
Copy link
Author

zippanto commented Jun 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants