Hi Sam,
On pe, 17 joulu 2021, Sam Morris wrote:
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
/etc/httpd/conf.d/ipa-pki-proxy.conf.
>
> 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
reproduced https://bugzilla.redhat.com/show_bug.cgi?id=2006070 after
all.
I have:
@ 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-
2.module+el8.5.0+12735+8eb38ccc.noarch.
This upgrade modified server.xml, replacing requiredSecret="oldSecret"
with secret="oldSecret".
Per https://bugzilla.redhat.com/show_bug.cgi?id=2006070 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.
Looking through
https://github.com/freeipa/freeipa/blob/56e4f33ce630a6a310518f25b67d46fb31f7919e/ipaserver/install/dogtaginstance.py#L351
... 'tomcat version' would have been 9.0.30.0, 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=
attribute.
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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
