Bug 1478394

Summary: [RFE] Sub-CA CRL not published in Master CA's CRL
Product: Red Hat Enterprise Linux 8 Reporter: Michael Voetter <mikevo>
Component: pki-coreAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED UPSTREAM QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: ---CC: ascheel, cobrown, dmoluguw, ftweedal, mharmsen, mikevo, msauton, pvoborni, rcritten, tscherf
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-26 14:26:37 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Voetter 2017-08-04 13:36:39 UTC
Description of problem:
Revoked certificates of the Sub-CA do not show up in the http://ipa-ca.$DOMAIN/ipa/crl/MasterCRL.bin

Version-Release number of selected component (if applicable):
ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

How reproducible:
Setup sub-ca as described in:
http://blog-ftweedal.rhcloud.com/2016/07/lightweight-sub-cas-in-freeipa-4-4/

Steps to Reproduce:
1. Revoke issued certificate with sub-ca (Web UI)
2. wget http://ipa-ca.$DOMAIN/ipa/crl/MasterCRL.bin
3. openssl crl -inform der -in MasterCRL.bin -noout -text

Actual results:
Revoked certificate does not show up.

Expected results:
Revoked certificate should show up.

Additional info:

Comment 2 Rob Crittenden 2017-08-04 13:49:37 UTC
CRLs are updated periodically, every 60 minutes IIRC. Did you wait between step 1 and step 2?

Comment 3 Michael Voetter 2017-08-04 14:24:51 UTC
While trying to figure out when exactly i revoked the certificate I fond the following in /var/log/pki/pki-tomcat/ca/system

0.Thread-34 - [03/Aug/2017:22:54:56 CEST] [8] [3] Publishing: Could not publish certificate serial number 0x1e. Error Failed to publish using rule: No rules enabled
0.Thread-35 - [04/Aug/2017:12:48:49 CEST] [8] [3] Publishing: Could not publish certificate serial number 0x1f. Error Failed to publish using rule: No rules enabled
0.Thread-36 - [04/Aug/2017:13:38:42 CEST] [8] [3] Publishing: Could not publish certificate serial number 0x20. Error Failed to publish using rule: No rules enabled
0.Thread-37 - [04/Aug/2017:14:13:49 CEST] [8] [3] Publishing: No rule can be found for unpublishing: certs request 38
0.Thread-37 - [04/Aug/2017:14:13:49 CEST] [8] [3] Publishing: Could not unpublish certificate serial number 0x1e. Error No Rule instance is matched for request 38.

I have no idea where I can/should add such a (missing) rule but I guess this is causing the problem.

(In reply to Rob Crittenden from comment #2)
> CRLs are updated periodically, every 60 minutes IIRC. Did you wait between
> step 1 and step 2?

I double checked it right now (approximately two hours later) with still the same result.

Comment 4 Rob Crittenden 2017-08-04 14:49:28 UTC
Fraser, is specific configuration needed in dogtag to enable CRLs for sub-CAs?

Comment 5 Fraser Tweedale 2017-08-08 06:08:19 UTC
There is no support yet for Lightweight CA CRLs.
See upstream ticket https://pagure.io/dogtagpki/issue/1627.

OCSP works perfectly for Lightweight CAs.

Comment 6 Fraser Tweedale 2017-08-08 13:28:57 UTC
Michael, how badly do you need CRL for your use case, instead of OCSP?

Comment 7 Michael Voetter 2017-08-10 14:03:48 UTC
I'd need to get a Certificate Revocation List in X.509 CRL format to manually add the CRL to a pfSense box which I use as a VPN gateway. The reason for that manual step is that it's not possible to configure the OpenVPN Server in the 2.3.4-RELEASE of pfSense to force OCSP checks AFAIK.


(In reply to Fraser Tweedale from comment #5)
> There is no support yet for Lightweight CA CRLs.
> See upstream ticket https://pagure.io/dogtagpki/issue/1627.
> 
> OCSP works perfectly for Lightweight CAs.


My cert profile is basically a copy of caIPAserviceCert as I followed the steps described in the blog entry https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/

Do I need to modify crlDistPoints entries of that profile as the Sub-CA doesn't support the CRL generation but the respective URL is still present?

Comment 8 Fraser Tweedale 2017-08-11 03:04:27 UTC
Michael, yes, you might want to just remove the CRLDP extension on
the modified profile.

Comment 9 Matthew Harmsen 2018-07-04 00:27:01 UTC
Moved to RHEL 7.7.

Comment 10 Corey Brown 2019-04-02 15:51:03 UTC
Hi,

I have a case that is getting these exact error messages:
Excerpt from etoltilisdidm03.idm.sgdcelab.sabre.com /var/log/pki/pki-tomcat/system :

0.Thread-13 - [22/Mar/2019:15:36:05 CDT] [8] [3] Publishing: Could not publish certificate serial number 0x4ff90016. Error Failed to publish using rule: No rules enabled
0.Thread-14 - [22/Mar/2019:15:36:35 CDT] [8] [3] Publishing: Could not publish certificate serial number 0x4ff90017. Error Failed to publish using rule: No rules enabled
0.Thread-15 - [22/Mar/2019:15:37:24 CDT] [8] [3] Publishing: Could not publish certificate serial number 0x4ff90018. Error Failed to publish using rule: No rules enabled
0.Thread-16 - [25/Mar/2019:13:45:22 CDT] [8] [3] Publishing: Could not publish certificate serial number 0x4ff90019. Error Failed to publish using rule: No rules enabled

However, the CRL master was moved at the beginning of the upgrade, the customer doesn't believe any new certificates were issued unless they were issued automatically when running `ipa-csreplica-manage set-renewal-master`. The customer doesn't use external CAs, only the self-signed cert that is created when the first server was created.

Is there a workaround for this issue I could provide to the customer?

Corey Brown

Comment 11 Marc Sauton 2019-04-02 17:14:47 UTC
the Publishing messages "Error Failed to publish using rule: No rules enabled" are unrelated.

Comment 12 Dinesh Prasanth 2020-04-28 18:08:35 UTC
Fraser, as per your email on 26 Feb 2020, you wanted to take this over. So, reassigning this bug
to you.

Comment 13 Fraser Tweedale 2020-06-19 10:25:42 UTC
Blog post about this feature and possible approaches to implementation:
https://frasertweedale.github.io/blog-redhat/posts/2020-06-19-dogtag-lightweight-ca-crl.html

Comment 14 Matthew Harmsen 2020-06-26 14:25:12 UTC
(In reply to Fraser Tweedale from comment #13)
> Blog post about this feature and possible approaches to implementation:
> https://frasertweedale.github.io/blog-redhat/posts/2020-06-19-dogtag-
> lightweight-ca-crl.html

Per email with ftweedal from June 19, 2020:

It's a bit of a compliance issue to have certs issued by LWCA
bearning a CRLDP extension that points at a CRL that does not
include the LWCA in its scope.

But how important is the CRL?  Does anyone really need it, or is
OCSP (which is already implemented) enough?

I will blog about the issues and implementation ideas, to transfer
some of that knowledge and identify the challenges/tradeoffs.  But
if there is no customer specifically asking, we can probably close
it, and re-open later if necessary.  But we should document the
current behaviour as a known issue.

https://frasertweedale.github.io/blog-redhat/posts/2020-06-19-dogtag-lightweight-ca-crl.html

Comment 15 Matthew Harmsen 2020-06-26 14:26:37 UTC
Closing - Upstream ticket is https://pagure.io/dogtagpki/issue/1627 -  Lightweight CAs: add ability to configure CRLs for lightweight CAs