#7815 IPA PKI publishes CRL to LDAP
Closed: invalid 5 years ago by cheimes. Opened 5 years ago by cheimes.

Issue

IPA's PKI instance publishes latest CRL to LDAP although LDAP publishing should be disabled by default.

Steps to Reproduce

  1. request, then revoke a certificate
  2. wait a couple of hours, Dogtag only creates a new CRL every 3 hours
  3. sudo ldapsearch -H ldapi://%2fvar%2frun%2fslapd-IPA-EXAMPLE.socket -Y EXTERNAL -b cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca certificateRevocationList

Actual behavior

dn: cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca
certificateRevocationList:: MIIB6TCB0gIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDA
 tJUEEuRVhBTVBMRTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5Fw0xODEyMTgxMjUwMDB
 aFw0xODEyMTgxMzAwMDBaMDYwIAIBFRcNMTgxMjEyMTAwOTMwWjAMMAoGA1UdFQQDCgEEMBICARYX
 DTE4MTIxNzE0MzU1NVqgMDAuMB8GA1UdIwQYMBaAFHynwdoDyuMroTDSbtXBZgFKL1cCMAsGA1UdF
 AQEAgIAwjANBgkqhkiG9w0BAQsFAAOCAQEAseqN+NWDO5wtWa4i6hr7yb9tcWivf2dLNkO5TqfYk5
 YMoEtVKZUsO8GamqNDJGQkk3Mm2Ds6GwpK/EcvUTV9lmusscd/+jDpvW9RLDliI492Wp9025c7B6l
 s6R39OIJsRblUUm20owUTv9bJLyCIWubDjZsnASgBgauI1tyPjQx+UaBD1TMEy0MsE0H40ww50E0l
 EKX3O0a/87omz8220dwXfMWeWhb08S6wlZvFxTrpNlh6JIsDMTMCi6a/q6LlBOQruH2sFjsyMWUJx
 w2bmjsQzdbEH9QZBgw+s0wDfDWzsM0dzpnTlA9zgEg3iNsvF2iXMVFytt9HkLXudYPEbA==

Expected behavior

I was under the impression that IPA disables LDAP publishing of CRLs by default.

Version/Release/Distribution

freeipa-server-4.7.2-1.fc29.x86_64
freeipa-client-4.7.2-1.fc29.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-1.4.0.18-1.fc29.x86_64
pki-ca-10.6.8-3.fc29.noarch
krb5-server-1.16.1-21.fc29.x86_64

Additional info:

-----BEGIN X509 CRL-----
MIIB6TCB0gIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDA
tJUEEuRVhBTVBMRTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5Fw0xODEyMTgxMjUwMDB
aFw0xODEyMTgxMzAwMDBaMDYwIAIBFRcNMTgxMjEyMTAwOTMwWjAMMAoGA1UdFQQDCgEEMBICARYX
DTE4MTIxNzE0MzU1NVqgMDAuMB8GA1UdIwQYMBaAFHynwdoDyuMroTDSbtXBZgFKL1cCMAsGA1UdF
AQEAgIAwjANBgkqhkiG9w0BAQsFAAOCAQEAseqN+NWDO5wtWa4i6hr7yb9tcWivf2dLNkO5TqfYk5
YMoEtVKZUsO8GamqNDJGQkk3Mm2Ds6GwpK/EcvUTV9lmusscd/+jDpvW9RLDliI492Wp9025c7B6l
s6R39OIJsRblUUm20owUTv9bJLyCIWubDjZsnASgBgauI1tyPjQx+UaBD1TMEy0MsE0H40ww50E0l
EKX3O0a/87omz8220dwXfMWeWhb08S6wlZvFxTrpNlh6JIsDMTMCi6a/q6LlBOQruH2sFjsyMWUJx
w2bmjsQzdbEH9QZBgw+s0wDfDWzsM0dzpnTlA9zgEg3iNsvF2iXMVFytt9HkLXudYPEbA==
-----END X509 CRL-----
# openssl crl -in crl -text -noout
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = IPA.EXAMPLE, CN = Certificate Authority
        Last Update: Dec 18 12:50:00 2018 GMT
        Next Update: Dec 18 13:00:00 2018 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                keyid:7C:A7:C1:DA:03:CA:E3:2B:A1:30:D2:6E:D5:C1:66:01:4A:2F:57:02

            X509v3 CRL Number:
                194
Revoked Certificates:
    Serial Number: 15
        Revocation Date: Dec 12 10:09:30 2018 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Superseded
    Serial Number: 16
        Revocation Date: Dec 17 14:35:55 2018 GMT
    Signature Algorithm: sha256WithRSAEncryption
         b1:ea:8d:f8:d5:83:3b:9c:2d:59:ae:22:ea:1a:fb:c9:bf:6d:
         71:68:af:7f:67:4b:36:43:b9:4e:a7:d8:93:96:0c:a0:4b:55:
         29:95:2c:3b:c1:9a:9a:a3:43:24:64:24:93:73:26:d8:3b:3a:
         1b:0a:4a:fc:47:2f:51:35:7d:96:6b:ac:b1:c7:7f:fa:30:e9:
         bd:6f:51:2c:39:62:23:8f:76:5a:9f:74:db:97:3b:07:a9:6c:
         e9:1d:fd:38:82:6c:45:b9:54:52:6d:b4:a3:05:13:bf:d6:c9:
         2f:20:88:5a:e6:c3:8d:9b:27:01:28:01:81:ab:88:d6:dc:8f:
         8d:0c:7e:51:a0:43:d5:33:04:cb:43:2c:13:41:f8:d3:0c:39:
         d0:4d:25:10:a5:f7:3b:46:bf:f3:ba:26:cf:cd:b6:d1:dc:17:
         7c:c5:9e:5a:16:f4:f1:2e:b0:95:9b:c5:c5:3a:e9:36:58:7a:
         24:8b:03:31:33:02:8b:a6:bf:ab:a2:e5:04:e4:2b:b8:7d:ac:
         16:3b:32:31:65:09:c7:0d:9b:9a:3b:10:cd:d6:c4:1f:d4:19:
         06:0c:3e:b3:4c:03:7c:35:b3:b0:cd:1d:ce:99:d3:94:0f:73:
         80:48:37:88:db:2f:17:68:97:31:51:72:b6:df:47:90:b5:ee:
         75:83:c4:6c
# ipa cert-show 0x15
...
  Serial number (hex): 0x15
  Revoked: True
  Revocation reason: 4

ipa-server-4.6.4-10.el7.x86_64 / pki-ca-10.5.9-6.el7.noarch also publish CRL to LDAP.

RHEL 7.5 with pki-ca-10.5.1-12.el7_5.noarch and ipa-server-4.5.4-10.el7_5.4.4.x86_64 also publishes the latest CRL to cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca, certificateRevocationList

I think LDAP storage is required so non-CRL renewal masters can serve CRLs. The Dogtag endpoint /ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL fetches the CRL from LDAP.

On a non-CRL master, the command curl -L http://$(hostname)/ipa/crl/MasterCRL.bin triggers the LDAP query SRCH base="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL.

Note to self: Dogtag only reads from LDAP when it initializes the CRLIssuingPoint object. Once the object is initizialized, the plugin never syncs back from LDAP.

This will cause the crl number to jump back:
- disabled MasterCRL on one server with OP_TYPE=OP_MODIFY&OP_SCOPE=crlIPs&id=MasterCRL&description=CRL&enable=false request to /ca/caadmin
- enable MasterCRL on another PKI clone
- reverse settings on both servers after a couple of CRLs have been generated by second server

@cheimes does this only affect generation? Does retrieving the updated CRL via the getCRL servlet always return the most recent CRL?

@cheimes I see it is just for the enable/disable behaviour. It should be a small change to force CRLIP to reinitialise itself from LDAP. I filed a ticket: https://pagure.io/dogtagpki/issue/3085

@cheimes FYI, PR to fix the errant Dogtag behaviour you described earlier:
https://github.com/dogtagpki/pki/pull/138

I'm closing this as "not a bug". Dogtag stores the master copy of its CRL in LDAP by design.

Metadata Update from @cheimes:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata