CVE-2026-115221: Ipa: freeipa: freeipa uses subject cn as proof of certificate ownership
A flaw was found in FreeIPA. An improper authorization check allows an authenticated host to retrieve and revoke digital certificates assigned to other users or services. This issue occurs because FreeIPA verifies ownership solely by matching the host name to the certificate's subject Common Name (CN), without confirming actual ownership in the directory service. Consequently, an enrolled host can disrupt services by revoking certificates belonging to other entities.
Other sources
FreeIPA treats a certificate's final subject CN (Common Name) as proof that the matching host owns the certificate. Free IPA does not verify the certificate's LDAP owner or managed-by relationship. FreeIPA therefore lets the host retrieve an d revoke the certificate even when it belongs to another user or service and the normal permission check rejects the request. The host needs a valid host credential and a readable serial number for an IPA-issued certificate. The host name must exactly match the certificate's final subject CN, including letter case. FreeIPA exposes certificate serial numbers in metadata that an authenticated host can read.
Impact An enrolled host normally manages only its own certificates or certificates delegated through a managed-by relationship. The same host can retrieve and revoke an IPA CA certificate assigned to another user, host, or service. The CA marks that certificate revoked without its owner's permission.
What I verified I tested FreeIPA 4.13.4, release-4-13-4, with the default IPA CA and the default certificate permission rules. I used a host principal that was not a member of Certificate Administrators or Host Administrators. I created one test certificate for a user and another for a service managed by a different host. I read the certificate serial number from metadata available to the host. I authenticated as the matching host and ran cert-show. FreeIPA returned a certificate that belonged to the other identity. I then ran cert-revoke with reason 6. Dogtag, the CA backend, marked the certificate revoked. I ran cert-revoke with reason 8, which asks the CA to remove the certificate from the revocation list. Dogtag reported the certificate as no longer revoked. As a non-matching host, I tried the same retrieval and revocation. FreeIPA rejected both requests. As the matching host, I also tried the separate cert-remove-hold command. FreeIPA rejected that command. I repeated the test with a service certificate managed by a different host. FreeIPA returned and revoked that certificate.
Why this happens After the normal permission check rejects a request, FreeIPA calls bindprincipalcanmanagecert(). The function checks only whether the caller is a host principal and whether the host name equals the certificate's final subject CN. The function does not compare the caller with the certificate owner or managed-by relationship https://github.com/freeipa/freeipa/blob/release-4-13-4/ipaserver/plugins/cert.py#L325-L348. cert-show uses the result of that function to return the certificate. FreeIPA reads the LDAP owner only after making this authorization decision https://github.com/freeipa/freeipa/blob/release-4-13-4/ipaserver/plugins/cert.py#L1475-L1518. cert-revoke uses the same function before asking Dogtag to change the certificate's revocation status https://github.com/freeipa/freeipa/blob/release-4-13-4/ipaserver/plugins/cert.py#L1559-L1588.
— Red Hat