The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
enhancements to SSL for puppet apply
|Keywords:||Affected PuppetDB version:|
your typical puppet apply setup would not have a CA so there wont be certs prior to enabling the puppetdb terminus , when running it against a remote puppetdb you get:
warning: peer certificate won't be verified in this SSL session err: Cached facts for dev4.devco.net failed: Failed to find facts from PuppetDB at dev3.devco.net:8081: SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert bad certificate warning: peer certificate won't be verified in this SSL session Could not run: Could not retrieve facts for dev4.devco.net: Failed to submit 'replace facts' command for dev4.devco.net to PuppetDB at dev3.devco.net:8081: SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert bad certificate
So without a shared CA this leaves a few options:
- let people specify completely custom sets of certs both on puppetdb and the node side as ppl might have some shared pki already
- allow anon SSL which would at least encrypt the payload if not protect against MITM
- allow plain text calls to the puppetdb and make this configurable on the clients
#1 Updated by Deepak Giridharagopal about 4 years ago
- Status changed from Unreviewed to Accepted
- Priority changed from Normal to Low
I’m marking this as “low” priority not because I don’t think it’s important, but because there’s a (not great, but functional) workaround: you can use something else to handle SSL termination, like nginx or apache, and have that only do anonymous SSL.
Implementation-wise, I believe we have code that already handles making puppetdb do this by itself…my hunch is that it’s just a matter of making those options configurable by the end-user.