Bug 494696

Created attachment 338588 [details]
subordinate CA debug log indicating failure

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.

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

(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

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.

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.

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()