I do see those messages even without changing the trust of CA signing cert. I installed CA and checked journatctl

[root@ipaqavmf ~]# journalctl -xe | grep  NO_SUCH_USER
Aug 18 14:34:37 ipaqavmf.idmqe.lab.eng.bos.redhat.com server[6324]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER.  This may not be a latest instance.  Ignoring ..
[root@ipaqavmf ~]# journalctl -xe | grep  entryUSN
Aug 18 14:34:40 ipaqavmf.idmqe.lab.eng.bos.redhat.com server[6324]: CMS Warning: FAILURE: Authority entry has no entryUSN.  This is likely because the USN plugin is not enabled in the database|
[root@ipaqav

I've investigated the entryUSN issue - I think if can happen if the USN plugin
gets enabled after the entry in question is created.  As long as the USN
plugin is enabled this is not actually a problem.  The proposed fix is, if
entry is missing entryUSN attribute, to check if the DS USN plugin is enabled.
We will print the warning only if it is not enabled.

I believe alee is investigating the NO_SUCH_USER message.

We probably need the fix that ftweedal suggests above for the case where we have migrated data.  But I'm a little confused ---  based on the code in SystemConfigService.java (line 765), it seems  like one of the first things we do is enable the USN plugin.  So I'm not sure how a CA entry would occur ..

The NO_SUCH_USER error message is benign.  Its been around forever and can be ignored.

Cherry-picked into DOGTAG_10_3_RHEL_BRANCH:

From 8e0235adccb11868f0036d48d2b52230c82b3e6b Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <ftweedal>
Date: Wed, 24 Aug 2016 14:10:55 +1000
Subject: [PATCH 8/9] Perform host authority check before entryUSN check

When processing lightweight CAs, currently we perform the entryUSN
check before the host authority check.  If the entry does not have
an entryUSN attribute, and if the DS USN plugin is not enabled, the
entry gets skipped and we do not reach the host authority check.
This causes the CA to believe that it has not seen the host
authority entry, and results in additional entries being added.

Move the host authority check before the entryUSN check to avoid
this scenario.

Fixes: https://fedorahosted.org/pki/ticket/2444
(cherry picked from commit e457cb8367f39562a844229ddb9da9c3a46d9611)
(cherry picked from commit 3a97c5fc0df7015a7e19236778089c67441a1499)


From 06a85c76938211d6ecf2b49ac72b168e9f6e7fdd Mon Sep 17 00:00:00 2001
From: Fraser Tweedale <frase.au>
Date: Tue, 23 Aug 2016 14:50:03 +1000
Subject: [PATCH 7/9] Accept LWCA entry with missing entryUSN if plugin enabled

Currently we abort adding a lightweight CA if its entry does not
have an 'entryUSN' attribute, and log a failure, even if the USN
plugin is enabled.  But if the plugin is enabled, it's fine to
proceed.

Update the authority monitor to check if the USN plugin is enabled
and only log the failure if it is not.  Clarify the log message
accordingly.

Part of: https://fedorahosted.org/pki/ticket/2444

(cherry picked from commit d1aa1ec049d7cb5beed9ba79b09930a90a3c51fe)
(cherry picked from commit 21e268ae6d5f9c2f93d4d80a6285e453974b5c07)

[root@cypher ~]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.3.3
Release     : 10.el7
Architecture: noarch
Install Date: Tue 13 Sep 2016 09:58:32 AM EDT
Group       : System Environment/Daemons
Size        : 2431460
License     : GPLv2
Signature   : (none)
Source RPM  : pki-core-10.3.3-10.el7.src.rpm
Build Date  : Sat 10 Sep 2016 02:18:45 AM EDT
Build Host  : ppc-042.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority


Verification steps

1. Install CA with defaults
2. [root@cypher ~]# journalctl | grep entryUSN
[root@cypher ~]# journalctl | grep NO_SUCH_USER
Sep 13 11:22:19 cypher.idmqe.lab.eng.bos.redhat.com server[23189]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER.  This may not be a latest instance.  Ignoring ..
Sep 13 11:39:42 cypher.idmqe.lab.eng.bos.redhat.com server[24503]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER.  This may not be a latest instance.  Ignoring ..
Sep 15 11:00:27 cypher.idmqe.lab.eng.bos.redhat.com server[31536]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER.  This may not be a latest instance.  Ignoring ..

Based on comment 5 marking the bug verified

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://rhn.redhat.com/errata/RHBA-2016-2396.html