This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 492108 - EC enabled CA broken after update
EC enabled CA broken after update
Status: CLOSED WORKSFORME
Product: Dogtag Certificate System
Classification: Community
Component: Certificate Manager (Show other bugs)
1.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Andrew Wnuk
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-25 08:46 EDT by David Stutzman
Modified: 2015-01-05 20:17 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-11 13:09:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
whole debug log after starting CA (36.58 KB, text/plain)
2009-03-25 08:46 EDT, David Stutzman
no flags Details

  None (edit)
Description David Stutzman 2009-03-25 08:46:36 EDT
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"
Comment 1 Christina Fu 2009-06-12 13:54:47 EDT
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
Comment 2 David Stutzman 2009-06-17 07:39:10 EDT
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).
Comment 4 Chandrasekar Kannan 2009-10-20 18:05:40 EDT
cc-ing kashyap to look at comment #3
Comment 5 David Stutzman 2009-10-21 07:26:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.