vancluever / terraform-provider-acme

Terraform ACME provider
https://registry.terraform.io/providers/vancluever/acme/latest
Mozilla Public License 2.0
226 stars 73 forks source link

Zone apex Subject alternative name not working with wildcards #419

Closed wirepatch closed 5 months ago

wirepatch commented 5 months ago

I'd like to support both a domain apex https://goik.sdi.hdm-stuttgart.cloud and https://www.goik.sdi.hdm-stuttgart.cloud by a single cert.

Starting from the acme_certificate example I set up:

resource "acme_certificate" "certificate" {
  account_key_pem           = acme_registration.registration.account_key_pem
  common_name               = "www.goik.sdi.hdm-stuttgart.cloud"
  subject_alternative_names = ["goik.sdi.hdm-stuttgart.cloud"]

  dns_challenge {
    provider = "rfc2136"

    config = {
      RFC2136_NAMESERVER     = "ns1.sdi.hdm-stuttgart.cloud"
      RFC2136_TSIG_ALGORITHM = "hmac-sha512"
      RFC2136_TSIG_KEY       = "goik.key."
      RFC2136_TSIG_SECRET    = file("../dnsupdatetoken.key")
    }
  }
  depends_on = [acme_registration.registration]
}

The Bind server's log shows success:

... updating zone 'goik.sdi.hdm-stuttgart.cloud/IN': deleting rrset at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT
... adding an RR at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT "Edek3mxk8AuhAEsgAIgJCb0C-0aJnO5_F7R39nPPy1k"
... deleting rrset at '_acme-challenge.www.goik.sdi.hdm-stuttgart.cloud' TXT
... adding an RR at '_acme-challenge.www.goik.sdi.hdm-stuttgart.cloud' TXT "GBOvjml1PdGBa6j9RSq7kjp0ZoIfVruTTQG8m5RjVKM"

So there are two challenges acting on separate zones goik.sdi.hdm-stuttgart.cloud and www.goik.sdi.hdm-stuttgart.cloud. Now I replace www.goik.sdi.hdm-stuttgart.cloud by a wildcard *.goik.sdi.hdm-stuttgart.cloud. This works well without the subsequent subject_alternative_names. But in presence of that line ...

...
  common_name                =  "*.goik.sdi.hdm-stuttgart.cloud"
  subject_alternative_names  =  ["goik.sdi.hdm-stuttgart.cloud"]
...

... certificate generation fails:

...
acme_certificate.certificate: Still creating... [1m10s elapsed]
acme_certificate.certificate: Still creating... [1m20s elapsed]
╷
│ Error: error creating certificate: error: one or more domains had a problem:
│ [*.goik.sdi.hdm-stuttgart.cloud] propagation: time limit exceeded: last error: NS ns1.goik.sdi.hdm-stuttgart.cloud. did not return the expected TXT record [fqdn: _acme-challenge.goik.sdi.hdm-stuttgart.cloud., value: 9xRJx_tyhCOIY-17tpZQZOi608d8yZMd03xJgQA6Gio]: a4GltWzN7vA4QgXs_55dpetl5x5nt2aHsYhTYoKMSvQ
│
...

The log reveals the culprit:

... updating zone 'goik.sdi.hdm-stuttgart.cloud/IN': deleting rrset at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT
... updating zone 'goik.sdi.hdm-stuttgart.cloud/IN': adding an RR at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT "9xRJx_tyhCOIY-17tpZQZOi608d8yZMd03xJgQA6Gio"
... updating zone 'goik.sdi.hdm-stuttgart.cloud/IN': deleting rrset at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT
... updating zone 'goik.sdi.hdm-stuttgart.cloud/IN': adding an RR at '_acme-challenge.goik.sdi.hdm-stuttgart.cloud' TXT "a4GltWzN7vA4QgXs_55dpetl5x5nt2aHsYhTYoKMSvQ"

Thus instead of modifying two different zones the second challenge just overrides the first one by acting on the now common zone _acme-challenge.goik.sdi.hdm-stuttgart.cloud.

N.b.: According to https://help.eurodns.com/s/article/Does-the-wildcard-secure-the-apex-domain-in-a-SSLcertificate the apex can be included in a single domain cert.

vancluever commented 5 months ago

@wirepatch this looks like a lego issue (we don't do any pre-processing on the domains). Have you tried replicating the issue with lego yet as per https://github.com/vancluever/terraform-provider-acme/blob/main/docs/lego.md?

wirepatch commented 5 months ago

@wirepatch this looks like a lego issue (we don't do any pre-processing on the domains). Have you tried replicating the issue with lego yet as per https://github.com/vancluever/terraform-provider-acme/blob/main/docs/lego.md?

Thx! Being new to the game I tried my best at https://github.com/go-acme/lego/issues/2211

vancluever commented 5 months ago

@wirepatch as mentioned over in the lego issue we'll continue the thread over here. As it stands the issue is possibly due the lack of communication in our own wrapper about the provider being parallel - I'll repro it and fix on this side.