Description of problem: With SSL disabled (SSL is not functional on Dogtag EPEL, see bugzilla #568787), all required pki-ca ports (Unsecure, Secure Agent, Secure Admin, etc) are now initialized, but the Installation Wizard login page yields an error. Version-Release number of selected component (if applicable): pki-ca-1.3.0-7.el5 dogtag-pki-common-ui-1.3.1-1.el5 How reproducible: Always on RHEL5/CentOS (works on Fedora 12). Steps to Reproduce: 1. Disable SSL in /etc/pki-ca/server.xml 2. Start pki-cad 3. Connect to http://host:9445/ca/admin/console/config/login?pin=xxx Actual results: Certificate System CA Error Page HTTP STATUS 500 The server encountered an unexpected condition which prevented it from fulfilling the request. Please consult your local administrator for further assistance. The Certificate System logs may provide further information. Expected results: The server should show the "Welcome" page from the Certificate Authority Configuration Wizard. Additional info: 1. To circumvent the SSL issues (see bugzilla #568787), I disabled the SSL references in /etc/pki-ca/server.xml 2. All ports are now initialized (with SSL enabled, no SSL port was started), but the login page yields an error. 3. /var/log/pki-ca/ access_log : "GET /ca/admin/console/config/login?pin=kDMYRgLzYhYW8cEEV3eI HTTP/1.1" 500 5601 "GET /ca/admin/console/img/favicon.ico HTTP/1.1" 200 601 "GET /ca/admin/console/css/pki-base.css HTTP/1.1" 200 3850 "GET /ca/admin/console/css/pki.css HTTP/1.1" 200 11417 "GET /ca/admin/console/css/pki-360.css HTTP/1.1" 200 17856 ... 4. /var/lib/pki-ca/webapps/ca/admin/console/login.vm is present. 5. /var/log/pki-ca/catalina.out : org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Allocate exception for servlet csadmin-login java.lang.ClassNotFoundException: org.apache.velocity.servlet.VelocityServlet at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332) The velocity-1.4-6jpp.1 RPM is present. 6. Tested with both Sun JDK (from the RHEL5 channel) and OpenJDK. 7. I compared the installation and configuration files with a (successful, functional) Fedora 12 Dogtag installation, and I can find no discernible differences. Should I conclude from BZ #566342 , BZ #568787 and this BZ, that Dogtag RHEL/CentOS EPEL is borked ?
We are working on finding a solution and prioritizing the work. It might take us some time to figure out the best course of action.
Thank you for the update, Dmitri. In the meantime, could you be so kind to clarify the next few points ? 1. For the moment being, further testing Dogtag on RHEL5 by me is rather useless, as you seem to confirm that Dogtag on RHEL is flawed ? I am ware BZ is not for user support, but anyway : 2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to secure ldaps traffic). Probably a stupid question, but here it goes : Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later - once a solution for Dogtag on RHEL/CentOS has been found - transfer the created PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC & IP address, etc.) without invalidating the certificates ? 3. Or should I alternatively create a self-signed certificate on the DS, and later import this into Dogtag ? I would like to prevent a situation in which I have to revoke and reissue LDAP SSL certificates after the LDAP server has been deployed in production.
(In reply to comment #3) > Thank you for the update, Dmitri. > > > In the meantime, could you be so kind to clarify the next few points ? > > > 1. For the moment being, further testing Dogtag on RHEL5 by me is rather > useless, as you seem to confirm that Dogtag on RHEL is flawed ? > I confirm that the EPEL version does not work. One of the reasons is that it requires a later version of one of the packages than the one that is currently available from the OS channel. We need to reconcile it. There are other EPEL issues too that we are looking at. > > I am ware BZ is not for user support, but anyway : > > 2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to > secure ldaps traffic). > Probably a stupid question, but here it goes : > Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later - > once a solution for Dogtag on RHEL/CentOS has been found - transfer the created > PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC & > IP address, etc.) without invalidating the certificates ? > > 3. Or should I alternatively create a self-signed certificate on the DS, and > later import this into Dogtag ? > > I would like to prevent a situation in which I have to revoke and reissue LDAP > SSL certificates after the LDAP server has been deployed in production. I will pass this to our experts.
(In reply to comment #4) > (In reply to comment #3) > > Thank you for the update, Dmitri. > > > > > > In the meantime, could you be so kind to clarify the next few points ? > > > > > > 1. For the moment being, further testing Dogtag on RHEL5 by me is rather > > useless, as you seem to confirm that Dogtag on RHEL is flawed ? > > > > I confirm that the EPEL version does not work. > One of the reasons is that it requires a later version of one of the packages > than the one that is currently available from the OS channel. We need to > reconcile it. There are other EPEL issues too that we are looking at. > > > > > > I am ware BZ is not for user support, but anyway : > > > > 2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to > > secure ldaps traffic). > > Probably a stupid question, but here it goes : > > Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later - > > once a solution for Dogtag on RHEL/CentOS has been found - transfer the created > > PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC & > > IP address, etc.) without invalidating the certificates ? > > > > 3. Or should I alternatively create a self-signed certificate on the DS, and > > later import this into Dogtag ? > > > > I would like to prevent a situation in which I have to revoke and reissue LDAP > > SSL certificates after the LDAP server has been deployed in production. > > I will pass this to our experts. Didier, Starting off in a vm and then migrating will work, but there are a couple of things that you'll need to work through first. I would start with the CS8 migration guide. Its designed for CS7.x to 8, but it will provide you with a good overview of the steps and the things you will need to consider. If can be found at http://www.redhat.com/docs/manuals/cert-system/8.0/migration/html/index.html Now, as far as different names, ip addresses and such: The docs do not currently state this, but they will be updated shortly. A note for the security domain migration: "Changing either the instance name or the fully-qualified domain name is not supported for migration. The fully-qualified domain name of the host machine for the new instance must be the same as the fully-qualified domain name of the original instance. Similarly, the new instance name must also be the same as the original instance name." Another option that may work here is cloning. Again, the CS8 docs can be a good guide here. Check out http://www.redhat.com/docs/manuals/cert-system/8.0/deploy/html/sect-Deployment_Guide-Planning_Your_CRTS-Arranging_the_Certificate_Authority_Hierarchy.html#sect-Deployment_Guide-Certificate_Manager_Flexibility_and_Scalability-CA_Cloning and http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Cloning_a_Subsystem.html and probably the one you will want to be sure and check out - converting cloned CAs: http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/converting-masters-and-clones.html#converting-ca-clones HTH, -kent
Thank you for your extensive answer, Kent ; this should get me on the road until the EPEL issues are solved. One final question (and now we're really out of scope for this BZ, my apologies), concerning migration and/or transfer (from e.g. Fedora12 to RHEL5) and the FQDN issue : would it be a valid option to use an ethernet alias (e.g. eth0:1) with its own IP address and FQDN, and use this to seamlessly transfer the PKI to it final destination ? e.g. PKI on interim server (F12) : - eth0:0 192.168.1.100 fedora12.domain.org - eth0:1 192.168.1.123 cert.domain.org <-- PKI moves to final destination (RHEL5) : - eth0:0 192.168.1.101 rhel5.domain.org - eth0:1 192.168.1.123 cert.domain.org <-- PKI I guess the issue would be to assign the PKI to eth0:1, and not eth0:0 ? (sincere apologies if this is handled in the docs you're referring to, I have not yet read them).
(In reply to comment #6) > Thank you for your extensive answer, Kent ; this should get me on the road > until the EPEL issues are solved. > > > One final question (and now we're really out of scope for this BZ, my > apologies), concerning migration and/or transfer (from e.g. Fedora12 to RHEL5) > and the FQDN issue : > would it be a valid option to use an ethernet alias (e.g. eth0:1) with its own > IP address and FQDN, and use this to seamlessly transfer the PKI to it final > destination ? > > e.g. PKI on interim server (F12) : > - eth0:0 192.168.1.100 fedora12.domain.org > - eth0:1 192.168.1.123 cert.domain.org <-- PKI > moves to final destination (RHEL5) : > - eth0:0 192.168.1.101 rhel5.domain.org > - eth0:1 192.168.1.123 cert.domain.org <-- PKI > > I guess the issue would be to assign the PKI to eth0:1, and not eth0:0 ? > > (sincere apologies if this is handled in the docs you're referring to, I have > not yet read them). Using a vip should be fine, as long as dogtag is configured to use it (security domain, etc). then migrating will be ok, as long the the fqdn stays the same. I don't like giving "should" answers, but I have not done it on a vip. I do not see any reason why it would not work, though. -kent
Well, rest assured I'll file a BZ if it doesn't. :) Thank you for the advice.
Created attachment 405062 [details] EPEL fix for "_sharedstatedir" macro on RHEL References: * http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions * http://fedoraproject.org/wiki/Packaging/DistTag
Created attachment 405063 [details] EPEL fix for "_sharedstatedir" macro on RHEL References: * http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions * http://fedoraproject.org/wiki/Packaging/DistTag
Created attachment 405065 [details] EPEL fix for "_sharedstatedir" macro on RHEL References: * http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions * http://fedoraproject.org/wiki/Packaging/DistTag
attachment (id=405062) attachment (id=405063) attachment (id=405065) +awnuk
See also 'Bugzilla Bug #568787 - pki-ca fails to create SSL connectors' # cd tomcatjss # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M tomcatjss.spec M build_tomcatjss M build.xml # svn commit Sending build.xml Sending build_tomcatjss Sending tomcatjss.spec Transmitting file data ... Committed revision 88. # cd pki/base # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M config/release.xml # svn commit Sending base/config/release.xml Transmitting file data . Committed revision 1029. # cd pki/dogtag # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M common/pki-common.spec M config-ext/build_dogtag_pki M util/pki-util.spec # svn commit Sending dogtag/common/pki-common.spec Sending dogtag/config-ext/build_dogtag_pki Sending dogtag/util/pki-util.spec Transmitting file data ... Committed revision 1030.
Confirmed fixed in current EPEL-testing rebuilds.