Web UI doesn't use any LDAP search directly. It uses API commands to do its work. The API command is equivalent the the CLI command written by Pavel. 

By checking cert-find, I think that it is the probable culprit:

    def _ldap_search(self, all, raw, pkey_only, no_members, timelimit,
                     sizelimit, **options):
        ldap = self.api.Backend.ldap2

        filters = []
        for owner in self.obj._owners():
            for prefix, rule in (('', ldap.MATCH_ALL),
                                 ('no_', ldap.MATCH_NONE)):
                try:
                    value = options[prefix + owner.name]
                except KeyError:
                    continue

                filter = ldap.make_filter_from_attr(
                    'objectclass',
                    owner.object_class,
                    ldap.MATCH_ALL)
                if filter not in filters:
                    filters.append(filter)

                filter = ldap.make_filter_from_attr(
                    owner.primary_key.name,
                    value,
                    rule)
                filters.append(filter)

I.e. it uses primary key. And in service.py there is:
    takes_params = (
        Principal(
            'krbcanonicalname',
            validate_realm,
            cli_name='canonical_principal',
            label=_('Principal name'),
            doc=_('Service principal'),
            primary_key=True,
            normalizer=normalize_principal,
            require_service=True
        ),

So the questions are:
 Is it an issue that cert-find uses krbcanonicalname in search?
 Is it an issue that there are services without krbcanonicalname?
   If yes, is the issue that upgrader probably doesn't upgrade those services?

Hi,

the issue is that in console the certificates are not shown. From the logs, I have seen that search. But I could be wrong and that search is used by another command. The truth is that the certificates are not shown in the services display.

If the krbcanonicalname is updated by some particular command but not by upgrader, that would explain the root cause of this bug.

if any client app, or command uses krbcanonicalname, well, we must have this attribute created first, imho.

The client app should not use krbcanonicalname at all, that is an implementation detail used by KDC to canonicalize principal aliases in AS_REQ.

The decision to change the primary key of service principals to krbcanonicalname was necessary to allow for creation of principal aliases for them.

I would say that in this case the `cert-find` command should use API calls to retrieve the owner objects instead of raw LDAP searches, that would make it independent on the presence of krbcanonicalname attribute.

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

Martin, 

could you, please, explain to me what you mean by "cert-find command should use API calls to retrieve the owner object"? Which should API calls be made?

Thanks

Fixed upstream
master:
https://pagure.io/freeipa/c/44bd5e358b027f8956b730f250854efb5087f05e
ipa-4-5:
https://pagure.io/freeipa/c/df1276e9daf9ee8db05538f47706855cb3d11e01

Verified.

'Owner Service' field is part of cert-show 

  Owner service: HTTP/bkr-hv03-guest34.testrelm.test

[root@bkr-hv03-guest34 ~]# rpm -q ipa-server
ipa-server-4.5.0-16.el7.x86_64
[root@bkr-hv03-guest34 ~]#

[root@bkr-hv03-guest34 ~]# ipa service-show HTTP/`hostname` 
  Principal name: HTTP/bkr-hv03-guest34.testrelm.test
  Principal alias: HTTP/bkr-hv03-guest34.testrelm.test
  Certificate: MIIDqzCCApOgAwIBAgIBEDANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMR4w
..
....
/qBT0oQPt9a6bRoYPat+dqGyaaFP8x2RkpEKF8bepU4Hyg7llrYo6OaERQ==
  Subject: CN=bkr-hv03-guest34.testrelm.test,O=TESTRELM.TEST
  Serial Number: 16
  Serial Number (hex): 0x10
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Thu Jun 08 14:41:22 2017 UTC
  Not After: Sun Jun 09 14:41:22 2019 UTC
  Fingerprint (SHA1): ae:ab:da:14:16:bd:2e:e4:48:61:a6:03:71:4c:24:9d:ed:fb:43:a1
  Fingerprint (SHA256): 56:03:33:94:a4:f1:95:07:aa:40:4d:14:9e:6a:71:5d:0a:2b:e1:e1:2a:9e:99:26:91:ff:f5:0f:5b:46:ed:2d
  Keytab: True
  Managed by: bkr-hv03-guest34.testrelm.test
[root@bkr-hv03-guest34 ~]# ipa cert-show 16
  Issuing CA: ipa
  Certificate: MIIDqzCCApOgAwIBAgIBEDANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMR4w
..
...
....
/qBT0oQPt9a6bRoYPat+dqGyaaFP8x2RkpEKF8bepU4Hyg7llrYo6OaERQ==
  Subject: CN=bkr-hv03-guest34.testrelm.test,O=TESTRELM.TEST
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Thu Jun 08 14:41:22 2017 UTC
  Not After: Sun Jun 09 14:41:22 2019 UTC
  Serial number: 16
  Serial number (hex): 0x10
  Revoked: False
  Owner service: HTTP/bkr-hv03-guest34.testrelm.test
[root@bkr-hv03-guest34 ~]#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2304