Bug 2559043 (CVE-2026-115221) - CVE-2026-115221 ipa: freeIPA: FreeIPA uses subject CN as proof of certificate ownership
Summary: CVE-2026-115221 ipa: freeIPA: FreeIPA uses subject CN as proof of certificate...
Keywords:
Status: NEW
Alias: CVE-2026-115221
Deadline: 2026-10-23
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-22 14:27 UTC by OSIDB Bzimport
Modified: 2026-10-22 14:40 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-22 14:27:57 UTC
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 bind_principal_can_manage_cert(). 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.


Note You need to log in before you can comment on or make changes to this bug.