Bug 642398

Summary: Unknown LDAP object classes prevent new Certificate Request entries
Product: [Retired] Dogtag Certificate System Reporter: Didier <d.bz-redhat>
Component: Internal Database (LDAP)Assignee: Andrew Wnuk <awnuk>
Status: CLOSED NOTABUG QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: low    
Version: 1.3CC: benl, cfu, dpal, jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-03 14:38:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 530474    
Attachments:
Description Flags
Excerpts from catalina.out debug system
none
Excerpts from pki-ca .ldif dump none

Description Didier 2010-10-12 19:34:44 UTC
Description of problem:
Probably after an update, the CA is unable to process new cert requests, due to missing object classes in the 386-ds LDAP backend.


Version-Release number of selected component (if applicable):
pki-ca-1.3.6-1.el5

How reproducible:
Always

Steps to Reproduce:
1. Connect to Dogtag CA web interface (SSL End User Services) ;
2. Submit cert request data ;
3. Receive e-mail confirmation (!) that certificate request is in the queue.
  
Actual results:

When consulting the supplied URL to process the request :
"Problem Processing Your Request
"The Certificate Manager encountered an unexpected error while processing your request. The following is a detailed message of the error that occurred.
    Request ID 24 was not found in the request queue.
Please consult your local administrator for further assistance. The Certificate System logs may provide further information."

Expected results:

The request should be present in the queue.


Additional info:

- Last (succesful) certificate request was somewhere in May 2010 ; since then, two pki-ca updates and one 389-ds-base update have occurred :

# grep pki-ca-1 /var/log/yum.log
Apr 21 14:45:18 Installed: pki-ca-1.3.3-1.el5.noarch
Jul 22 04:04:07 Updated: pki-ca-1.3.5-1.el5.noarch
Aug 28 04:10:11 Updated: pki-ca-1.3.6-1.el5.noarch

# grep 389-ds-base /var/log/yum.log
Feb 10 04:51:54 Updated: 389-ds-base-1.2.5-1.el5.x86_64
Oct 08 12:39:41 Updated: 389-ds-base-1.2.6-1.el5.x86_64

- Please find in attachment some logs, which indicate missing object classes in the LDAP backend (LDAP db has been restored to previous backups, to no avail).

Comment 1 Didier 2010-10-12 19:42:06 UTC
Created attachment 453020 [details]
Excerpts from catalina.out debug system

12:38:43 : pki-ca restart
  Warnings about unknown object classes "crlIssuingPointRecord" and "certificateRecord"

15:14:13 : submitting certificate request through CA web interface
  Error: LDAP operation failure

15:16:06 : consulting requestId=24 through CA web interface
  Error : Request ID 24 not found in the request queue.

+ miscellaneous errors concerning CRL

Comment 2 Didier 2010-10-12 19:53:56 UTC
Created attachment 453022 [details]
Excerpts from pki-ca .ldif dump

Two .ldif examples where "objectClass: crlIssuingPointRecord" and "objectClass: request" are applied.

Entry-id 86 is the 23rd (and last) certificate request (dating from 2010-05-10), which was at that time successfully enrolled.

Comment 3 Didier 2010-10-18 06:20:41 UTC
Is there anything more I can do to help debug this issue ?

(at this moment, I am unable to request or enroll CSR's).

Comment 4 Didier 2010-10-19 07:34:39 UTC
Related to bugzilla 572018 ?

Comment 7 Didier 2010-12-03 14:38:59 UTC
Got the LDAP backend data back in a decent shape (see bug #572018), rendering the PKI data accessible again.

Closing as NOTABUG.