Publishing Certificates And Crls - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

• In automatic enrollment, end-entity requests are authenticated using a plug-in, and then the
certificate request is processed; an agent is not involved in the enrollment process.
• In CMC enrollment, a third party application can create a request that is signed by an agent and
then automatically processed.
A Certificate Manager is initially configured for agent-approved enrollment and for CMC authentication.
Automated enrollment is enabled by configuring one of the authentication plug-in modules. More
than one authentication method can be configured in a single instance of a subsystem. The HTML
registration pages contain hidden values specifying the method used. With certificate profiles, the
end-entity enrollment pages are dynamically-generated for each enabled profile. The authentication
method associated with this certificate profile is specified in the dynamically-generated enrollment
page.
The authentication process is simple.
1. An end entity submits a request for enrollment. The form used to submit the request identifies
the method of authentication and enrollment. All HTML forms are dynamically-generated by the
profiles, which automatically associate the appropriate authentication method with the form.
2. If the authentication method is an agent-approved enrollment, the request is sent to the request
queue of the CA agent. If the automated notification for a request in queue is set, an email is sent
to the appropriate agent that a new request has been received. The agent can modify the request
as allowed for that form and the profile constraints. Once approved, the request must pass the
certificate profiles set for the Certificate Manager, and then the certificate is issued. When the
certificate is issued, it is stored in the internal database and can be retrieved by the end entity from
the end-entities page by serial number or by request ID.
3. If the authentication method is automated, the end entity submits the request along with required
information to authenticate the user, such as an LDAP username and password. When the user
is successfully authenticated, the request is processed without being sent to an agent's queue. If
the request passes the certificate profile configuration of the Certificate Manager, the certificate is
issued and stored in the internal database. It is delivered to the end entity immediately through the
HTML forms.
The requirements for how a certificate request is authenticated can have a direct impact on the
necessary subsystems and profile settings. For example, if an agent-approved enrollment requires
that an agent meet the requester in person and verify their identity through supported documentation,
the authentication process can be time-intensive, as well as constrained by the physical availability
of both the agent and the requester. In that case, having numerous local RAs may be preferable to
centralized CAs.

5.4.8. Publishing Certificates and CRLs

A CA can publish both certificates and CRLs. Certificates can be published to a plain file or to
an LDAP directory; CRLs can be published to file or an LDAP directory, as well, and can also be
published to an OCSP responder to handle certificate verification.
Configuring publishing is fairly straightforward and is easily adjusted. For continuity and accessibility,
though, it is good to plan out where certificates and CRLs need to be published and what clients need
to be able to access them.
Publishing to an LDAP directory requires special configuration in the directory for publishing to work:
Publishing Certificates and CRLs
73