Skip to content

Document how the CA CLI is authorized and fix stale CA endpoint statements - #485

Open
miharp wants to merge 2 commits into
OpenVoxProject:masterfrom
miharp:docs/ca-cli-auth
Open

miharp wants to merge 2 commits into
OpenVoxProject:masterfrom
miharp:docs/ca-cli-auth

Conversation

@miharp

@miharp miharp commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

Closes #484

A recent Slack thread had maintainers unsure why puppetserver ca list works on a fresh primary with no auth.conf changes. The answer (the server's own certificate carries the pp_cli_auth extension, and the shipped auth.conf authorizes the CA admin endpoints on that extension) was not written down anywhere, and a few related pages still carried statements from before that mechanism existed.

Changes, applied to both the 8.x and 9.x trees:

  • Subcommands page: replace the Puppet 5 upgrade note and its allow: master.example.com example with a "CA CLI authorization" section. It explains that ca setup and ca import add pp_cli_auth to the server certificate, how to check for it with openssl x509, what breaks if the server certificate is regenerated another way, and that puppetserver ca generate --ca-client is the supported way to issue the extension to another host (with a warning that it is an administrative credential).
  • auth.conf page: show the shipped puppetlabs cert status rule as the worked example of extensions matching and link to the new section.
  • Registered OIDs include (used by the SSL extensions and CSR attributes pages): add pp_owner, pp_auth_auto_renew, and pp_cli_auth, which lib/puppet/ssl/oids.rb registers but the table omitted. The ppAuthCertExt rows had no table header, so they rendered as a paragraph; this adds one.
  • Certificate status endpoint page: drop "This endpoint is disabled in the default configuration" and describe the actual default.
  • Bulk sign endpoint page: the rules live in auth.conf, not ca.conf.

Sources: openvoxserver-ca gem local_certificate_authority.rb (CLI_AUTH_EXT_OID, add_authorized_extensions, called from setup.rb, import.rb, and the --ca-client path in generate.rb) and openvox-server ezbake/config/conf.d/auth.conf.

Verified with markdownlint-cli2 on every touched file and a full jekyll build; the new anchor resolves from all four linking pages in both trees.

Assisted by Claude.

@miharp
miharp marked this pull request as ready for review September 15, 2026 13:06
@miharp
miharp requested a review from a team as a code owner September 15, 2026 13:06
}
```

See [CA CLI authorization](./subcommands.html#ca-cli-authorization) for how the server's own certificate gets that extension and how to issue it to another host.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if we need to make this distinction: We can create unlimited certificates with this certificate extension and IMO it's common to have multiple of them - if you need to call the APIs from other services.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, updated it.

miharp and others added 2 commits September 18, 2026 06:57
…ments

Explain that puppetserver ca setup and ca import stamp the server's own
certificate with the pp_cli_auth extension, that the default auth.conf
authorizes the CA administrative endpoints on that extension rather than
by certname, and that --ca-client is the way to issue it to another host.

Add pp_owner, pp_auth_auto_renew, and pp_cli_auth to the registered OIDs
table and give the ppAuthCertExt rows a proper table header. Correct the
certificate status page, which still said the endpoint was disabled by
default, and the bulk sign page, which pointed at ca.conf instead of
auth.conf. Replace the Puppet 5 upgrade note on the subcommands page with
a CA CLI authorization section and show the shipped cert status rule as
the extensions example on the auth.conf page.

Closes OpenVoxProject#484

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Michael Harp <mike@mikeharp.com>
Review feedback: the server's own certificate is not special. Any service that
calls the CA API gets a certificate with the extension, and having several
is normal, so stop framing the server as the holder and other hosts as the
exception.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Michael Harp <mike@mikeharp.com>
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

Successfully merging this pull request may close these issues.

Document pp_cli_auth: how the CA CLI is authorized, and fix stale CA endpoint statements

2 participants