此内容没有您所选择的语言版本。

10.7. Converting Masters and Clones


Only one single active CA generating CRLs can exist within the same topology. Similarly, only one OCSP receiving CRLs can exist within the same topology. As such, there can be any number of clones, but there can only be a single configured master for CA and OCSP.
For KRAs and TKSs, there is no configuration difference between masters and clones, but CAs and OCSPs do have some configuration differences. This means that when a master is taken offline — because of a failure or for maintenance or to change the function of the subsystem in the PKI — then the existing master must be reconfigured to be a clone, and one of the clones promoted to be the master.

10.7.1. Converting CA Clones and Masters

  1. Stop the master CA if it is still running.
  2. Open the existing master CA configuration directory:
    # cd /var/lib/pki/instance_name/ca/conf
  3. Edit the CS.cfg file for the master, and change the CRL and maintenance thread settings so that it is set as a clone:
    • Disable control of the database maintenance thread:
      ca.certStatusUpdateInterval=0
    • Disable monitoring database replication changes:
      ca.listenToCloneModifications=false
    • Disable maintenance of the CRL cache:
      ca.crl.IssuingPointId.enableCRLCache=false
    • Disable CRL generation:
      ca.crl.IssuingPointId.enableCRLUpdates=false
    • Set the CA to redirect CRL requests to the new master:
      master.ca.agent.host=new_master_hostname
      master.ca.agent.port=new_master_port
  4. Stop the cloned CA server.
    # systemctl stop pki-tomcatd@instance_name.service
  5. Open the cloned CA's configuration directory.
    # cd /etc/instance_name
  6. Edit the CS.cfg file to configure the clone as the new master.
    1. Delete each line which begins with the ca.crl. prefix.
    2. Copy each line beginning with the ca.crl. prefix from the former master CA CS.cfg file into the cloned CA's CS.cfg file.
    3. Enable control of the database maintenance thread; the default value for a master CA is 600.
      ca.certStatusUpdateInterval=600
    4. Enable monitoring database replication:
      ca.listenToCloneModifications=true
    5. Enable maintenance of the CRL cache:
      ca.crl.IssuingPointId.enableCRLCache=true
    6. Enable CRL generation:
      ca.crl.IssuingPointId.enableCRLUpdates=true
    7. Disable the redirect settings for CRL generation requests:
      master.ca.agent.host=hostname
      master.ca.agent.port=port number
  7. Start the new master CA server.
    # systemctl start pki-tomcatd@instance_name.service

10.7.2. Converting OCSP Clones

  1. Stop the OCSP master, if it is still running.
  2. Open the existing master OCSP configuration directory.
    # cd /etc/instance_name
  3. Edit the CS.cfg, and reset the OCSP.Responder.store.defStore.refreshInSec parameter to 21600:
    OCSP.Responder.store.defStore.refreshInSec=21600
  4. Stop the online cloned OCSP server.
    # systemctl stop pki-tomcatd@instance_name.service
  5. Open the cloned OCSP responder's configuration directory.
    # cd /etc/instance_name
  6. Open the CS.cfg file, and delete the OCSP.Responder.store.defStore.refreshInSec parameter or change its value to any non-zero number:
    OCSP.Responder.store.defStore.refreshInSec=15000
  7. Start the new master OCSP responder server.
    # systemctl start pki-tomcatd@instance_name.service
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.