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:
[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.
This file looks like the following:
[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.
I then did a pkidestroy on the previous KRA installed with the interactive method.
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.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.