Cloning A Ca - Red Hat CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR Administrator's Manual

Hide thumbs Also See for CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR:
Table of Contents

Advertisement

Cloning a CA

CS also provides a publishing mapper for CA certificates that can be used for publishing
cross-pair certificates,
, designating which LDAP entry should be used to store the
LDAPCA
. A publisher,
, is also set up
crossCertificatePair
LDAPCrossPairPublisher
specifying the attribute used to store the cross-pair certificate in the CA entry. This is set to
.
crossCertificatePair;binary
See Chapter 16, "Publishing" for more information about publishing.
Cloning a CA
Cloning a Certificate Manager is the process of creating two server processes performing
the same CA functions: you create another instance of a Certificate Manager and configure
it to use the same CA signing key and certificate to issue certificates with serial numbers
that do not conflict or overlap with the serial numbers of the Certificate Manager that's
being cloned.
You can use the cloning feature for CA scalability and for setting up a PKI with CAs
organized in a flat structure as opposed to a hierarchical structure. For example, if you don't
want your PKI to be a CA hierarchy comprising root and subordinate CAs, you can clone
the Certificate Manager and configure the clone to issue certificates that fall within a
distinct range of serial numbers. Because clone CAs and original CAs use the same CA
signing key and certificate to sign the certificates they issue, the issuer name in all the
certificates in such a setup will be the same. Clone CAs and the Certificate Managers they
clone issue certificates as if they are a single CA, and can be placed on different hosts for
high availability failover support.
When you setup a Certificate Manager clone, the clone and the original share the the
revocation status of the certificates they have issued. Though the clone CA cannot generate
the CRL itself, it can revoke certificates, display, import, and download previously
generated CRL lists. This is because data sources for the cloned systems are replicated, so
that the data is shared seemlessly between subsystem databases. See Appendix , " for
information on how to set up cloned instances replication between the cloned databases.
If you enable the OCSP-service feature built into the Certificate Manager, it can function as
a full-fledged OCSP responder for your PKI. Like the CA itself, the OCSP responder can be
cloned.
OCSP-compliant clients can query the Certificate Manager for the revocation status of any
certificate, whether that certificate was generated by the original CA or a clone, and
whether the OCSP responder is itself an originals or a clone. See "Cloning the Online
Certificate Status Manager" on page 662 for information about cloning the OCSP
Responder.
Chapter 3
Certificate Manager
127

Advertisement

Table of Contents
loading

This manual is also suitable for:

Certificate system 7.1 - adminsistrator

Table of Contents