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

no zero-downtime migration path with universal ssl certificate #4643

Open
3 tasks done
lobeck opened this issue Nov 21, 2024 · 2 comments
Open
3 tasks done

no zero-downtime migration path with universal ssl certificate #4643

lobeck opened this issue Nov 21, 2024 · 2 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/needs-information Indicates an issue needs more information in order to work on it.

Comments

@lobeck
Copy link

lobeck commented Nov 21, 2024

Confirmation

  • This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
  • I have searched the issue tracker and my issue isn't already found.
  • I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

1.9
4.46

Affected resource(s)

cloudflare_record
cloudflare_certificate_pack

Terraform configuration files

resource "cloudflare_record" "test" {
  name    = "test"
  type    = "CNAME"
  content = "test.elb.amazonaws.com"
  proxied = true
  zone_id = data.cloudflare_zone.zone.id
}

import {
  id = "1234/5678"
  to = cloudflare_certificate_pack.test
}

resource "cloudflare_certificate_pack" "test" {
  hosts                 = ["test.domain.com"]
  certificate_authority = "google"
  type                  = "universal"
  validation_method     = "txt"
  validity_days         = 90
  zone_id               = data.cloudflare_zone.zone.id
}

Link to debug output

Panic output

No response

Expected output

record created, certificate issued

Actual output

Error: expected type to be one of ["advanced"], got universal

Steps to reproduce

We're running multiple Partial DNS zones.

Previously, when you created a proxied record, it immediately issued the appropriate certificate automatically without further validation. This worked since the zone itself was ownership validated and Cloudflare found this sufficient proof of ownership.

Issue 1

Now when creating a cloudflare_record, the universal certificate will be created with http validation as default and no option to override. This happens automatically on creation of the record resource.

This is no concern, when the record pointing to Cloudflare is created first. As outlined in the documentation, the certificate will be issued after a brief downtime since Cloudflare can serve the necessary validation http request automatically.

But this does not work when a record is created first in Cloudflare to avoid the mentioned downtime and allow for a zero impact migration.

Issue 2

The attempted workaround to this, was to mange the certificate through a cloudflare_certificate_pack resource. But this does not support universal certificates and would require the issuance of an advanced certificate which are quota'd.

So the only options right now for such a zero downtime migration are either to extract the validation url and content to serve it through the live host or to manually send a PATCH request to change the validation method of the universal certificate.

Issue 3

The third issue is therefore, that you can not access universal certificates through terraform in order to extract the needed validation url and content to serve it elsewhere.

In any case it's not possible to do this natively with terraform and would require manual intervention.

Additional factoids

No response

References

No response

@lobeck lobeck added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 21, 2024
Copy link
Contributor

Community Note

Voting for Prioritization

  • Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

  • If you are interested in working on this issue, please leave a comment.
  • If this would be your first contribution, please review the contribution guide.

Copy link
Contributor

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

@github-actions github-actions bot added triage/needs-information Indicates an issue needs more information in order to work on it. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/needs-information Indicates an issue needs more information in order to work on it.
Projects
None yet
Development

No branches or pull requests

1 participant