[Pki-devel] Dogtag 10.0.2 'pki-core' packages test scenarios
Matthew Harmsen
mharmsen at redhat.com
Wed May 1 03:38:10 UTC 2013
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20130430/59b6f0e2/attachment.htm>
More information about the Pki-devel
mailing list