Refresh the Infrastructure CRL page: branding, how the feature works, and a compiler warning #490

Summary

The Infrastructure CRL page (docs/_openvox-server_8x/infrastructure_crl.markdown and the 9.x copy, which are identical) was imported from the Puppet Server docs and never refreshed. It still uses Puppet branding and retired terms, it is thin on how the feature works, and it leaves out one consequence that weakens revocation checking on compilers.

Gaps

1. Branding and terminology

• Front matter: title: "Puppet Server: Infrastructure CRL" and canonical: "/puppetserver/latest/infrastructure_crl.html". The canonical path points at a URL this site does not serve.
• A second H1 in the body ("Infrastructure certificate revocation list") under the layout's title.
• Body text: "Puppet Server CA" (three times), "compile masters", "single master configuration", "open source Puppet".

Six other pages in each server collection have the same title: "Puppet Server: …" and canonical: "/puppetserver/…" front matter: external_ssl_termination, gems, restarting, ssl_server_certificate_change_and_virtual_ips, subcommands, and tuning_guide. They could be fixed in the same PR or tracked separately.

2. The page does not say how the feature works

Source of truth, openvox-server:

• certificate_authority_core.clj, resolve-crl-information: when enable-infra-crl is true, the certificate_revocation_list endpoint serves the file at infra-crl-path ($cadir/infra_crl.pem) and not cacrl. Every client gets the infra CRL, not only "when agents first check in" as the page says. Agents download the CRL again whenever it is missing or crl_refresh_interval has passed.
• certificate_authority_service.clj: a file watcher on $cadir/infra_inventory.txt regenerates the infra serials file when the inventory changes, so edits take effect without a restart. The page does not say whether a reload is needed after editing the inventory.
• The page names the setting as certificate-authority.enable-infra-crl in one paragraph and says to update "puppetserver.conf" in the next. config_file_ca documents the setting under ca.conf. The page should name one file and link to that section. Nothing links to the infra CRL page today except the nav.
• The full CRL is still maintained, and the web server on the CA host still checks clients against the full CRL (the server copies cacrl, never the infra CRL, to hostcrl; see Document why OpenVox Server overwrites hostcrl, and the workaround when the agent trusts a different CA #488). The page should say that enabling the feature changes what is distributed, not what the CA server itself enforces.

3. Missing warning: compilers stop refusing revoked agents

A compiler runs with the CA service disabled and gets its CRL through its own agent, like any other node. With the infra CRL enabled, that CRL lists only revoked infrastructure nodes. A compiler whose web server reads the agent's copy (ssl-crl-path pointing at $ssldir/crl.pem, or the hostcrl default) then never refuses a revoked ordinary agent. Only the CA server does.

This comes from reading the source and has not been lab-tested. It should be verified with a primary plus compiler pair before the warning is written, and the page should then say what to do about it: leave the feature off when compilers must enforce revocation, or distribute the full CRL to compilers by other means.

4. Who the feature is for

The page says the feature is off by default because "infrastructure" is site-specific. It does not say when turning it on is worth it: large fleets where the full CRL is big and agents only ever connect to a few infrastructure hosts. One or two sentences on that trade-off would help a reader decide.

Proposed fix

One PR touching the 8.x and 9.x copies of infrastructure_crl.markdown:

• fix the front matter, drop the duplicate H1, and replace the retired terms (OpenVox Server, compilers, primary server);
• describe what is served to whom, the inventory file watcher, and the single place to set enable-infra-crl, with links to and from config_file_ca;
• add the compiler warning once verified, with a link to the hostcrl section added in Explain why OpenVox Server overwrites hostcrl and how to avoid it #489;
• optionally fix the same front matter on the six sibling pages.

Assisted by Claude.