IPA's PKI instance publishes latest CRL to LDAP although LDAP publishing should be disabled by default.
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==
I was under the impression that IPA disables LDAP publishing of CRLs by default.
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
-----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
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.
/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL
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.
curl -L http://$(hostname)/ipa/crl/MasterCRL.bin
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
OP_TYPE=OP_MODIFY&OP_SCOPE=crlIPs&id=MasterCRL&description=CRL&enable=false
/ca/caadmin
@cheimes does this only affect generation? Does retrieving the updated CRL via the getCRL servlet always return the most recent CRL?
getCRL
@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)
Login to comment on this ticket.