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.
userCertificate
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.
;binary
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
Login to comment on this ticket.