Bug 1360525

Summary: CA subsystem OSCP responder fails when LWCAs are not used
Product: Red Hat Enterprise Linux 7 Reporter: Fraser Tweedale <ftweedal>
Component: pki-coreAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.3CC: alee, ftweedal, gkapoor, mharmsen
Target Milestone: rc   
Target Release: 7.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.3.3-5.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1360526 (view as bug list) Environment:
Last Closed: 2016-11-04 05:26:33 UTC Type: Bug
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: 1360526    

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