In Puppet 6 and the latest Puppet 5 releases we shipped a subcommand with Puppet Server `puppetserver ca` and an agent local subcommand `puppet ssl` that can remotely manage the CA or manage an agent's local certificate info respectively. These tools exist in Puppet 5 and and replaces the several competing certificate related cli tools in Puppet 6.
Running `puppetserver ca revoke --certname server` from the Puppet Server should let someone revoke a cert from the CLI in Puppet 6. On a different host that command would return a 403 because the auth system expects the user attempting the request to have a pp_cli_auth extension in their cert. Here's that auth rule: https://github.com/puppetlabs/puppetserver/blob/master/ezbake/config/conf.d/auth.conf#L60-L73 If you wanted a node to be able to manage it's own certificate you might be able to do something more like how we auth catalog access: https://github.com/puppetlabs/puppetserver/blob/master/ezbake/config/conf.d/auth.conf#L4-L14 That line makes it so only the node whose name matches a segment in the url can access it. Additional docs for that file and what it can do are here: https://github.com/puppetlabs/trapperkeeper-authorization/blob/master/doc/authorization-config.md#rules hth, Justin On Tue, Jul 14, 2020 at 4:22 PM Randy Zagar <jrza...@gmail.com> wrote: > Did you ever get this to work? I used a similar method in an engineering > lab where systems regularly got re-imaged and, hence, needed to be able to > revoke and clean their own cert on the puppet-ca > > On Thursday, August 17, 2017 at 12:23:10 PM UTC, Jason McMahan wrote: >> >> Good morning, >> We installed a puppet agent on our citrix mgmt servers. >> The problem became that the way it is done a golden image is used, >> server_dev. Once sealed that spins off multiple other servers for stage and >> prod environments. >> >> We want to know about the servers, ensure they are in configuration and >> not drifting between rebuilds and keep reports for a history on them. >> >> The idea was to once they are done stop the service (not disable), delete >> the ssl directory, then revoke and delete the cert on the puppetca. >> >> >> Has anyone else attempt to revoke and delete cert remotely from the >> puppetca? >> >> We are attempting a curl command like >> curl -X DELETE --tlsv1 --cacert >> /etc/puppetlabs/puppet/ssl/certs/ca.pem --cert >> /etc/puppetlabs/puppet/ssl/certs/server.pem --key >> /etc/puppetlabs/puppet/ssl/private_keys/server.pem -H "Accept: >> application/json" -H "Content-Type: application/json" -d >> '{"desired_state":"revoked"}' >> https://puppetcat:8140/puppet-ca/v1/certificate_status/server?environment=production >> >> But everytime we get forbidden 403 whether running curl command from >> remote server or even the puppetca itself. >> Attemped to add ip to >> /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf as well as >> /etc/puppetlabs/puppetserver/conf.d/ca.conf but still same error. >> >> >> Any help or suggestions would be greatly appreciated. >> Thank you >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/8c9be388-990e-4d02-a376-b1d1dca394c9o%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/8c9be388-990e-4d02-a376-b1d1dca394c9o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2B%3DBEqXXzTbArHvy3EXkEm9Dt9FMXGjOHrbKk7jOOoAkyFK6jA%40mail.gmail.com.
