freeipa

#6530 service and host plugins do not handle userCertificate;binary attribute
Opened by ftweedal. Modified

Open
Close Issue

the service and host plugins currently write, and expect to find,
the userCertificate. But RFC 4523 requires this attribute to have the
binary encoding attribute, i.e. userCertificate;binary.

Currently, DS returns the attribute with or without the option, depending
on how it was first written. But there is a ticket to make DS comply with
the RFC, meaning it will always return with ;binary and thus the service
and host plugins will not be able to read the attribute.

Furthermore, if some other software adds certificates to a host or service in a
compliant way, FreeIPA will not be able to see it.

Furthermore, if we fix this in a future version of IPA (#6529), older server
versions will not be able to see it. So something would need to be backported.

5173 addressed this problem for user principals.

related DS ticket: https://fedorahosted.org/389/ticket/49059

There are 4 possible combinations if the usercertificate attribute is stored with/without ';binary' and retrieve with/without ';binary'.

I think there is one problematic case that is if the attribute value is stored without ';binary' and is retrieved with 'binary'

ldapmodify -D "cn=directory manager" -w password
dn: cn=account18,cn=account,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: pkiuser
modifying entry "cn=account18,cn=account,dc=example,dc=com"
dn: cn=account18,cn=account,dc=example,dc=com
changetype: modify
add: usercertificate;binary
usercertificate;binary: value with binary
-
add: usercertificate
usercertificate: value without binary
modifying entry "cn=account18,cn=account,dc=example,dc=com"
ldapsearch -D "cn=directory manager" -w xxx -LLL -b "dc=example,dc=com" 'cn=account18' "userCertificate"
dn: cn=account18,cn=account,dc=example,dc=com
userCertificate: value without binary
userCertificate;binary:: dmFsdWUgd2l0aCBiaW5hcnk=
ldapsearch -D "cn=directory manager" -w xxx -LLL -b "dc=example,dc=com" 'cn=account18' "userCertificate;binary"
dn: cn=account18,cn=account,dc=example,dc=com
userCertificate;binary:: dmFsdWUgd2l0aCBiaW5hcnk=

Until https://fedorahosted.org/389/ticket/49059 is fixed, client applications should retrieve usercertificate without specifying ';binary'. Else they will miss usercertificate values stored without ';binary'

An other issue exists usercertificate is part of the filter, result are not coherent:

ldapsearch -D "cn=directory manager" -w password -LLL -b "dc=example,dc=com" 'userCertificate=value without binary' dn
dn: cn=account18,cn=account,dc=example,dc=com
ldapsearch -D "cn=directory manager" -w password -LLL -b "dc=example,dc=com" 'userCertificate=value with binary' dn
dn: cn=account18,cn=account,dc=example,dc=com
ldapsearch -D "cn=directory manager" -w password -LLL -b "dc=example,dc=com" 'userCertificate;binary=value without binary' dn
<empty>
ldapsearch -D "cn=directory manager" -w password -LLL -b "dc=example,dc=com" 'userCertificate;binary=value with binary' dn
dn: cn=account18,cn=account,dc=example,dc=com

Until ​https://fedorahosted.org/389/ticket/49059 is fixed, client applications should filter usercertificate without specifying ';binary'.

the set of CLI/web around user is using userCertificate;binary. Both in storage and lookup. It looks coherent. But it exists entries with 'certificate', so there is a risk of incoherence although I have not found a use case:

dn: krbprincipalname=ldap/<fqdn>@<domain>,cn=services,cn=accounts,<suffix>
usercertificate:: MIIEpDCCA4ygAw....
dn: krbprincipalname=HTTP/<fqdn>@<domain>,cn=services,cn=accounts,<suffix>
usercertificate:: MIIEpDCCA4ygAw...
dn: uid=x1,cn=users,cn=accounts,<suffix>                                                                              
userCertificate;binary:: MIIEUDCCAzigAw....

Metadata Update from @ftweedal:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5 backlog
Metadata
None
None
None
Normal
defect
IPA
None
0
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.