Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-27 01:46 UTC by Fraser Tweedale
Modified: 2016-11-04 05:26 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:
Environment:
Last Closed: 2016-11-04 05:26:33 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2396 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.