Issuers, registration and relying parties
The PKIX model distinguishes end entities, certification authorities, optional registration authorities, repositories and potentially separate CRL issuers. A CA certifies a subject–key association, while registration and publication may be delegated rather than running on one server.
A relying party uses certificates to make a decision, such as a client checking a remote service. Publishing a certificate helps retrieval but does not itself perform identity checks, protect private keys or decide client policy. Those responsibilities jointly determine the system’s guarantees.
References: [1]
Trust anchors are inputs to policy
Path validation starts with an accepted trust anchor: a name, public key and associated constraints. A self-signed root certificate can represent it, but trusted configuration or another reliable out-of-band decision establishes trust, not the ability to verify its own signature.
Applications may choose different anchors and impose additional name, policy and usage constraints. Identical certificate bytes can therefore be acceptable inside one organization and unacceptable to another client because their trust inputs differ.
References: [1]
Lifecycle management continues after issuance
After issuance, validity, key replacement and status information still need management. CRLs or OCSP can supply scoped revocation information, but PKI does not promise instantaneous globally consistent status for every visit. Signer authority, timing and applicability must be checked.
Online revocation is not available for every certificate. RFC 9608 defines noRevAvail for end-entity certificates whose CA will not publish revocation information and specifies a validation exception. That explicit policy signal differs from treating a failed status query as permission to skip checking.