RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1360525 - CA subsystem OSCP responder fails when LWCAs are not used
Summary: CA subsystem OSCP responder fails when LWCAs are not used
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 7.3
Assignee: RHCS Maintainers
QA Contact: Asha Akkiangady
URL:
Whiteboard:
: 1360526 (view as bug list)
Depends On:
Blocks: 1360526
TreeView+ depends on / blocked
 
Reported: 2016-07-27 01:46 UTC by Fraser Tweedale
Modified: 2020-10-04 21:13 UTC (History)
4 users (show)

Fixed In Version: pki-core-10.3.3-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1360526 (view as bug list)
Environment:
Last Closed: 2016-11-04 05:26:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2540 0 None None None 2020-10-04 21:13:07 UTC
Red Hat Product Errata RHBA-2016:2396 0 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2016-11-03 13:55:03 UTC

Description Fraser Tweedale 2016-07-27 01:46:01 UTC 
Description of problem:



After upgrading to FreeIPA 4.3.1, I am getting "Error querying OCSP responder" with the following command. I can confirm certificate with serial 0x14 is present in the system and is not expired/revoked, etc. I'm a bit nervous about the "OCSPServlet: Could not locate issuing CA" in the Dogtag output below.

    # /usr/bin/openssl ocsp \

        -issuer /etc/ipa/ca.crt \ -nonce \ -CAfile /etc/ipa/ca.crt \ -url "​http://ipa-ca.example.com/ca/ocsp" \ -serial 0x14

    # rpm -q freeipa-server pki-server freeipa-server-4.3.1-1.fc24.x86_64 pki-server-10.3.3-1.fc24.noarch



Version-Release number of selected component (if applicable): 10.3


How reproducible: always, when lightweight CAs are not used.


Steps to Reproduce:
1. upgrade PKI (not part of IPA deployment) from older version to 10.3,
   or install 10.3 and delete lightweight CAs container
   (ou=authorities,ou=ca,o=ipaca)

2. Send an OCSP request to CA subsystem's OCSP responder



Actual results:

OCSP responder errors, with message in log
"OCSPServlet: Could not locate issuing CA"


Expected results:

OCSP responder does not error; returns correct response.


Additional info:
Comment 2 Fraser Tweedale 2016-08-02 00:58:37 UTC 
*** Bug 1360526 has been marked as a duplicate of this bug. ***
Comment 3 Matthew Harmsen 2016-08-08 21:02:43 UTC 
On August 7, 2016, ftweedal wrote:

Fixed in master (018b5c1f3295fadd263d256d00866dd7b9d31163)
Comment 5 Geetika Kapoor 2016-09-23 04:17:52 UTC 
In CA logs i could see:

debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: OCSP Request:
debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: MEcwRaADAgEAMD4wPDA6MAkGBSsOAwIaBQAEFI+f1p94B6E7gFyBxU3fvfSauVLG
debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: OCSP Response Size:
debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: 2507
debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: OCSP Response Data:
debug:[21/Sep/2016:22:28:58][http-bio-20080-exec-5]: OCSPServlet: MIIJxwoBAKCCCcAwggm8BgkrBgEFBQcwAQEEggmtMIIJqTCBzqFoMGYxJTAjBgNV

Do you think its enough.please add more test scenario if it's needed
Comment 6 Fraser Tweedale 2016-09-23 05:07:40 UTC 
To verify this fix, the lightweight CAs LDAP subtree must be absent.
Procedure:

1. If ou=authorities,ou=ca,{basedn} subtree exists:
   1.1. Stop Dogtag
   1.2. Delete the whole subtree *including the ou=authorities container itself*
   1.3. Start Dogtag

2. Perform an OCSP request against the CA subsystem.  If request succeeds -> verified.
Comment 7 Matthew Harmsen 2016-09-23 15:51:52 UTC 
(In reply to Fraser Tweedale from comment #6)
> To verify this fix, the lightweight CAs LDAP subtree must be absent.
> Procedure:
> 
> 1. If ou=authorities,ou=ca,{basedn} subtree exists:
>    1.1. Stop Dogtag
>    1.2. Delete the whole subtree *including the ou=authorities container
> itself*
>    1.3. Start Dogtag
> 
> 2. Perform an OCSP request against the CA subsystem.  If request succeeds ->
> verified.

Moving back to ON_QA based upon these comments.
Comment 8 Geetika Kapoor 2016-09-26 06:53:40 UTC 
Test steps:

1. I have deleted ou=authorities,ou=ca,{basedn} subtree. But what is the use for it? Another question, If i do a OCSP query will it save something in LDAP and ou=authorities,ou=ca,{basedn} subtree will get created again?

Below is the result of the OCSP query.

OCSPClient -h pki1.example.com -p 30144 -d /var/lib/pki/TestExternal/alias/ -t /ca/ocsp -c 'caSigningCert cert-TestExternal CA' --serial 1 -v 
Initializing security database
Creating request for serial number 1
Submitting OCSP request
URL: http://pki1.example.com:30144/ca/ocsp
Data Length: 68
Data: MEIwQDA+MDwwOjAJBgUrDgMCGgUABBQmZlUQJMv/qPoB+ReYFx1PO/SjVQQUKHLR
YOI4kcprgNYqlWpSnXWfbI4CAQE=

CertID.serialNumber=1
CertStatus=Good
Comment 9 Ade Lee 2016-09-27 18:14:55 UTC 
The subtree is being removed to simulate a case where the LWCA subtree did not exist to begin with.  This would occur when an instance is created by an old version of dogtag (before LWCAs), and then we update to the latest software.

You will notice that this bug was originally was reported during an IPA migration test.

The test you have done is sufficient as test that triggers the newly fixed code.
A good end-to-end test would be to do an IPA migration - and confirm that the error reported above is no longer observed.
Comment 10 Asha Akkiangady 2016-09-27 22:02:36 UTC 
IPA QE team confirmed that IPA upgrade from 4.2 to 4.4 worked fine. Based off of comment #9 response, marking the bug verified.
Comment 12 errata-xmlrpc 2016-11-04 05:26:33 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2396.html
Note You need to log in before you can comment on or make changes to this bug.