Created attachment 336633 [details] whole debug log after starting CA Description of problem: I updated some pki packages along with all of the fedora updates-newkey OS updates, rebooted the box and now the CA is malfunctioning. The following snippets are from the debug log: [25/Mar/2009:08:21:46][main]: ca.signing Signing Unit nickname Certicom FIPS Cert/Key Services:caSigningCert cert-pki-ca [25/Mar/2009:08:21:46][main]: Got token Certicom FIPS Cert/Key Services by name [25/Mar/2009:08:21:46][main]: Found cert by nickname [25/Mar/2009:08:21:46][main]: converted to x509CertImpl [25/Mar/2009:08:21:46][main]: Got private key from cert [25/Mar/2009:08:21:46][main]: Got public key from cert [25/Mar/2009:08:21:46][main]: SigningUnit init: debug Signing Algorithm SHA1withEC is not supported for the CA signing token [25/Mar/2009:08:21:46][main]: CA signing unit inited [25/Mar/2009:08:21:46][main]: cachainNum= 0 [25/Mar/2009:08:21:46][main]: in init - got CA chain from JSS. [25/Mar/2009:08:21:46][main]: ca.ocsp_signing Signing Unit nickname Certicom FIPS Cert/Key Services:ocspSigningCert cert-pki-ca [25/Mar/2009:08:21:46][main]: Got token Certicom FIPS Cert/Key Services by name [25/Mar/2009:08:21:46][main]: Found cert by nickname [25/Mar/2009:08:21:46][main]: converted to x509CertImpl [25/Mar/2009:08:21:46][main]: Got private key from cert [25/Mar/2009:08:21:46][main]: Got public key from cert [25/Mar/2009:08:21:46][main]: SigningUnit init: debug Signing Algorithm SHA1withEC is not supported for the CA signing token [25/Mar/2009:08:21:46][main]: Separate OCSP signing unit inited [25/Mar/2009:08:21:46][main]: in init - got OCSP chain from JSS. [25/Mar/2009:08:21:46][main]: CA First signing algorithm is SHA1withEC [25/Mar/2009:08:21:46][main]: in init - got CA name CN=CERDEC ECC Test CA-1,OU=PKI,OU=DoD,O=U.S. Government,C=US then lower down a stack trace: [25/Mar/2009:08:21:46][main]: CMS:Caught EBaseException Signing Algorithm SHA1withEC is not supported for the CA signing token at com.netscape.ca.SigningUnit.checkSigningAlgorithmFromName(SigningUnit.java:231) at com.netscape.ca.CRLIssuingPoint.initConfig(CRLIssuingPoint.java:604) at com.netscape.ca.CRLIssuingPoint.init(CRLIssuingPoint.java:417) at com.netscape.ca.CertificateAuthority.initCRL(CertificateAuthority.java:1644) at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:335) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:830) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:759) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:313) 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:85) 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:927) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:890) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1150) 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) The pki packages I have installed now are (rpm -qa | egrep -i pki-\|osutil\|symkey | sort | cat -n): 1 dogtag-pki-ca-ui-1.0.0-9.fc8 2 dogtag-pki-common-ui-1.0.0-11.fc8 3 dogtag-pki-console-ui-1.0.0-6.fc8 4 osutil-1.0.0-6.fc8 5 pki-ca-1.0.0-35.fc8 6 pki-ca-ui-1.0.0-4.fc8 7 pki-common-1.0.0-56.fc8 8 pki-common-ui-1.0.0-4.fc8 9 pki-console-1.0.0-15.fc8 10 pki-console-1.0.0-9.fc8 11 pki-console-ui-1.0.0-1.fc8 12 pki-java-tools-1.0.0-8.fc8 13 pki-native-tools-1.0.0-5.fc8 14 pki-selinux-1.0.0-7.fc8 15 pki-setup-1.0.0-20.fc8 16 pki-util-1.0.0-12.fc8 17 pki-util-1.0.0-6.fc8 18 symkey-1.0.0-8.fc8 If I su to pkiuser and run certutil on the CA's DB, it sees the certs/keys: $ certutil -L -d . -h all Enter Password or Pin for "Certicom FIPS Cert/Key Services": caSigningCert cert-pki-ca CTu,Cu,Cu caSigningCert cert-pki-ca CTu,Cu,Cu Certicom FIPS Cert/Key Services:caSigningCert cert-pki-ca CTu,Cu,Cu Certicom FIPS Cert/Key Services:caSigningCert cert-pki-ca CTu,Cu,Cu Certicom FIPS Cert/Key Services:subsystemCert cert-pki-ca u,u,u Certicom FIPS Cert/Key Services:ocspSigningCert cert-pki-ca u,u,u Certicom FIPS Cert/Key Services:Server-Cert cert-pki-ca u,u,u I *can* list the certificate using: $ certutil -L -d . -n "Certicom FIPS Cert/Key Services:caSigningCert cert-pki-ca"
Hi, I need some information. Please try to address all if possible: 1. which version of certicom ECC library are you using? I have had success with one that I used a long time ago (libsbcp.so). 2. where did you get the certicom library? 3. Please give procedure on how you added the module. 4. Please give procedure on how you initialized the token password. 5. What platform was used (OS). 6. Which NSS version? 7. x86 or x86_64 8. Anything else you wish to add. thanks! Christina
1. from NSS's modutil output: library name: /usr/lib/libsbcpgse.so slots: 2 slots attached status: loaded slot: FIPS Generic Crypto Services V1.0.1c token: Certicom FIPS Crypto Services slot: FIPS Certificate/Key Services V1.0.1c token: Certicom FIPS Cert/Key Services The PKCS#11 interface and SB GSE folders we got from Certicom are: - sbgse2.0-linux_x86 - sbp11api_gse1.0-linux_x86 2. We purchased Security Builder GSE FIPS and the PKCS#11 interface from Certicom. /usr/lib/libsbcpgse.so loads /usr/lib/libsbgse2.so which is the implementation library. 3. Inside the directory /var/lib/pki-ca/alias I ran: modutil -dbdir . -nocertdb -add certicom -libfile /usr/lib/libsbcpgse.so 4. This is the fun part. I could never use modutil to change/set the password so I had to compile Certicom's sample app and run that which creates the .certicom folder in $HOME and initializes the "token". Then copy that certicom DB over to CA user's $HOME and chown it to the CA's user. At that point I was able to use certutil options like -K which require a password to login to the token. 5. Fedora release 8 (Werewolf) 6. $Header: NSS 3.11.10.1 Extended ECC (debug) Nov 3 2008 10:46:46 $ (I realize dogtag is currently using 3.12.x) 7. x86 8. I filed another bug (bug 492124), after asking on pki-devel: http://osdir.com/ml/pki-devel/2009-03/msg00000.html, to have an NSS build for dogtag that was already built according to the directions on the wiki to be supplied. That's basically the problem. Once you install the CA from RPMS and build NSS the special way (according to the wiki) it's very hard (impossible?) to update the system/CA further. Since the CMC auth issue has been taken care of we should be able to move forward with testing CMC + EC, but to update the CA, NSS needs to be updated and if I just update the NSS RPM, I'll lose my EC capabilities. I currently have a block on updating NSS so I won't easily break the CA. If I do a check to see what packages yum wants to upgrade *besides* NSS and then manually grab those rpms and install them, the CA breaks. I remember checking out and compiling several different versions of NSS when I was initially trying to get this working and after talking to some of the NSS devs settling on the version I'm using (which I *think* is a 3_11 branch HEAD checkout).
cc-ing kashyap to look at comment #3
An update... I recently attempted to setup a Dogtag EC CA on Fedora 11. As soon as I replaced the system NSS with the custom one, the system became somewhat unusable. I don't know the extent of the breakage but I could no longer do a graphical login. It was also a fun surprise having rpm no longer work after I forcefully uninstalled the NSS rpm before installing another version. I looked into the NSS on a RHEL 5 box and it appeared to have an EC build. I spoke with someone in the dogtag IRC channel (sorry, forget which of the wonderful devs it was!) who said you guys use RHEL for testing EC. I then tried to install Dogtag on RHEL 5.4 and hit a snag because there is no JSS package for RHEL5. After speaking some more with the devs they mentioned CS8 has a JSS package. I was able to get a copy of CS8 with the errata update (for SHA2 + EC support) and install and test that setting up a P384withSHA384 EC CA. This worked fine. I set up another RHEL 5.4 box to be a build box, installed the JSS package and am building the CA from Dogtag SVN sources and things seem to be working smoothly. I still have to actually configure an EC CA though with this new setup. I originally filed the bug because there are still some outstanding issues we're waiting to get fixed and as soon as the fixes come out we'd like to test. Using CS8 means we would have to wait quite a while to get the fixes officially released. Using Dogtag, I can svn up and rebuild. The problem with the EC CA was that some of the newer Dogtag packages required a newer NSS and that required a rebuild of the custom NSS and the whole thing is just more fragile than I was hoping. I'm perfectly fine running Dogtag on RHEL 5.4 as we've got the spare licenses so for me this bug isn't truly an issue anymore. However, if you'd like to support Dogtag+EC running on Fedora, some changes are most likely needed. I didn't test with 9 or 10, but as I said before, replacing NSS on 11 caused breakages.