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.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.