On Fri, 2021-12-17 at 06:59 +0200, Alexander Bokovoy wrote:
> On to, 16 joulu 2021, Sam Morris via FreeIPA-users wrote:
> > > The CA has its own upgrade code which runs unconditionally and I think
> > > that's how both secret and requiredSecret got added to server.xml. I
> > > wasn't able to duplicate the 403 though, it always just worked for me.
> > > Perhaps it has to go through more than one upgrade cycle. I did my
> > > testing on RHEL 8.
> > >
> > > I filed https://bugzilla.redhat.com/show_bug.cgi?id=2006070 against
> > > pki-core.
> > I think I just ran into this, or a related issue, when upgrading today on two
RHEL 8 machines.
> > According to etckeeper (great tool!):
> > Package changes:
> > -0:ipa-client-4.9.6-6.module+el8.5.0+12660+88e16a2c.x86_64
> > -0:ipa-client-common-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > -0:ipa-common-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > +0:ipa-client-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
> > +0:ipa-client-common-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > +0:ipa-common-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > -0:ipa-server-4.9.6-6.module+el8.5.0+12660+88e16a2c.x86_64
> > -0:ipa-server-common-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > -0:ipa-server-dns-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > +0:ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
> > +0:ipa-server-common-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > +0:ipa-server-dns-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > -0:python3-ipaclient-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > -0:python3-ipalib-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > -0:python3-ipaserver-4.9.6-6.module+el8.5.0+12660+88e16a2c.noarch
> > +0:python3-ipaclient-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > +0:python3-ipalib-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > +0:python3-ipaserver-4.9.6-10.module+el8.5.0+13587+92118e57.noarch
> > Upgrading the above *added* requiredSecret="newSecret" to the AJP
Connector elements within /etc/pki/pki-tomcat/server.xml.
> > The existing secret="oldSecret" attribute was not changed. Neither was
"secret=oldSecret" changed in the ProxyPassMatch directives in
> > It looks like tomcat uses the value of requiredSecret= in preference to secret=
if both are supplied.
> > The fix was to remove requiredSecret="newSecret" from the tomcat
config file & restart pki-tomcatd@pki-tomcat.
> > But that bugzilla is about migrating from requiredSecret="oldSecret"
-> secret="oldSecret". So I'm not sure I've hit that bug exactly...
> The packages above aren't including any additional patches related to
> what you see here. They only include changes for CVE-2020-25717 which
> has nothing to do with CA operations.
> What happens, I suspect, is that both pki upgrade code and ipa upgrade
> code triggered and pki upgrade code adds 'requiredSecret' part. IPA
> upgrade code is present since FreeIPA 4.9.0, since March 2020, more than
> 1.5 years ago.
Ok. Piecing together the timeline, I think I have merely
@ 2021-11-12 01:31
[root@ipa5 ~]# cat /var/log/pki/pki-upgrade-10.11.2.log
Upgrading PKI system configuration at Fri 12 Nov 01:31:11 UTC 2021.
... corresponds with the upgrade of pki-base-10.10.5-
3.module+el8.4.0+11039+635979e4.noarch -> pki-base-10.11.2-
This upgrade modified server.xml, replacing requiredSecret="oldSecret"
this should not
have happened. Because it breaks the assumption in ipa-server-upgrade
that Tomcat >= 0.9.31.0 performs this replacement.
@ 2021-12-16 09:33
This is the upgrade where ipa-server-upgrade ran, which added
requiredSecret="newSecret" to server.xml which broke (communication
with) the CA subsystem.
... 'tomcat version' would have been 188.8.131.52, so secretattr and
oldattr would both be 'requiredSecret'; since, at this time, server.xml
did not have a requiredSecret=, only a secret=, the code code generated
a new secret and set it as the value of a new requiredSecret=
Phew, that took some digging!
As for the fix I made to server.xml, it would just be reverted by ipa-
server-upgrade, until the fixed pki-base is installed.
May be we need to fix our logic when checking the connectors now.
Needless to say, this is not reproducible in Fedora which already has
both newer PKI and newer IPA.
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland