Certificate Authority
Red Hat Certificate System (RH...
Install Red Hat Certificate System and deploy the subsystem
9 min
this tutorial walks system administrators through installing red hat certificate system (rhcs), configuring selinux for hsm integration, preparing a pkispawn override file, deploying a ca subsystem, and importing the administrator certificate it also includes browser configuration for access install rhcs perform the following steps to install red hat certificate system and prerequisites rhcs requires red hat directory server (rhds) , which serves as an internal repository for certificate requests, certificates, and so on enable the rhcs and rhds repositories with the following command subscription manager repos \\ \ enable=certsys 10 8 for rhel 8 x86 64 rpms \\ \ enable=dirsrv 11 for rhel 8 x86 64 rpms install the directory server packages sudo dnf module install redhat ds 11 run the directory server configuration script sudo dscreate interactive enable specific versions of the maven and pki deps modules to support successful redhat pki installation in the next step sudo dnf module enable y maven 3 8 pki deps 10 6 refresh the dnf cache sudo dnf clean all sudo rm rf /var/cache/dnf/ sudo dnf makecache install the certificate system packages sudo dnf install redhat pki modify selinux to enable hsm communication while selinux is enforcing, perform these steps reset the context for the futurex pkcs #11 library sudo semanage fcontext a t lib t '/usr/lib/fxpkcs11(/ )?' apply the context changes sudo restorecon rfv /usr/lib64/fxpkcs11 set the context for the configuration file sudo semanage fcontext a t etc t '/etc/fxpkcs11 cfg' apply the context to the configuration file sudo restorecon v /etc/fxpkcs11 cfg create a ca subsystem instance the pkispawn command line tool installs and configures a new pki instance it eliminates the need for separate installation and configuration steps, and you can run it interactively, as a batch process, or as a combination of both (batch process with prompts for passwords) refer to the pkispawn man page for detailed information about all supported options by running man pkispawn the pkispawn command reads in its default installation and configuration values from a plain text configuration file ( /etc/pki/default cfg ) this file consists of name=value pairs divided into \[default] , \[tomcat] , \[ca] , \[kra] , \[ocsp] , \[tks] , and \[tps] sections we strongly recommend that you read the full documentation to understand the purpose of every parameter in the /etc/pki/default cfg file this enables you to customize your pki environment to your specific needs the red hat recommended procedure for spawning a subsystem that uses an hsm is to create an override configuration file that contains only the parameters necessary for using the hsm as its token any parameter settings in this file override the parameter settings in the default cfg file you can spawn any rhcs subsystems ( ca , kra , ocsp , tks , tps ) to use the hsm, but this integration guide focuses on the certificate authority ( ca ) for brevity prepare an override configuration file create an override configuration file to specify hsm parameters for the ca subsystem create the override file sudo vi default futurex txt populate the file with the following template set the pki instance name , pki token password , and pki security domain name values to your specific values keep all other values unchanged you must define the password of the identity you created on the {{vectera}} in the pki token password parameter \[default] pki instance name=\<instance name> pki http port=8080 pki https port=8443 \# admin & client credentials pki admin email=caadmin\@example com pki admin name=caadmin \# security domain (first ca or joining an existing one) pki security domain name=\<security domain name> pki security domain https port=8443 \# 389 ds pki ds url=ldap\ //127 0 0 1 389 pki ds database=userroot pki ds bind dn=cn=directory manager \# hsm (pkcs#11) pki hsm enable=true pki hsm libfile=/usr/lib64/fxpkcs11/libfxpkcs11 so pki hsm modulename=fxpkcs11 pki token name=futurex pki token password=\<hsm user pin> \[ca] pki audit signing token=futurex pki ca signing token=futurex pki ocsp signing token=futurex pki sslserver token=futurex pki subsystem token=futurex run the pkispawn utility perform the following steps to run the pkispawn utility deploy the ca subsystem with the {{vectera}} using your override configuration sudo pkispawn s ca f default futurex txt debug if the deployment succeeds, an installation summary similar to the following displays after the command completes ============================================================= installation summary \============================================================= administrator's username caadmin administrator's pkcs #12 file /root/ dogtag/pki tomcat/ca admin cert p12 to check the status of the subsystem systemctl status pki tomcatd\@pki tomcat service to restart the subsystem systemctl restart pki tomcatd\@pki tomcat service the url for the subsystem is https //localhost localdomain 8443/ca pki instances will be enabled upon system boot \============================================================= validation after successful deployment, verify the following the ca subsystem service is active systemctl status pki tomcatd\@pki tomcat service the certificate file exists at /root/ dogtag/pki tomcat/ca admin cert p12 the ca web interface is accessible https //\<hostname> 8443/ca import the pkcs #12 file import the ca administrator certificate into your browser to authenticate in firefox, go to settings > privacy & security > certificates and select \[ view certificates ] under the your certificates tab, select \[ import ] to load the ca administrator pkcs #12 file ( ca admin cert p12 ) enter the pki client pkcs12 password you set during the ca subsystem deployment access the ca subsystem access the ca web interface and submit certificate signing requests open your browser and navigate to https //localhost localdomain 8443/ca when submitting certificate signing requests (csrs) in rhcs, the common name and uid fields are both required if you submit a request with only the common name field, the request fails, and you receive an error stating that the subject name does not match next steps for detailed csr submission guidance, see https //access redhat com/documentation/en us/red hat certificate system/10/html/administration guide/index