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 <[email protected]> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2B%3DBEqXXzTbArHvy3EXkEm9Dt9FMXGjOHrbKk7jOOoAkyFK6jA%40mail.gmail.com.
