freeipa

#9505 ipa cert-revoke command does not update CRL when ran from clients
Closed: worksforme by rcritten. Opened by daanbc.

Closed: worksforme
Reopen Issue

Issue

We use the ipa cert-revoke command to revoke user certificates. When we run this command on the master everything goes well, however when we run it from a client the command appears to work correctly (including a REVOKED status in the GUI) however the certificate never actually gets added to the Certificate Revocation List.

Steps to Reproduce

  1. Create a certificate for a user (using ipa-certrequest)
  2. ssh to a client server
  3. kinit admin
  4. ipa cert-revoke <Serial Number> --revocation-reason=4 # outputs: "Revoked: true"
  5. ipa-crlgen-manage disable ; ipa-crlgen-manage enable # force CSP to be regenerated
  6. wget https://ipa.example.com/ipa/crl/MasterCRL.bin
  7. openssl crl -in MasterCRL.bin -text -noout # the output has a refreshed date but revoked certificate is not present

Actual behavior

The certificate is shown as REVOKED in the GUI but the regenerated CRL does not contain the revoked certificate.

The exact same CLI steps on master do work as expected and revoking through the GUI also works as expected.

Expected behavior

ipa cert-revoke should either throw an error or perform all required actions.

Version/Release/Distribution

Master

The master runs on the following docker image: freeipa/freeipa-server:fedora-39-4.11.0

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

freeipa-server-4.11.0-7.fc39.x86_64
freeipa-client-4.11.0-7.fc39.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-2.4.4-1.fc39.x86_64
package pki-ca is not installed
krb5-server-1.21.2-2.fc39.x86_64

Clients

The clients run on Ubuntu 20.04, IPA version 4.8.6.

All commands are executed on an IPA server so there should be no difference where the request came from.

If you want to force CRL generation, while disabling and re-enabling via ipa-crlgen-manage is certainly clever, there is a PKI XML endpoint for it which doesn't require restarting the CA twice in a row.

curl -v https://ipa.example.test:8443/ca/agent/ca/updateCRL --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key

This will be both more efficient and reliable.

All commands are executed on an IPA server so there should be no difference where the request came from.

Indeed it is a very unexpected behavior and moreover it is strange that IPA does show the certificates as revoked through the GUI and the CLI, they just never get added to the CRL if the command ran from a client.

If you want to force CRL generation, while disabling and re-enabling via ipa-crlgen-manage is certainly clever, there is a PKI XML endpoint for it which doesn't require restarting the CA twice in a row.

That's good to know, thanks. Although I think it shouldn't affect the contents of the CRL.

I can't reproduce the behavior you are seeing. When I revoke a cert and force a CRL update (using curl) then regardless of where the revocation request originated.

Metadata Update from @rcritten:
- Custom field affects_doc adjusted to on
- Custom field knownissue adjusted to on
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)

I may be seeing this. I'll try to debug in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/DL3HTLSR446OAMM5HT5RUQMIL4DHNXOE/

If you have something reproduce I'd recommend opening a JIRA case against pki-core. IPA only configures CRL generation. Beyond that it doesn't have a hand in it.

Done, at https://issues.redhat.com/browse/RHEL-30280

The findings are that ipa-crlgen-manage should remove the value of ca.certStatusUpdateInterval when setting a server as the CRL generator. The man page could include this detail as well, along with the other changes, for future troubleshooting.
Metadata
None
None
None
None
None
on
on
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.