#668 TPS configuration does not allow strong passwords
Closed: Invalid Opened by nkinder.

When configuring TPS, the use of special characters such as { } ! * $ @ + cause
configuration of TPS to break. This is especially for netHSM login, nss db
login, or linking to the internal directory.

Steps to Reproduce:
1. Run pkicreate for tps subsystem
2. When running through web configuration, supply complex passwords using
special characters as mentioned above.

Actual results:
- Configuration fails


Proposed Milestone: 10.2.2 (per CS Meeting of 09/17/2014)

Verify that this is fixed and close.

Per 10.2.2 Triage meeting of 02/24/2015: 10.2.2

KRA, OCSP, TKS and TPS configuration fails when pki_security_domain_password parameter in the config file has special characters as follows

pki_security_domain_password={&+$@*!

The following is the error thrown during pkispawn:

Loading deployment configuration from /tmp/tmp.50jtZO0e72/tmpconfigfile8.in.
Traceback (most recent call last):
File "/usr/sbin/pkispawn", line 579, in
main(sys.argv)
File "/usr/sbin/pkispawn", line 484, in main
parser.sd_authenticate()
File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 480, in sd_authenticate
account.login()
File "/usr/lib/python2.7/site-packages/pki/init.py", line 297, in handler
clazz = exc.response.json()['ClassName']
File "/usr/lib/python2.7/site-packages/requests/models.py", line 604, in json
return json.loads(self.text or self.content)
File "/usr/lib64/python2.7/json/init.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

OK:

I've been looking at this today myself and came up with different results, using some different passwords with special chars.

Here is the cfg file I used to create the original CA:

[DEFAULT]
pki_instance_name = pki-tomcat

[CA]
pki_http_port = 8080
pki_https_port = 8443
pki_ajp_port = 8009
pki_tomcat_server_port = 8005
pki_admin_uid = caadmin
pki_admin_password = netscape!+*
pki_backup_password = netscape!+^
pki_client_database_password = netscape!+@
pki_client_pkcs12_password = netscape!+#
pki_import_admin_cert = False
pki_client_admin_cert = /root/.dogtag/pki-tomcat/ca_admin.cert
pki_ds_hostname = localhost.localdomain
pki_ds_ldap_port = 389
pki_ds_bind_dn = cn=Directory Manager
pki_ds_password = netscape!+
pki_ds_base_dn = o=pki-tomcat-CA
pki_security_domain_name = localdomain Security Domain
pki_client_pin = netscape!+{
pki_clone_pkcs12_password = netscape!+-
pki_one_time_pin = netscape!+|
pki_pin = netscape!+<
pki_security_domain_password = netscape!+>
pki_token_password = netscape!+&

Note ever password has some variation of special chars at the end of the string:

This install worked just fine.

Then I proceeded to use the ineractive method to install the KRA, and TKS. I used the appropriate password values out of the original cfg file as needed. All of these subsystems installed just fine.

Then finally I created another TPS.cfg file to automatically install a TPS, using corresponding passwords culled from the original file as follows:

[DEFAULT]
pki_admin_password=netscape!+
pki_client_database_password=netscape!+@
pki_client_pkcs12_password=netscape!+#
pki_ds_password=netscape!+
pki_security_domain_password=netscape!+

[TPS]
pki_enable_server_side_keygen=True
pki_authdb_basedn=ou=People,dc=localdomain

Note that the pki_admin_password value has a bunch of special chars in it.

Perhaps rpattath has managed to use a certain character the system does not like or combination of characters. I will attempt to use the one she has flagged and see what happens.

If there is indeed an issue, it will be for all subsystems. Since the TPS is now installed by pkispawn , it has no special tendency to have this issue over any of the other subsystems.

I tried the whole thing again using the offending password from above
{&+$@*!

This time I was able to install a KRA using interactive method using that password for the security domain.

Then I tried to come up with a kra.cfg to use the other method. This attempt failed for some reason. It is not 100% sure the password is at fault, it could be a misconfiguration in the config file or some other anomaly. Will have to investigate further.

Quickly over lunch, made one more test:

  1. Installed the CA with auto method cfg file here:

[DEFAULT]
pki_instance_name = pki-tomcat

[CA]
pki_http_port = 8080
pki_https_port = 8443
pki_ajp_port = 8009
pki_tomcat_server_port = 8005
pki_admin_uid = caadmin
pki_admin_password = {&+$@!
pki_backup_password = netscape!+^
pki_client_database_password = netscape!+@
pki_client_pkcs12_password = netscape!+#
pki_import_admin_cert = False
pki_client_admin_cert = /root/.dogtag/pki-tomcat/ca_admin.cert
pki_ds_hostname = localhost.localdomain
pki_ds_ldap_port = 389
pki_ds_bind_dn = cn=Directory Manager
pki_ds_password = netscape!+
pki_ds_base_dn = o=pki-tomcat-CA
pki_security_domain_name = localdomain Security Domain
pki_client_pin = netscape!+{
pki_clone_pkcs12_password = netscape!+-
pki_one_time_pin = netscape!+|
pki_pin = netscape!+<
pki_security_domain_password = {&+$@
!
pki_token_password = netscape!+&

This installed fine.

  1. Installed a KRA with the interactive method. This time I modifed the python code to write out all the password into the deployment.cfg file it generates before actually doing the install.

This file looks like the following:

[DEFAULT]
pki_instance_name = pki-tomcat

[KRA]
pki_http_port = 8080
pki_https_port = 8443
pki_ajp_port = 8009
pki_tomcat_server_port = 8005
pki_admin_uid = kraadmin
pki_admin_password = {&+$@!
pki_backup_password = {&+$@
!
pki_client_database_password = {&+$@!
pki_client_pkcs12_password = {&+$@
!
pki_import_admin_cert = True
pki_admin_cert_file = /root/.dogtag/pki-tomcat/ca_admin.cert
pki_client_admin_cert = /root/.dogtag/pki-tomcat/kra_admin.cert
pki_ds_hostname = localhost.localdomain
pki_ds_ldap_port = 389
pki_ds_bind_dn = cn=Directory Manager
pki_ds_password = netscape!+
pki_ds_base_dn = o=pki-tomcat-KRA
pki_security_domain_hostname = localhost.localdomain
pki_security_domain_https_port = 8443
pki_security_domain_name = localdomain Security Domain
pki_security_domain_user = caadmin
pki_security_domain_password = {&+$@*!

Note all instances of the offending pword "{&+@*!". I chose this as the kraadmin pword and the installer must use that for a bunch of other passwords.

  1. I then did a pkidestroy on the previous KRA installed with the interactive method.

  2. Then I took that exact generated cfg file and ran it through pkispawn as follows:

    pkispawn -f ./kra.cfg -s KRA -vvvvvvvvvvvvvvvvvvvvv

The result was a correct install, with the final output below:

'sensitive_parameters': '\npki_admin_password\npki_backup_password\npki_client_database_password\npki_client_pin\npki_client_pkcs12_password\npki_clone_pkcs12_password\npki_ds_password\npki_one_time_pin\npki_pin\npki_security_domain_password\npki_token_password',
'spawn_scriplets': '\ninitialization\ninfrastructure_layout\ninstance_layout\nsubsystem_layout\nselinux_setup\nwebapp_deployment\nslot_substitution\nsecurity_databases\nconfiguration\nfinalization'}

==========================================================================
                            INSTALLATION SUMMARY
==========================================================================
  Administrator's username:             kraadmin
  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/kra
==========================================================================

Conclusion:

I think the password thing is probably a non issue. What we have here are a few cases where either a) We have provided incorrect data in the cfg files for the kra, or b) There is some issue in the installer when everything in the cfg is not perfectly set up. Therefore, we could close this, and keep an eye out for the rest.

Closing as works for me. QA can try the sample script I provided above.

Metadata Update from @nkinder:
- Issue assigned to jmagne
- Issue set to the milestone: 10.2.2

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1238

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata