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

Certificate bundle does not contain exactly 2 certificates #154

Closed
lonegunmanb opened this issue Feb 20, 2021 · 9 comments
Closed

Certificate bundle does not contain exactly 2 certificates #154

lonegunmanb opened this issue Feb 20, 2021 · 9 comments

Comments

@lonegunmanb
Copy link

lonegunmanb commented Feb 20, 2021

Dear Provider's Developer,

I like this provider very much, makes day easier in a cloud-native environment. But when I apply tf code as below, I encountered "Certificate bundle does not contain exactly 2 certificates" error:

terraform {
  required_providers {
    acme = {
      source  = "vancluever/acme"
      version = "2.1.1"
    }
  }
}

provider "acme" {
  server_url = "https://acme-v02.api.letsencrypt.org/directory"
}

resource "tls_private_key" "private_key" {
  algorithm = "RSA"
}

resource "acme_registration" "reg" {
  account_key_pem = tls_private_key.private_key.private_key_pem
  email_address   = "xxx@hotmail.com"
}

resource "acme_certificate" "lonegunman" {
  account_key_pem       = acme_registration.reg.account_key_pem
  common_name           = "www.lonegunman.xyz"
  key_type              = "4096"
  recursive_nameservers = ["119.29.29.29:53"]
  min_days_remaining    = 360
  dns_challenge {
    provider = "dnspod"
    config   = {
      DNSPOD_API_KEY      = var.dnspod_api_key
      DNSPOD_TTL          = "600"
      DNSPOD_HTTP_TIMEOUT = "10m"
    }
  }
}

output "privkey" {
  value = acme_certificate.lonegunman.private_key_pem
}

output "cert" {
  value = "${acme_certificate.lonegunman.certificate_pem}${acme_certificate.lonegunman.issuer_pem}"
}

I traced this error message to acme_structure.go, there're two functions throw this error message: splitPEMBundle and bundleToPKCS12. I modified code and compiled my own plugin then replaced plugin downloaded from registry, I found parsePEMBundle function returned 3 certs instead of 2, so the guard code throws error. After bypassed the guard, everything was fine, the cert this provider returned worked just perfect.

Was there something wrong in my Terraform code? Many Thanks!

@Aransh
Copy link

Aransh commented Feb 21, 2021

Experiencing the same issue since this morning

Not sure if relevant but after trying to run apply several times I'm either getting "Certificate bundle does not contain exactly 2 certificates" or "failed to initiate challenge: net/http: timeout awaiting response headers"
Was working fine a few days ago...

@mboutet
Copy link

mboutet commented Feb 21, 2021

As @lonegunmanb suggested, commenting the two checks raising "Certificate bundle does not contain exactly 2 certificates" and re-compiling the provider works and produce valid certificates.

@Kasper-Jensen
Copy link

Any updates on this? @vancluever

@vancluever
Copy link
Owner

vancluever commented Feb 22, 2021

Hey all, I'm reviewing the recent updates to the certificate chain on Let's Encrypt, which I'm imagining is the source of this issue. I'm able to reproduce this on staging. I'll update soon. Thanks for bringing this to my attention!

@vancluever
Copy link
Owner

Deleted my last comment regarding chain introspection, don't worry about it.

I've been able to find plenty of background regarding this and also a possible path to getting some better assertions regarding the certificate chain as per the PreferredChain option (which I'd imagine will be more important here now with the varying options in light of the update).

Just going to finish reading up on things before putting in a fix as a stop-gap, then we can add the option after if need be.

References:
https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html
https://letsencrypt.org/2020/11/06/own-two-feet.html
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
go-acme/lego#1333
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
https://github.com/go-acme/lego/blob/620a48a3743435c6a9324784ed291c7062edf57d/cmd/cmd_run.go#L46-L49

vancluever added a commit that referenced this issue Feb 22, 2021
Let's Encrypt, in part of the work in migrating to their own independent
root CA certificate, has introduced an additional intermediate in the
default chain to help compatibility with older systems, namely Android
devices.

The new chain is now being issued with new requests, which has caused
issues with our current assertions where we look for two certificates.
This assertion possibly could fail with other ACME CAs that are not
Let's Encrypt that may eventually need to do something similar.

For now, we are just removing the assertion that expects this. For PEM
encoding we are just concatenating the entire collection of issuer
certificates in issuer_pem. This will be migrated to a list at a later
time. Since PFX encoding takes certificates un-encoded, this is a more
natural, graceful change.

Additionally, we should look to add a certificate chain preference at a
later time, as Let's Encrypt will be eventually transitioning their
default chain to one that does not include the cross-signed
intermediate.

Related to #154.
@vancluever
Copy link
Owner

Hey all, 2.1.2 is out now which should fix this - can everyone test and let me know?

@mboutet
Copy link

mboutet commented Feb 22, 2021

@vancluever, works for me on LE staging. Thanks a lot!

@lonegunmanb
Copy link
Author

Hey all, 2.1.2 is out now which should fix this - can everyone test and let me know?

Thanks a lot @vancluever ,2.1.2 works perfect!

@vancluever
Copy link
Owner

Thanks for the update @lonegunmanb and thanks for reporting!

saitho pushed a commit to getstackhead/terraform-provider-acme that referenced this issue Feb 28, 2021
Let's Encrypt, in part of the work in migrating to their own independent
root CA certificate, has introduced an additional intermediate in the
default chain to help compatibility with older systems, namely Android
devices.

The new chain is now being issued with new requests, which has caused
issues with our current assertions where we look for two certificates.
This assertion possibly could fail with other ACME CAs that are not
Let's Encrypt that may eventually need to do something similar.

For now, we are just removing the assertion that expects this. For PEM
encoding we are just concatenating the entire collection of issuer
certificates in issuer_pem. This will be migrated to a list at a later
time. Since PFX encoding takes certificates un-encoded, this is a more
natural, graceful change.

Additionally, we should look to add a certificate chain preference at a
later time, as Let's Encrypt will be eventually transitioning their
default chain to one that does not include the cross-signed
intermediate.

Related to vancluever#154.

(cherry picked from commit a8f59aa)
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

5 participants