[Pki-devel] Dogtag 10.0.2 'pki-core' packages test scenarios

The following test scenarios have been run successfully on Dogtag 10.0.2: * Default installation and REST configuration of CA, KRA, OCSP, and TKS instances within a single Tomcat 7 PKI instance: o *pkispawn -s CA -f ca.cfg* + where 'ca.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX o *pkispawn -s KRA -f kra.cfg* + where 'kra.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX o *pkispawn -s OCSP -f ocsp.cfg* + where 'ocsp.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX o *pkispawn -s TKS -f tks.cfg* + where 'tks.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX Since a TKS must remain FIPS-compliant, the following post-configuration steps are also necessary: * # cat /var/lib/pki/pki-tomcat/conf/password.conf** ** # tkstool -T -d /var/lib/pki/pki-tomcat/alias -n sharedSecret** ** # stty sane** ** #/bin/systemctl restart pki-tomcatd(a)pki-tomcat.service* * Default installation and legacy GUI browser configuration of CA, KRA, OCSP, and TKS instances within separate Tomcat 7 PKI instances: o *pkispawn -s CA -f ca.cfg* + where 'ca.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX pki_skip_configuration=True o CA instance is configured via the legacy GUI browser configuration For a CA instance which has been configured via the legacy GUI browser interface, the following post-configuration steps are necessary: *# /bin/systemctl restart pki-tomcatd(a)pki-tomcat.service* o *pkispawn -s KRA -f kra.cfg* + where 'kra.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_http_port=28080 pki_https_port=28443 pki_instance_name=pki-tomcat-kra pki_security_domain_password=XXXXXXXX pki_skip_configuration=True [Tomcat] pki_ajp_port=28009 pki_tomcat_server_port=28005 [KRA] pki_import_admin_cert=False o KRA instance is configured via the legacy GUI browser configuration For a KRA instance which has been configured via the legacy GUI browser interface, the following post-configuration steps are necessary: *# /bin/systemctl restart pki-tomcatd(a)pki-tomcat-kra.service* o *pkispawn -s OCSP -f ocsp.cfg* + where 'ocsp.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_http_port=29080 pki_https_port=29443 pki_instance_name=pki-tomcat-ocsp pki_security_domain_password=XXXXXXXX pki_skip_configuration=True [Tomcat] pki_ajp_port=29009 pki_tomcat_server_port=29005 [OCSP] pki_import_admin_cert=False o OCSP instance is configured via the legacy GUI browser configuration For an OCSP instance which has been configured via the legacy GUI browser interface, the following post-configuration steps are necessary: *# /bin/systemctl restart pki-tomcatd(a)pki-tomcat-ocsp.service* Additionally, whenever an OCSP instance is installed as a standalone PKI Tomcat instance that is separate from the CA instance, the CA instance needs to reset publishing in the CA so that the OCSP will obtain the updates. Therefore, the following additional post-configuration steps are necessary (restart the CA): *# /bin/systemctl restart pki-tomcatd(a)pki-tomcat.service* By default, since the REST configuration process restarts the PKI Tomcat instance at the end of its configuration, both the CA instance and the OCSP instance will be restarted since they are the same instance. o *pkispawn -s TKS -f tks.cfg* + where 'tks.cfg' contains: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_database_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_http_port=30080 pki_https_port=30443 pki_instance_name=pki-tomcat-tks pki_security_domain_password=XXXXXXXX pki_skip_configuration=True [Tomcat] pki_ajp_port=30009 pki_tomcat_server_port=30005 [TKS] pki_import_admin_cert=False o TKS instance is configured via the legacy GUI browser configuration For a TKS instance which has been configured via the legacy GUI browser interface, the following post-configuration steps are necessary: *# /bin/systemctl restart pki-tomcatd(a)pki-tomcat-tks.service* Additionally, since a TKS must remain FIPS-compliant, the following post-configuration steps are also necessary: * # cat /var/lib/pki/pki-tomcat-tks/conf/password.conf** ** # tkstool -T -d /var/lib/pki/pki-tomcat-tks/alias -n sharedSecret** ** # stty sane** ** #/bin/systemctl restart pki-tomcatd(a)pki-tomcat-tks.service* ADDITIONAL TEST NOTES for legacy GUI browser configurations: * For KRA, OCSP, and TKS, the 'pki_import_admin_cert=False' parameter was specified so that a single browser profile could be utilized to configure and test all four PKI subsystems (CA, KRA, OCSP, and TKS) * When selecting ports for KRA, OCSP, and TKS, it was discovered that an SELinux conflict occurred if ports were selected higher than 32768 since these are of type 'ephemeral_port_t' and cannot be re-labeled without an additional procedure: *# semanage -l port | grep ephemeral* ephemeral_port_t tcp 32768-61000 ephemeral_port_t udp 32768-61000 * When configuring the KRA, OCSP, and TKS, in order to obtain the CA security domain URL required by the 'Join an Existing Security Domain' option on the 'Security Domain' panel, the following command was utilized: *# pkidaemon status tomcat pki-tomcat* * Unlike the default 'pki_security_domain_user=caadmin' utilized by the REST configuration, the KRA, OCSP, and TKS legacy GUI browser configurations utilized 'admin' rather than 'caadmin' as the 'Uid:' entry on the 'Security Domain (<DNS Domain> Domain) Login' panel. * For convenience, when configuring the CA, KRA, OCSP, and TKS the 'Remove the existing data from the Base DN shown above.' checkbox option was checked on the 'Internal Database' panel.