PKI Known Issues
Contents
Known Issues: Problems and Solutions
Directory Server
Problem: I tried to yum install fedora-ds-base on Fedora 8, but I'm getting "Transaction Check Error" with lots of "conflicts with file" errors for the perl-5.8.8-30.fc8 package.
Solution: On Fedora 8, the default perl package is of version 5.8.8-30, while fedora-ds-base attempts to install . In order to address this issue, do the following:
yum update perl
and then
yum install fedora-ds-base
PKI Subsystem Installation
Problem: I attempted to install a pki-ca, but encountered the following error:
PKI instance creation completed ...
Starting pki-ca1: /usr/bin/rebuild-jar-repository: error: Could not find servlet
Java extension for this JVM
/usr/bin/rebuild-jar-repository: error: Some detected jars were not found for
this jvm
[ OK ]
.
.
.
Solution: A detailed example of this type of error is explained in Bugzilla Bug #440178. Examine the log file called "/var/lib/<pki instance name>/logs/catalina.out". If it contains the line "java.lang.NoClassDefFoundError: javax/servlet/http/HttpServletRequest", attempt to add the following symbolic link, remove, and reinstall the instance:
ln -s /etc/alternatives/servlet /usr/share/java/servlet.jar
Problem: On both 32-bit and 64-bit Fedora 10, when I attempted to install pki-ra and pki-tps, both subsystems failed to start!
Solution: On some versions of Fedora 10, the file "/etc/init.d/functions" has the improper non-executable file permissions of 00644 (-rw-r--r--); become 'root' or have your system administrator change the permissions of this file to be an executable value of 00755 (-rwxr-xr-x).
chmod 00755 /etc/init.d/functions
| NOTE: | During the port to Fedora 11, the source code has been corrected to fix this issue as documented in Bugzilla Bug #519259 - Change "[ -x /etc/init.d/functions]" to "[ -f /etc/init.d/functions]" . . . . However, this work-around may still be required on certain versions of Fedora 10 if the pre-built binaries are utilized. |
Problem: While attempting to install 'pki-ra' on RHEL 5.2, I am getting the following messages thru yum:
Error: Missing Dependency: perl(version) is needed by package perl-Parse-RecDescent Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by package perl-DBD-SQLite
Solution: These packages are not available in RHEL 5.2. For now, obtain the following packages (e. g. - Fedora 9), and install them on the RHEL 5.2 system:
perl-DBD-SQLite-1.14-7.fc9.i386.rpm (32-bit) OR perl-DBD-SQLite-1.14-7.fc9.x86_64.rpm (64-bit) perl-Parse-RecDescent-1.96-1.fc9.noarch.rpm
Problem: While attempting to install 'pki-ra' EPEL package on RHEL 5.5, I am getting the following messages thru yum:
Error: mod_nss >= 1.0.7 is needed by pki-ra-1.3.1-1.el5.noarch
Solution: Per Bugzilla Bug #529164 - mod_nss certificate database generated., Bugzilla Bug #533092 - mod_nss rfe - "Dynamic CRL Loading", and Bugzilla Bug #563874 - mod_nss - "Dynamic CRL Loading", the 'mod_nss' 1.0.8 package is not scheduled to be available until RHEL 5.6. For convenience, a copy of this package may be obtained from this website (see obtaining a copy of mod_nss-1.0.8-2.el5idm.<arch>.rpm for RHEL 5.5).
Problem: While attempting to install 'pki-tps' EPEL package on RHEL 5.5, I am getting the following messages thru yum:
Error: mod_nss >= 1.0.7 is needed by pki-tps-1.3.1-1.el5.i686 (32-bit) OR Error: mod_nss >= 1.0.7 is needed by pki-tps-1.3.1-1.el5.x86_64 (64-bit)
Solution: Per Bugzilla Bug #529164 - mod_nss certificate database generated., Bugzilla Bug #533092 - mod_nss rfe - "Dynamic CRL Loading", and Bugzilla Bug #563874 - mod_nss - "Dynamic CRL Loading", the 'mod_nss' 1.0.8 package is not scheduled to be available until RHEL 5.6. For convenience, a copy of this package may be obtained from this website (see obtaining a copy of mod_nss-1.0.8-2.el5idm.<arch>.rpm for RHEL 5.5).
PKI Subsystem Configuration
Problem: Help! I keep having problems configuring new PKI instances, and I didn't have these problems during the first several installations!
Solution: You may be a victim of certificate collisions resulting from use of the same nickname/serial number. While it is often convenient and desirable to use the same profile for a single PKI installation involving numerous subsystems, it is generally recommended to try using a new Firefox browser profile when first creating a completely new PKI solution:
/usr/bin/firefox -ProfileManager -no-remote
Problem: I attempted to configure a pki-ca instance, but I noticed the uninitialized variable $https_port was present on the second screen when attempting to create a new Security Domain (see Bugzilla Bug #441974). Additionally, the file /var/log/pki-ca/debug contained the following stack trace:
[16/Apr/2008:12:01:47][main]: CMS:Caught EBaseException
Failed to create jss service: org.mozilla.jss.CryptoManager$NotInitializedException
at com.netscape.cmscore.security.JssSubsystem.init(JssSubsystem.java:252)
at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:732)
at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:661)
at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:276)
at com.netscape.certsrv.apps.CMS.init(CMS.java:152)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1490)
at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:78)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:966)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3956)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4230)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:926)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:889)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:448)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:623)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Solution: A detailed example of this type of error is explained in Bugzilla Bug #441974. The tomcat-native performance RPM is known to conflict with the Dogtag PKI security model, and cannot co-exist. To run Dogtag, all versions of this RPM must be removed:
rpm -ev tomcat-native.i386 rpm -ev tomcat-native.x86_64
Problem: I was unable to configure a pki-ca instance, and I do NOT have any tomcat-native packages installed (see Bugzilla Bug #441974).
Solution: In the file called /etc/sysconfig/i18n, try changing LANG to "C".
Problem: Using separate browser profiles, I was able to successfully install and configure a Subordinate CA that contains its own security domain and is signed by the Root CA. However, after I successfully performed a restart, I received an HTTP Status 500 error when attempting to go to the Services page.
Solution: During configuration, make certain that you have named the security domain of the Subordinate CA to something different than the name of the security domain used during configuration of the Root CA. The most common cause of this error is simply using the default text for the name of the security domain for both the Root and Subordinate CA.
PKI Subsystem Execution
Problem: I was able to successfully install and configure a Subordinate CA that contains its own security domain and is signed by the Root CA. However, after I successfully performed a restart, I received an HTTP Status 500 error when attempting to go to the Services page.
Solution: During configuration, make certain that you have named the security domain of the Subordinate CA to something different than the name of the security domain used during configuration of the Root CA. The most common cause of this error is simply using the default text for the name of the security domain for both the Root and Subordinate CA.
Problem: I was able to successfully install and configure a pki-ca instance, and was able to display the Services page as well as the End Entity Page. However, when I attempted to go to the Agent page, I received the following error in a pop-up dialog:
Alert Could not establish an encrypted connection because your certificate was rejected by <machine_name.domain_name>. Error Code: -12271.
Solution: Although it is ALWAYS mentioned in the final panel of the configuration process, you more than likely forgot to restart the PKI instance AFTER you completed the configuration process (e. g. - /sbin/service pki-ca restart). The process fails because it is still attempting to use the boot-strap certificate used during configuration. Note that this message may be displayed by any PKI subsystem instance. If you are still unable to access the Agent page after restarting the service, attempt to "clear all of the private data" in your browser, and if that fails, simply try to shutdown and restart your browser.
Problem: Using the same browser profile, I was able to successfully install and configure multiple PKI subsystems. However, when I went to the agent page of a particular PKI subsystem, I received the following error:
Problem Processing Your Request
--------------------------------------------------------------------------------------------------------------------------------------------------------
The Certificate Manager encountered an unexpected error while processing your request. The following is a detailed message of the error that occurred.
Invalid Credential.
Please consult your local administrator for further assistance. The Certificate System logs may provide further information.
Solution: When several PKI subsystems (and therefore multiple Administration Certificates) co-exist within the same profile, the most common cause of this problem is selection of the wrong Administration Certificate when prompted for authentication. To correct this issue, attempt to "clear all of the private data" in your browser, and get re-prompted for authentication to the desired subsystem being careful to select the correct Administration Certificate for that PKI subsystem. If that fails, simply try to shutdown and restart your browser.
Problem: I attempted to reach Dogtag's CA web interface from a remote machine and was denied.
Solution: On Fedora 8, you may have the firewall for your machine enabled. In order to address this issue, do the following:
- On the main menu, click System->Administration->firewall.
- Type in the root password.
- Click on "Other Ports" because we only want to enable the ports we need.
- Click Add to add a port.
- Click on the "User Defined" checkbox to allow us to choose our own port.
- Make sure the "Protocol is set to "tcp".
- Type in the desired port number, the default is 9443 for the CA.
- Use the same procedure to add the configuration wizard's port of 9080.
- Note: If other ports have been configured, simply enable those as above.
- Click "Apply" at the top and accept the confirmation.
- Close the application.
Problem: I am unable to enroll a token on the TPS. The audit logs indicate that there is an error in creating a new record, and the directory server access logs indicate that ADD operations fail with error 21 (syntax error).
Solution: The TPS currently does work with syntax checking on in the directory server. A BZ has been filed to fix this (https://bugzilla.redhat.com/show_bug.cgi?id=596827). To workaround this, disable syntax checking in the dse.ldif of the database.
PKI Console
Problem: I attempted to launch pkiconsole <URL> from the command line, and I received an error stating "libstdc++.so.5 cannot open shared object file: No such file or directory". What is the problem?
Solution: Certain versions of the IBM JRE (e. g. - "java-1.5.0-ibm-1.5.0.5-1jpp") require the C++ compatibility library (e. g. - "compat-libstdc++"). As the root user, execute the following command:
yum install compat-libstdc++
Unfortunately, on some platforms such as Fedora 8, multiple legacy versions of this compatibility library may need to be installed:
yum install compat-libstdc++-296 compat-libstdc++-33
Internationalization
Problem: Per Bugzilla Bug #442310, I had a minor problem with my LC_CTYPE which was set to el_GR:
java.util.MissingResourceException: Can't find bundle for base name LogMessages,locale el_GR
Solution: Change LC_CTYPE to en_US before starting and everything will work.
EPEL
Problem: While attempting to install 'pki-ra' EPEL package on RHEL 5.5, I am getting the following messages thru yum:
Error: mod_nss >= 1.0.7 is needed by pki-ra-1.3.1-1.el5.noarch
Solution: Per Bugzilla Bug #529164 - mod_nss certificate database generated., Bugzilla Bug #533092 - mod_nss rfe - "Dynamic CRL Loading", and Bugzilla Bug #563874 - mod_nss - "Dynamic CRL Loading", the 'mod_nss' 1.0.8 package is not scheduled to be available until RHEL 5.6. For convenience, a copy of this package may be obtained from this website (see obtaining a copy of mod_nss-1.0.8-2.el5idm.<arch>.rpm for RHEL 5.5).
Problem: While attempting to install 'pki-tps' EPEL package on RHEL 5.5, I am getting the following messages thru yum:
Error: mod_nss >= 1.0.7 is needed by pki-tps-1.3.1-1.el5.i686 (32-bit) OR Error: mod_nss >= 1.0.7 is needed by pki-tps-1.3.1-1.el5.x86_64 (64-bit)
Solution: Per Bugzilla Bug #529164 - mod_nss certificate database generated., Bugzilla Bug #533092 - mod_nss rfe - "Dynamic CRL Loading", and Bugzilla Bug #563874 - mod_nss - "Dynamic CRL Loading", the 'mod_nss' 1.0.8 package is not scheduled to be available until RHEL 5.6. For convenience, a copy of this package may be obtained from this website (see obtaining a copy of mod_nss-1.0.8-2.el5idm.<arch>.rpm for RHEL 5.5).
Problem: For Dogtag 9.0, why aren't there any EPEL packages for RHEL 5.7?
Solution: Dogtag 9.0 has only been targeted for use with RHEL 6, consequently, there are no plans to release Dogtag 9.0 EPEL packages for RHEL 5.
Problem: If Dogtag 9.0 has been targeted for use with RHEL 6, why aren't there any EPEL packages for RHEL 6?
Solution: In RHEL 6, several Dogtag 9.0 packages (pki-core) are utilized via IPA v2.0+ and use non-UI "theme" packages (ipa-pki-theme) which are mutually exclusive from Dogtag-UI "theme" packages (dogtag-pki-theme). Plans exist to eventually integrate most other Dogtag subsystems (e. g. - pki-kra, pki-ocsp, etc.) with IPA v2.0+ on the RHEL 6 platform.
Miscellaneous
Problem: Per CVE-2007-4465 as documented in Bugzilla Bug #289511, the mod_autoindex.so Apache module contains a potential security vulnerability.
Solution: This is a known problem within the product, and will be addressed by Bugzilla Bug #439544: Remove mod_autoindex.so . . .
Problem: Once I configured my CA, it gives me a link to a page that has XXXXXX Certificate System and lists "SSL End Users Services" as well as "Agent Services". All I did was go through the setup of the CA service. If I click on either of those, I get a white blank screen. I have no idea how to debug this, I can't seem to find any error messages in /var/log/pki-ca to even point me anywhere, when I do request those pages, *nothing* shows up in any of the many log files in that directory. Any pointers?
I have had the same experience using dogtag on CentOS 6.x. The last time I looked many optional parts of the dogtag system were still missing (pki-ra, pki-ocsp, etc).
Solution: From the sounds of this problem, the Certificate Authority (CA) being used is the CA that is contained in the pki-core package that is reliant upon the ipa-pki-theme package (e. g. - presuming that CentOS 6.x is roughly equivalent to RHEL 6). The CA that utilizes the ipa-pki-theme package was never intended to be used as a standalone CA, but rather as a CA for use by Red Hat Identity Manager which is based upon FreeIPA, and as such, contains no true GUI component.
To use the packages in pki-core as a standalone CA in operating systems such as CentOS 6.x, you should attempt to replace the ipa-pki-theme non-GUI RPMS with their corresponding dogtag-pki-theme GUI packages (CentOS 5.x may have contained individual redhat-pki-ca-ui, redhat-pki-common-ui, etc., packages). Note that ALL three of these "GUI" packages are mutually exclusive and conflict with one another!
Additionally, the pki-core package currently only contains the CA, not the KRA, OCSP, RA, TKS, TPS, or pki-console packages.
To obtain any of these packages, please look on the Fedora Build System called Koji per the following links:
|
||||||||||||||||||||
|
||||||||||||||||||||
