Bug 1685912

The issue happens because the entry can contain multiple certificates (entry_attrs['usercertificate'] is multi-valued), but the code is using only the first value to build the fields subject, serial_number, issuer, valid_not_before, valid_not_after etc..
See in the set_certificate_attrs method of ipaserver/plugins/server.py which is called in the post_callback method of service_show:

    if type(entry_attrs['usercertificate']) in (list, tuple):
        cert = entry_attrs['usercertificate'][0]
    else:
        cert = entry_attrs['usercertificate']
    entry_attrs['subject'] = unicode(DN(cert.subject))
    [...]

As ldap does not guarantee any ordering when returning multivalued attributes, we need to have a different strategy. It could be possible to read all the certificates and pick the one issued the most recently, for instance, and display the data for this one only.

Hi Thorsten,

there could be multiple ways to fix this issue, and I would like to get your opinion.

We could either keep the current interface, i.e. display information only for the one of the certs (= the most recent cert)
OR
display information for all the certificates.

In the first case, we need to agree on the way to pick the cert for which we want to display the information:
is it the one with the most recent not_valid_before (=date of issuance), or the one with the furthest expiration date?

In the second case, the CLI output could become heavy and we may want to show the info only when a --displaycertinfo param is provided. 

So what's your opinion on this?

Upstream ticket:
https://pagure.io/freeipa/issue/7878

(In reply to Florence Blanc-Renaud from comment #3)
> there could be multiple ways to fix this issue, and I would like to get your
> opinion.
> 
> We could either keep the current interface, i.e. display information only
> for the one of the certs (= the most recent cert)
> OR
> display information for all the certificates.

I think the output for the most recent cert is good enough.

> In the first case, we need to agree on the way to pick the cert for which we
> want to display the information:
> is it the one with the most recent not_valid_before (=date of issuance), or
> the one with the furthest expiration date?

Why not just the one with the higher serial number?

> In the second case, the CLI output could become heavy and we may want to
> show the info only when a --displaycertinfo param is provided.

The question is how to define most recent. Is it the one with the latest notBefore, or the latest notAfter?

It is likely the serial numbers will be randomized at some point, plus with multiple CA's issuing certs each with their own ranges this would favor one CA over others.

It's not clear how meaningful it would be to pick one cert over another beyond the most basic use case (one cert in an entry).

I'd rather propose not providing the output by default and adding a new option to show cert data and when that is provided then include the cert output for all certs.

This would be a rather disruptive change with a pretty major impacts to the web UI.

Rob had some good arguments. I did not think about randomized serials maybe even issued by different CA's.

I like the idea to not displaying the cert details by default and introduce a new option instead which has to be used to explictly request the cert related information. When this option is used we can then indeed show the data from all the certificates stored in the object.

RHEL-7.7 is already near the end of a Development Phase and development is being wrapped up. I am bulk-moving to RHEL 8 the Bugs which were already triaged, but to which we did not commit (without devel_ack) and we cannot keep them even as a stretch goal for RHEL-7.7.

If you believe this particular bug should be reconsidered for 7.7, please let us know.