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

"key values mismatch" when rebuilding nodes #6

Closed
wwkimball opened this issue Feb 8, 2018 · 3 comments
Closed

"key values mismatch" when rebuilding nodes #6

wwkimball opened this issue Feb 8, 2018 · 3 comments
Assignees

Comments

@wwkimball
Copy link
Contributor

wwkimball commented Feb 8, 2018

Building a fresh node with your module using the DNS-01 mechanism with GoDaddy works mostly well. However, if we destroy a node that had already received its certificate, chain, and key files, we are unable to rebuild that node because we end up with a mismatched certificate/key pair. In my own testing, I was only able to rebuild an affected node by fully destroying both the affected node and the Puppet Server itself, then rebuilding them both! This is obviously not an ideal workaround.

Steps to reproduce:

  1. Build up a fresh Open-Source Puppet 5 Server with your module properly configured.
  2. Attach and build an Apache HTTPd node that also uses your module and requests a Let's Encrypt certificate via the DNS-01 mechanism for an SSL-enabled vhost.
  3. Note that after about 15 minutes and a few Puppet Agent runs on both the Puppet Server and the Apache HTTPd node, it works. [Aside: Please call this out in your README file; that it takes at least15 minutes and a minimum of 3 sequential Puppet Agent runs on the Puppet Server itself to actually obtain a signed certificate. So, if an unattended Puppet Server runs its Agent only once per hour, it will take over 3 hours to obtain a signed certificate!]
  4. Destroy the Apache HTTPd node. We do this deliberately to simulate disaster and other dynamic cloud scaling scenarios.
  5. Rebuild the Apache HTTPd node.
  6. Encounter the intractable error, "key values mismatch" even after the 15 minute minimum delay and any number of Puppet Agent runs on the Puppet Server and Apache HTTPd node.

There is no readily-identifiable way to resolve this error. I manually compared the private key and certificate files on the affected node and indeed, they are mismatched. I tried destroying the old certificate files from /etc/acme.sh/* directories on the Puppet Server for the affected node and repeating the request sequence in hope that your module would re-request fresh copies of the files from GoDaddy, but this had no effect; in fact, the certificate files are never recreated on the Puppet Server. This leaves me to suspect that you're caching the certificates in PuppetDB, which is cool except this needs to be clear in your documentation along with a direct means of flushing affected resources.

Please advise.

@wwkimball
Copy link
Contributor Author

I also noticed that the node's private key doesn't seem to be collected on the Puppet Server; I couldn't find it anywhere. This leads me to suspect your module doesn't cache the original private key. Without it, whenever a node is destroyed and rebuilt, an entirely new private key will be automatically created which will -- of course -- never match the previously-signed certificate that your module will serve up from the Puppet Server.

If this is the case, then please start caching the right private keys with their signed certificates. It is critical for a node to receive the correct pair. Your module could easily pass the matching pair back to the requesting node no matter how many times it gets rebuilt.

@fraenki
Copy link
Member

fraenki commented Jun 16, 2020

If this is the case, then please start caching the right private keys with their signed certificates.

They are not cached on purpose. In my opinion the whole point of this module is a clear separation of concerns.

That being said I still have no idea how to fix the mismatch that occurs when rebuilding nodes (except to manually remove everything, of course), so I'm open to suggestions.

@fraenki
Copy link
Member

fraenki commented Dec 1, 2021

Since nobody has come up with a solution for this problem, I've added an entry to the README.

@fraenki fraenki closed this as completed Dec 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants