Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there. I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
many thanks, L
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 14/09/2021 14:13, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
on renewing master: -> $ getcert list | grep status # all are MONITORING But I think I missed it first time. md5s of: userCertificate:: from -> $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no and -> $ cat /var/lib/ipa/ra-agent.pem | grep -v '--' | _my._sed-joinLines.sh are different which, if I get it right, means that those are different certificates, right? And if yes then how to know which one is the right one?
thanks, L.
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 14/09/2021 15:11, lejeczek via FreeIPA-users wrote:
On 14/09/2021 14:13, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
on renewing master: -> $ getcert list | grep status # all are MONITORING But I think I missed it first time. md5s of: userCertificate:: from -> $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no and -> $ cat /var/lib/ipa/ra-agent.pem | grep -v '--' | _my._sed-joinLines.sh are different which, if I get it right, means that those are different certificates, right? And if yes then how to know which one is the right one?
thanks, L.
But then when I do 'openssl x509 -noout -text -in' on what is in ldap then that & '/var/lib/ipa/ra-agent.pem' then it seems to be the same one certificate. I'm about to get really confused... :) (..so md5s do not work on pem files?)
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
lejeczek via FreeIPA-users wrote:
On 14/09/2021 15:11, lejeczek via FreeIPA-users wrote:
On 14/09/2021 14:13, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
on renewing master: -> $ getcert list | grep status # all are MONITORING But I think I missed it first time. md5s of: userCertificate:: from -> $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no and -> $ cat /var/lib/ipa/ra-agent.pem | grep -v '--' | _my._sed-joinLines.sh are different which, if I get it right, means that those are different certificates, right? And if yes then how to know which one is the right one?
thanks, L.
You mentioned you did this on the renewal server. Is this the same server that is throwing the 403?
But then when I do 'openssl x509 -noout -text -in' on what is in ldap then that & '/var/lib/ipa/ra-agent.pem' then it seems to be the same one certificate. I'm about to get really confused... :) (..so md5s do not work on pem files?)
PEM files are just ASCII text.
rob
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 14/09/2021 20:00, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
On 14/09/2021 15:11, lejeczek via FreeIPA-users wrote:
On 14/09/2021 14:13, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
on renewing master: -> $ getcert list | grep status # all are MONITORING But I think I missed it first time. md5s of: userCertificate:: from -> $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no and -> $ cat c | grep -v '--' | _my._sed-joinLines.sh are different which, if I get it right, means that those are different certificates, right? And if yes then how to know which one is the right one?
thanks, L.
You mentioned you did this on the renewal server. Is this the same server that is throwing the 403?
Yes, it's a primitive two-master setup, both masters fail with 'Unable to communicate with CMS (403)' So I presume ultimate is what I get from: putting what I get from $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no into a file and fixing it with begin/end in order to have it a .pem, then I do 'openssl' on such .pem file. then what I get from $ openssl x509 -noout -text -in openssl x509 -noout -text -in Then I 'diff' two 'openssl' outputs - if this how to ultimately tell then - it's the same cert, mining 'diff' sees no difference. All this I have done on only the renewal master, as of yet.
many thanks, L.
But then when I do 'openssl x509 -noout -text -in' on what is in ldap then that & '/var/lib/ipa/ra-agent.pem' then it seems to be the same one certificate. I'm about to get really confused... :) (..so md5s do not work on pem files?)
PEM files are just ASCII text.
rob
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
lejeczek via FreeIPA-users wrote:
On 14/09/2021 20:00, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
On 14/09/2021 15:11, lejeczek via FreeIPA-users wrote:
On 14/09/2021 14:13, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
Hi guys.
I get:
-> $ ipa host-del c8kubernode1.private.lot ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
-> $ ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)
I searched mailing list and what I found about certs being out or in sync I checked, I verified but it's still possible I missed something there.
You checked and verified what?
on renewing master: -> $ getcert list | grep status # all are MONITORING But I think I missed it first time. md5s of: userCertificate:: from -> $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no and -> $ cat c | grep -v '--' | _my._sed-joinLines.sh are different which, if I get it right, means that those are different certificates, right? And if yes then how to know which one is the right one?
thanks, L.
You mentioned you did this on the renewal server. Is this the same server that is throwing the 403?
Yes, it's a primitive two-master setup, both masters fail with 'Unable to communicate with CMS (403)' So I presume ultimate is what I get from: putting what I get from $ ldapsearch -D cn=directory\ manager -b uid=ipara,ou=people,o=ipaca -LLL -o ldif-wrap=no into a file and fixing it with begin/end in order to have it a .pem, then I do 'openssl' on such .pem file. then what I get from $ openssl x509 -noout -text -in openssl x509 -noout -text -in Then I 'diff' two 'openssl' outputs - if this how to ultimately tell then - it's the same cert, mining 'diff' sees no difference. All this I have done on only the renewal master, as of yet.
Try installing and running ipa-healthcheck. It will check for this type of mismatch.
rob
many thanks, L.
But then when I do 'openssl x509 -noout -text -in' on what is in ldap then that & '/var/lib/ipa/ra-agent.pem' then it seems to be the same one certificate. I'm about to get really confused... :) (..so md5s do not work on pem files?)
PEM files are just ASCII text.
rob
I also see this: https://access.redhat.com/solutions/3624671 - which I thought was a bit dated issue thus I want to ask: Should that be in ipa-server-4.9.6-4 ? because my '/etc/httpd/conf.d/ipa-pki-proxy.conf' indeed lacks "^/ca/rest/account/login...
It's unfortunate that the article says it applies to 4.X which is quite a broad reach.
The matching expression was greatly simplified. I don't believe this is related.
rob
many thanks, L _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Could you check if your "requiredSecret" value matches the "secret" in "/etc/pki/pki-tomcat/server.xml"? I had two lines where they were different and the value has to match the secret in "/etc/httpd/conf.d/ipa-pki-proxy.conf". Once they all matched I restarted pki-tomcatd@pki-tomcat.service and httpd and both CLI and WebGUI certificate management worked again. According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'." I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'."
https://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes
I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
I can confirm this behavior. After update from 4.9.3 to 4.9.6 on CentOS 8 Stream I had two entries in <Connector ... /> - 'requiredSecret' with the correct password and 'secret' with wrong password. Thanks for pointing me to the right direction!
Dirk Silkenbäumer via FreeIPA-users wrote:
According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'."
https://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes
I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
I can confirm this behavior. After update from 4.9.3 to 4.9.6 on CentOS 8 Stream I had two entries in <Connector ... /> - 'requiredSecret' with the correct password and 'secret' with wrong password. Thanks for pointing me to the right direction!
Hmm, not good. Any chance you have an old set of config files you can pass me out-of-band, with the passwords obfuscated obviously, so I can see what went wrong with the upgrade process?
rob
On 17/09/2021 16:28, Rob Crittenden via FreeIPA-users wrote:
Dirk Silkenbäumer via FreeIPA-users wrote:
According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'."
https://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes
I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
I can confirm this behavior. After update from 4.9.3 to 4.9.6 on CentOS 8 Stream I had two entries in <Connector ... /> - 'requiredSecret' with the correct password and 'secret' with wrong password. Thanks for pointing me to the right direction!
Hmm, not good. Any chance you have an old set of config files you can pass me out-of-band, with the passwords obfuscated obviously, so I can see what went wrong with the upgrade process?
I see in: /etc/pki/pki-tomcat/server.xml
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost4" name="Connector1" secret="a...some_Btdh" requiredSecret="b...some_W2yFo"/> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost6" name="Connector2" secret="a...some_Btdh" requiredSecret="b...some_W2yFo"/>
and in my: /etc/httpd/conf.d/ipa-pki-proxy.conf all 'secret' entries are secret=a...some_Btdh
just to have it cleared - both 'secret' & 'requiredSecret' must be present in '/etc/pki/pki-tomcat/server.xml' ?
ps. with applied fix, thought origianal error(s) is gone I still get: -> $ ipa-healthcheck Internal error testing KRA clone. KRA clone problem detected Host: c8kubermaster2.private.lot Port: 443 [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "da1224dc-9caf-49f7-9f77-fcfa2991da78", "when": "20210917193316Z", "duration": "1.646698", "kw": { "status": "ERROR: pki-tomcat : Internal error testing KRA clone. Host: c8kubermaster2.private.lot Port: 443" }
can that be related?
many thanks, L.
rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Sep 17, 2021 at 9:35 PM lejeczek via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
[...] ps. with applied fix, thought origianal error(s) is gone I still get: -> $ ipa-healthcheck Internal error testing KRA clone. KRA clone problem detected Host: c8kubermaster2.private.lot Port: 443 [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "da1224dc-9caf-49f7-9f77-fcfa2991da78", "when": "20210917193316Z", "duration": "1.646698", "kw": { "status": "ERROR: pki-tomcat : Internal error testing KRA clone. Host: c8kubermaster2.private.lot Port: 443" }
can that be related?
This is a known issue: https://pagure.io/freeipa/issue/8582 / https://github.com/freeipa/freeipa-healthcheck/issues/212 / https://github.com/dogtagpki/pki/issues/3608
HTH, flo
On 17/09/2021 13:35, pp via FreeIPA-users wrote:
Could you check if your "requiredSecret" value matches the "secret" in "/etc/pki/pki-tomcat/server.xml"? I had two lines where they were different and the value has to match the secret in "/etc/httpd/conf.d/ipa-pki-proxy.conf". Once they all matched I restarted pki-tomcatd@pki-tomcat.service and httpd and both CLI and WebGUI certificate management worked again. According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'." I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
I too can confirm that this is the issue and the fixed worked. many! thanks. L.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
lejeczek via FreeIPA-users wrote:
On 17/09/2021 13:35, pp via FreeIPA-users wrote:
Could you check if your "requiredSecret" value matches the "secret" in "/etc/pki/pki-tomcat/server.xml"? I had two lines where they were different and the value has to match the secret in "/etc/httpd/conf.d/ipa-pki-proxy.conf". Once they all matched I restarted pki-tomcatd@pki-tomcat.service and httpd and both CLI and WebGUI certificate management worked again. According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'." I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps.
I too can confirm that this is the issue and the fixed worked. many! thanks.
The strange thing is this upgrade code has been in IPA since 4.9.0 so its unclear why it decided to break now, and in the way it did.
It should only change the attribute from requiredSecret to secret if "tomcat version" reports a version >= 9.0.31.0.
Another user told me that starting pki with the requiredSecret name it is getting renamed to secret. I'll check with the pki team to see if they do any of their own renaming of it.
rob
The strange thing is this upgrade code has been in IPA since 4.9.0 so its unclear why it decided to break now, and in the way it did.
It should only change the attribute from requiredSecret to secret if "tomcat version" reports a version >= 9.0.31.0.
Yes, I noticed the python function returns the correct value (false) when checking for my tomcat version and should use "requiredSecret" as a result.
pp via FreeIPA-users wrote:
The strange thing is this upgrade code has been in IPA since 4.9.0 so its unclear why it decided to break now, and in the way it did.
It should only change the attribute from requiredSecret to secret if "tomcat version" reports a version >= 9.0.31.0.
Yes, I noticed the python function returns the correct value (false) when checking for my tomcat version and should use "requiredSecret" as a result.
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.
rob
Thank you. Just to clarify I currently have both "secret" and "requiredSecret" set. Originally "requiredSecret" did not match the ipa secret while "secret" did. I changed "requiredSecret" to also match to fix my issue.
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2006070 against pki-core.
latest update with: ipa-server.x86_64 4.9.6-6.module_el8.5.0 pki-server.noarch 10.11.2-2.module_el8.5.0
has the same issue
Best Dirk
Dirk Silkenbäumer via FreeIPA-users wrote:
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2006070 against pki-core.
latest update with: ipa-server.x86_64 4.9.6-6.module_el8.5.0 pki-server.noarch 10.11.2-2.module_el8.5.0
has the same issue
The BZ is still in NEW state. It hasn't been worked on yet.
rob
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...
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.
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%C2%A0against 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/56e4f33ce630a6a310518f25b67d46fb31f7... ... '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.
I'll bear that in mind if there are any more ipa-server updates before pki-base is fixed.
Thanks :)
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%C2%A0against 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/56e4f33ce630a6a310518f25b67d46fb31f7... ... '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.
On Fri, 2021-09-17 at 12:35 +0000, pp via FreeIPA-users wrote:
Could you check if your "requiredSecret" value matches the "secret" in "/etc/pki/pki-tomcat/server.xml"? I had two lines where they were different and the value has to match the secret in "/etc/httpd/conf.d/ipa-pki-proxy.conf". Once they all matched I restarted pki-tomcatd@pki-tomcat.service and httpd and both CLI and WebGUI certificate management worked again. According to a different thread "tomcat pre-9.0.31.0 uses 'requiredSecret' and afterward uses 'secret'." I am running my FreeIPA server on CentOS 8 Stream which uses tomcat 9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which "broke" the config for the tomcat version used. Hope this helps. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
I can confirm that I ran in this issue on CentOS Stream 8 and this solution works.
Hi Antonie,
I've checked requiredSecret and secret values in the files you indicated. They are matching. My installations are fresh, I didn't upgrade from previous versions. I'm going to backup nssdb and reinitialize it, maybe it works. Regards,
Antoine Gatineau via FreeIPA-users freeipa-users@lists.fedorahosted.org, 17 Eki 2021 Paz, 18:07 tarihinde şunu yazdı:
On Fri, 2021-09-17 at 12:35 +0000, pp via FreeIPA-users wrote:
Could you check if your "requiredSecret" value matches the "secret" in
"/etc/pki/pki-tomcat/server.xml"?
I had two lines where they were different and the value has to match the
secret in "/etc/httpd/conf.d/ipa-pki-proxy.conf". Once they all matched I restarted pki-tomcatd@pki-tomcat.service and httpd
and both CLI and WebGUI certificate management worked again. According to a different thread "tomcat pre-9.0.31.0 uses
'requiredSecret' and afterward uses 'secret'."
I am running my FreeIPA server on CentOS 8 Stream which uses tomcat
9.0.30. My uninformed guess is the last FreeIPA update from 4.9.3 to 4.9.6 configured "secret" only and not "requiredSecret" which
"broke" the config for the tomcat version used. Hope this helps. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to
freeipa-users-leave@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.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
I can confirm that I ran in this issue on CentOS Stream 8 and this solution works.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Antoine Gatineau -
Dirk Silkenbäumer -
Florence Renaud -
lejeczek -
pp -
Rob Crittenden -
Sam Morris -
Çiçek Adam