Bug 494696 - subordinate CA creation with external CA option failure. Needs better error reporting.
subordinate CA creation with external CA option failure. Needs better error r...
Status: CLOSED CURRENTRELEASE
Product: Dogtag Certificate System
Classification: Community
Component: CA (Show other bugs)
unspecified
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Christina Fu
Chandrasekar Kannan
:
Depends On:
Blocks: 445047
  Show dependency treegraph
 
Reported: 2009-04-07 15:52 EDT by Chandrasekar Kannan
Modified: 2015-01-05 20:17 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-04 16:05:15 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)
subordinate CA debug log indicating failure (174.89 KB, text/plain)
2009-04-07 15:54 EDT, Chandrasekar Kannan
no flags Details

  None (edit)
Description Chandrasekar Kannan 2009-04-07 15:52:16 EDT
Steps to reproduce:

1 - install a rootCA (beta bits) - successful.
2 - create a 2nd instance with pkicreate.
3 - configure the 2nd instance. 
  - while configuring follow these ..
  -- create a new security domain
  -- mark it to be a sub-ordinate CA
  -- choose option External CA. 
  -- copy/paste CSR(s) to get it signed by the external CA (in our case
, CA in step 1)
  -- after approval, paste them back in the wizard and click Apply.
press next.

You will start to see NullpointerExceptions in the ca debug log.
Comment 1 Chandrasekar Kannan 2009-04-07 15:54:26 EDT
Created attachment 338588 [details]
subordinate CA debug log indicating failure
Comment 2 Christina Fu 2009-04-08 20:24:45 EDT
So, after repeatedly going through the procedure successfully myself without failure regardless of the platform, and observing others going through the procedure with consistent failure, it is observed that there is a subtle difference when I do my installation.

I always change the domain name and the subsystem name on those two panels.

The quick workaround should be to always use a different security domain name.
Comment 3 Jeff Broitman 2009-04-08 21:45:42 EDT
Since the Subordinate I make is always on a different box than the root I don't see how this is suppose to be a work around.  If I install a RHCS8 Beta ROOT CA (Domain1). Then create a RHCS8 Beta Subordinate CA (Domain2) and sign it with my 8.0 Beta root, how exactly is this a work around?  Are you saying that a 8 Beta Root must exist first on the box before a subordinate is created?  The Subordinate who's logs I sent was a new domain signed by an external root that has no domain associated.  

I will of course try your recommendations tomorrow at work, but I guess I'm missing the point to this exercise.

-jzb
Comment 4 Christina Fu 2009-04-08 23:43:53 EDT
(In reply to comment #3)
> Since the Subordinate I make is always on a different box than the root I don't
> see how this is suppose to be a work around.  If I install a RHCS8 Beta ROOT CA
> (Domain1). Then create a RHCS8 Beta Subordinate CA (Domain2) and sign it with
> my 8.0 Beta root, how exactly is this a work around?  Are you saying that a 8
> Beta Root must exist first on the box before a subordinate is created?  The

oh, I did not suggest that.  Please do not install a RHCS8 Beta root CA unless that's what you plan to do in your deployment.
What I suggested was, since I seem to be the only one that keeps getting the subordinate CA installed signed by an external CA, it might be a good idea to just do what I do as a workaround, that is, to NOT take the default domain name suggested by the system (change it to something you never used before), and NOT take the default subsystem name suggested by the system (change it to something you never used before).  Certain data, including the security domain names, are stored on the ldap system.  There may well be bug in the system that does not detect/alert people when needed, and/or delete existing ones when needed.  Further investigation will be needed, of course.  But, in the mean time, please just try to change the names on those two panels and we will appreciate it if you could tell us if this helps or not.

> Subordinate who's logs I sent was a new domain signed by an external root that
> has no domain associated.  
> 
> I will of course try your recommendations tomorrow at work, but I guess I'm
> missing the point to this exercise.
> 
> -jzb
Comment 5 Christina Fu 2009-04-09 11:25:51 EDT
notes to self (or Ade) later:

I did a careful comparison between the log of a success case and the log of a failure cases, and then the comparison between the cert db content.  The following are worth noting.

Success case debug message:

[07/Apr/2009:13:13:04][http-9544-Processor22]: CertRequestPanel configCert: cert imported for certTag ocsp_signing
[07/Apr/2009:13:13:04][http-9544-Processor22]: Updating local request... certTag=ocsp_signing

Failure case debug message:

[08/Apr/2009:05:46:07][http-9564-Processor17]: CertRequestPanel configCert: Failed to import certificate ocsp_signing Exception: org.mozilla.jss.crypto.TokenException: PK11_ImportDERCertForKey Unable to import certificate to its token: (-8054) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.
[08/Apr/2009:05:46:07][http-9564-Processor17]: Updating local request... certTag=ocsp_signing

==================================
Success case certdb content:
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Certificate Authority - SjcRedhat Domain jaw0407             CT,c,
ocspSigningCert cert-pki-ca1                                 u,u,u
subsystemCert cert-pki-ca1                                   u,u,u
caSigningCert cert-pki-ca1                                   CTu,Cu,Cu
Server-Cert cert-pki-ca1                                     u,u,u
auditSigningCert cert-pki-ca1                                u,u,u


Failure case certdb content:
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca2                                     CTu,Cu,Cu
caSigningCert cert-pki-ca2                                   CTu,Cu,Cu
caSigningCert cert-pki-ca2                                   CT,C,C


Note that in the success case, the nick name of the CA contains the domain name exactly as I entered (not taking the default suggested by system),
while in the failure case, the nickname of the CA bears the one from the CS.cfg file.
Comment 6 Christina Fu 2009-04-09 13:58:50 EDT
Just a summary.

I asked Jeff to try it again with specific steps on the Requests and Certs panel and it worked for him.

The exact steps are
step 2: the pkcs7 chain should not contain the leaf cert.
step 3: it should only contain the leaf cert.

We probably need better wording/warning on the panel.
Comment 9 Kashyap Chamarthy 2010-10-25 10:49:42 EDT
Verified.
- RHEL 5.6(x86_64)
- CS8.1 nightly(10/21/2010)


Steps:
- Create a MasterCA
- Create a new instance(for SubCA)
- While configuring SubCA, change the 'security domain name' to a new one, and at the 'Subject Names' panel. Change the DN name for subsystem cert to something different than the default
- Now. proceed ahead & finish configuration & try to access url

SubCA subsystem certs
-------------------------------------------------------------------------
[root@eccerrata pki-subca-ca1]# certutil -L -d alias/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Certificate Authority - PnqRedhat Domain-master1             CT,c,
ocspSigningCert cert-pki-subca-ca1                           u,u,u
subsystemCert cert-pki-subca-ca1                             u,u,u
caSigningCert cert-pki-subca-ca1                             CTu,Cu,Cu
Server-Cert cert-pki-subca-ca1                               u,u,u
auditSigningCert cert-pki-subca-ca1                          u,u,u
[root@eccerrata pki-subca-ca1]# 
-------------------------------------------------------------------------

successful message in the SubCA debug log (similar to comment #5)


[root@eccerrata pki-subca-ca1]# cat logs/debug | grep -i "certTag ocsp" -A 2
[25/Oct/2010:15:35:35][http-20345-Processor24]: NamePanel: display() added cert to mCerts: certTag ocsp_signing
[25/Oct/2010:15:35:35][http-20345-Processor24]: NamePanel: display() about to process certTag :sslserver
[25/Oct/2010:15:35:35][http-20345-Processor24]: NamePanel: display() override is false
--
[25/Oct/2010:15:39:31][http-20345-Processor19]: NamePanel: updateConfig() for certTag ocsp_signing
[25/Oct/2010:15:39:31][http-20345-Processor19]: NamePanel: setting signing nickname=ocspSigningCert cert-pki-subca-ca1
[25/Oct/2010:15:39:31][http-20345-Processor19]: NamePanel: updateConfig() done
--
[25/Oct/2010:15:43:01][http-20345-Processor22]: CertRequestPanel configCert: cert imported for certTag ocsp_signing
[25/Oct/2010:15:43:01][http-20345-Processor22]: Updating local request... certTag=ocsp_signing
[25/Oct/2010:15:43:01][http-20345-Processor22]: In LdapBoundConnFactory::getConn()

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