Show Table of Contents
6.5. Managing Server Roles
Based on the services installed on an IdM server, it can perform various server roles. For example: CA server, DNS server, or key recovery authority (KRA) server.
6.5.1. Viewing Server Roles
Web UI: Viewing Server Roles
For a complete list of the supported server roles, see → → .
- Role status absent means that no server in the topology is performing the role.
- Role status enabled means that one or more servers in the topology are performing the role.
Figure 6.14. Server Roles in the Web UI
Command Line: Viewing Server Roles
The
ipa config-show command displays all CA servers, NTP servers, and the current CA renewal master:
$ ipa config-show ... IPA masters: server1.example.com, server2.example.com, server3.example.com IPA CA servers: server1.example.com, server2.example.com IPA NTP servers: server1.example.com, server2.example.com, server3.example.com IPA CA renewal master: server1.example.com
The
ipa server-show command displays a list of roles enabled on a particular server. For example, for a list of roles enabled on server.example.com:
$ ipa server-show
Server name: server.example.com
...
Enabled server roles: CA server, DNS server, NTP server, KRA server
The
ipa server-find --servrole searches for all servers with a particular server role enabled. For example, to search for all CA servers:
$ ipa server-find --servrole "CA server" --------------------- 2 IPA servers matched --------------------- Server name: server1.example.com ... Server name: server2.example.com ... ---------------------------- Number of entries returned 2 ----------------------------
6.5.2. Promoting a Replica to a Master CA Server
Note
This section describes changing the CA renewal master at domain level 1 (see Chapter 7, Displaying and Raising the Domain Level). For documentation on changing the CA renewal master at domain level 0, see Section D.4, “Promoting a Replica to a Master CA Server”.
In a topology that includes multiple replicas, one of them acts as the master CA server: it manages the renewal of CA subsystem certificates and generates certificate revocation lists (CRLs). By default, the master CA is the initial server from which replicas were created.
If you plan to take the master CA server offline or decommission it, promote another CA server to take the its place as the new CA renewal master:
- Configure the replica to handle CA subsystem certificate renewal.
- See Section 6.5.2.1, “Changing the Current CA Renewal Master” for domain level 1.
- See Section D.4.1, “Changing Which Server Handles Certificate Renewal” for domain level 0.
- Configure the replica to generate CRLs. See Section 6.5.2.2, “Changing Which Server Generates CRLs”.
- Before decommissioning the previous master CA server, make sure the new master works properly. See Section 6.5.2.3, “Verifying That the New Master CA Server Is Configured Correctly”.
6.5.2.1. Changing the Current CA Renewal Master
Web UI: Changing the Current CA Renewal Master
- Select → .
- In the IPA CA renewal master field, select the new CA renewal master.
Command Line: Changing the Current CA Renewal Master
Use the
ipa config-mod --ca-renewal-master-server command:
$ ipa config-mod --ca-renewal-master-server new_ca_renewal_master.example.com
...
IPA masters: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA CA servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA NTP servers: old_ca_renewal_master.example.com, new_ca_renewal_master.example.com
IPA CA renewal master: new_ca_renewal_master.example.com
The output confirms that the update was successful.
6.5.2.2. Changing Which Server Generates CRLs
To change which server generates CRLs, stop CRL generation on the current CRL generation master, and then enable it on the other server.
Identifying the Current CRL Generation Master
Examine the
/etc/pki/pki-tomcat/ca/CS.cfg file on each server with a CA installed:
- On the CRL generation master, the
ca.crl.MasterCRL.enableCRLUpdatesparameter is set totrue:# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true - On CRL generation clones, the parameter is set to
false.
Stopping CRL Generation on the Current CRL Generation Master
- Stop the CA service:
# systemctl stop pki-tomcatd@pki-tomcat.service
- Disable CRL generation on the server. Open the
/etc/pki/pki-tomcat/ca/CS.cfgfile, and set the values of theca.crl.MasterCRL.enableCRLCacheandca.crl.MasterCRL.enableCRLUpdatesparameters tofalse:ca.crl.MasterCRL.enableCRLCache=
falseca.crl.MasterCRL.enableCRLUpdates=false - Start the CA service:
# systemctl start pki-tomcatd@pki-tomcat.service
- Configure Apache to redirect CRL requests to the new master. Open the
/etc/httpd/conf.d/ipa-pki-proxy.conffile, and uncomment theRewriteRuleargument:# Only enable this on servers that are not generating a CRL RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
- Restart Apache:
# systemctl restart httpd.service
Before, this server responded to CRL requests. Now, all CRL requests are routed to the previous CA master.
Configure a Server to Generate CRLs
- Stop the CA service:
# systemctl stop pki-tomcatd@pki-tomcat.service
- Enable CRL generation on the server. Set the values of the
ca.crl.MasterCRL.enableCRLCacheandca.crl.MasterCRL.enableCRLUpdatesparameters totrue:ca.crl.MasterCRL.enableCRLCache=true ca.crl.MasterCRL.enableCRLUpdates=true
- Start the CA service:
# systemctl start pki-tomcatd@pki-tomcat.service
- Configure Apache to disable redirecting CRL requests. Open the
/etc/httpd/conf.d/ipa-pki-proxy.conffile, and comment out theRewriteRuleargument:#RewriteRule ^/ipa/crl/MasterCRL.bin https://server.example.com/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]Before, all CRL requests were routed to the previous CA master. Now, this server will respond to CRL requests. - Restart Apache:
# systemctl restart httpd.service
6.5.2.3. Verifying That the New Master CA Server Is Configured Correctly
Make sure the
/var/lib/ipa/pki-ca/publish/MasterCRL.bin file exists on the new master CA server.
The file is generated based on the time interval defined in the
/etc/pki/pki-tomcat/ca/CS.cfg file using the ca.crl.MasterCRL.autoUpdateInterval parameter. The default value is 240 minutes (4 hours).
If the file exists, the new master CA server is configured correctly, and you can safely dismiss the previous CA master system.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.