Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
*** EXTERNAL E-MAIL ***
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two hosts that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
BTW, healthcheck uses this url to get that PKI info.
http://localhost:8080/ca/rest/securityDomain/domainInfo
How can I get rid of the two old hosts?
On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
*** EXTERNAL E-MAIL ***
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two hosts that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
CA replica management is done with 'ipa-csreplica-manage' tool, not 'ipa-replica-manage'.
On 29-05-2021 10:21, Alexander Bokovoy wrote:
On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two hosts that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
CA replica management is done with 'ipa-csreplica-manage' tool, not 'ipa-replica-manage'.
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
So, two things 1) "ipa-csreplica-manage del" somehow failed (it's probably too late to look at logs) 2) how can I still remove the old hosts?
Kees Bakker via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two hosts that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
CA replica management is done with 'ipa-csreplica-manage' tool, not 'ipa-replica-manage'.
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to
look at logs) 2) how can I still remove the old hosts?
I'm not sure how to remove hosts from the CA-managed security domain but you can show the hosts it knows about with pki securitydomain-show to confirm that this is where it is finding the old one.
This check is provided by dogtag and executed within ipa-healthcheck. Can you open a ticket on it at https://github.com/dogtagpki/pki/
rob
On 01-06-2021 18:01, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote:
Hi,
After installing a new replica and running
/usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data
I'm getting this error
keyctl_search: Required key not available Enter password for Internal Key Storage Token: Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fc473262a90>: Failed to establish a new connection: [Errno 113] No route to host',)) [ { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", "when": "20210528150818Z", "duration": "30.348789", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: iparep3.ghs.nl Port: 443" } } ]
First, it is asking for a password, and I have no clue for what. I've tried the admin password and the Directory Manager password. It makes no difference.
Second, it tries to connect to a replica that was removed several months ago. Both ipa-replica-manage list and ipa-csreplica-manage show the correct list of masters that we currently have.
Where does ipa-healthcheck get the information from to query the removed replica?
BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The first two give this healthcheck error, the centos7 master does not.
That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two hosts that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
CA replica management is done with 'ipa-csreplica-manage' tool, not 'ipa-replica-manage'.
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to
look at logs) 2) how can I still remove the old hosts?
I'm not sure how to remove hosts from the CA-managed security domain but you can show the hosts it knows about with pki securitydomain-show to confirm that this is where it is finding the old one.
This check is provided by dogtag and executed within ipa-healthcheck. Can you open a ticket on it at https://github.com/dogtagpki/pki/
rob
Hi, I'm not sure the issue is really on PKI side. On ipa server-del call, IPA should also make sure to call something similar to pki securitydomain-host-del to make sure that the host is removed from PKI security domain.
This was tracked in BZ 1740702 https://bugzilla.redhat.com/show_bug.cgi?id=1740702 that was closed as Duplicate, but I believe this was a mistake (the other bug 1902173 https://bugzilla.redhat.com/show_bug.cgi?id=1902173 was about not crashing if KRA unregistration failed).
flo
On Thu, Jun 3, 2021 at 12:16 PM Kees Bakker via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
On 01-06-2021 18:01, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote:
On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote: > Hi, > > After installing a new replica and running > > /usr/bin/ipa-healthcheck --source > pki.server.healthcheck.clones.connectivity_and_data > > I'm getting this error > > keyctl_search: Required key not available > Enter password for Internal Key Storage Token: > Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl', > port=443): Max retries exceeded with url: > /ca/rest/certs/search?size=3 (Caused by > NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection > object at 0x7fc473262a90>: Failed to establish a new connection: > [Errno 113] No route to host',)) > [ > { > "source":
"pki.server.healthcheck.clones.connectivity_and_data",
> "check": "ClonesConnectivyAndDataCheck", > "result": "ERROR", > "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", > "when": "20210528150818Z", > "duration": "30.348789", > "kw": { > "status": "ERROR: pki-tomcat : Internal error testing CA > clone. Host: iparep3.ghs.nl Port: 443" > } > } > ] > > First, it is asking for a password, and I have no clue for what.
I've
> tried the admin password and the Directory Manager password. It > makes no difference. > > Second, it tries to connect to a replica that was removed several > months > ago. Both ipa-replica-manage list and ipa-csreplica-manage show the > correct list of masters that we currently have. > > Where does ipa-healthcheck get the information from to query the > removed > replica? > > BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The > first two give > this healthcheck error, the centos7 master does not. That last remark should be: on CentOS 7 there was no such check. So, perhaps the error is there too.
# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data Source 'pki.server.healthcheck.clones.connectivity_and_data' not
found
The problem seems to be that PKI has its own information about masters (and clones). In our PKI configuration there are still two
hosts
that were deleted from FreeIPA a long time ago. So, the ipa-replica-manage del command did not remove them from PKI??
CA replica management is done with 'ipa-csreplica-manage' tool, not 'ipa-replica-manage'.
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to
look at logs) 2) how can I still remove the old hosts?
I'm not sure how to remove hosts from the CA-managed security domain but you can show the hosts it knows about with pki securitydomain-show to confirm that this is where it is finding the old one.
This check is provided by dogtag and executed within ipa-healthcheck. Can you open a ticket on it at https://github.com/dogtagpki/pki/
rob
https://github.com/dogtagpki/pki/issues/3552 _______________________________________________ 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
Florence Renaud wrote:
Hi, I'm not sure the issue is really on PKI side. On ipa server-del call, IPA should also make sure to call something similar to pki securitydomain-host-del to make sure that the host is removed from PKI security domain.
This was tracked in BZ 1740702 https://bugzilla.redhat.com/show_bug.cgi?id=1740702 that was closed as Duplicate, but I believe this was a mistake (the other bug 1902173 https://bugzilla.redhat.com/show_bug.cgi?id=1902173 was about not crashing if KRA unregistration failed).
I agree. I re-opened the BZ.
rob
flo
On Thu, Jun 3, 2021 at 12:16 PM Kees Bakker via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
On 01-06-2021 18:01, Rob Crittenden wrote: > Kees Bakker via FreeIPA-users wrote: >> On 29-05-2021 10:21, Alexander Bokovoy wrote: >>> On pe, 28 touko 2021, Kees Bakker via FreeIPA-users wrote: >>>> On 28-05-2021 19:32, Kees Bakker via FreeIPA-users wrote: >>>>> On 28-05-2021 17:22, Kees Bakker via FreeIPA-users wrote: >>>>>> Hi, >>>>>> >>>>>> After installing a new replica and running >>>>>> >>>>>> /usr/bin/ipa-healthcheck --source >>>>>> pki.server.healthcheck.clones.connectivity_and_data >>>>>> >>>>>> I'm getting this error >>>>>> >>>>>> keyctl_search: Required key not available >>>>>> Enter password for Internal Key Storage Token: >>>>>> Internal server error HTTPSConnectionPool(host='iparep3.ghs.nl <http://iparep3.ghs.nl>', >>>>>> port=443): Max retries exceeded with url: >>>>>> /ca/rest/certs/search?size=3 (Caused by >>>>>> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection >>>>>> object at 0x7fc473262a90>: Failed to establish a new connection: >>>>>> [Errno 113] No route to host',)) >>>>>> [ >>>>>> { >>>>>> "source": "pki.server.healthcheck.clones.connectivity_and_data", >>>>>> "check": "ClonesConnectivyAndDataCheck", >>>>>> "result": "ERROR", >>>>>> "uuid": "c2f3ec1d-494b-4f6a-b6e3-0e38108f2005", >>>>>> "when": "20210528150818Z", >>>>>> "duration": "30.348789", >>>>>> "kw": { >>>>>> "status": "ERROR: pki-tomcat : Internal error testing CA >>>>>> clone. Host: iparep3.ghs.nl <http://iparep3.ghs.nl> Port: 443" >>>>>> } >>>>>> } >>>>>> ] >>>>>> >>>>>> First, it is asking for a password, and I have no clue for what. I've >>>>>> tried the admin password and the Directory Manager password. It >>>>>> makes no difference. >>>>>> >>>>>> Second, it tries to connect to a replica that was removed several >>>>>> months >>>>>> ago. Both ipa-replica-manage list and ipa-csreplica-manage show the >>>>>> correct list of masters that we currently have. >>>>>> >>>>>> Where does ipa-healthcheck get the information from to query the >>>>>> removed >>>>>> replica? >>>>>> >>>>>> BTW. Two replica run CentOS 8 Stream, and one runs CentOS 7. The >>>>>> first two give >>>>>> this healthcheck error, the centos7 master does not. >>>>> That last remark should be: on CentOS 7 there was no such check. So, >>>>> perhaps >>>>> the error is there too. >>>>> >>>>> # /usr/bin/ipa-healthcheck --source >>>>> pki.server.healthcheck.clones.connectivity_and_data >>>>> Source 'pki.server.healthcheck.clones.connectivity_and_data' not found >>>> The problem seems to be that PKI has its own information about >>>> masters (and clones). In our PKI configuration there are still two hosts >>>> that were deleted from FreeIPA a long time ago. So, the >>>> ipa-replica-manage del >>>> command did not remove them from PKI?? >>> CA replica management is done with 'ipa-csreplica-manage' tool, not >>> 'ipa-replica-manage'. >>> >>> >> But I did use "ipa-csreplica-manage del" as well. However, I remember >> that it >> complained it couldn't remove that host. I was assuming it was already >> gone. >> When I list with ipa-csreplica-manage then I don't see the old hosts >> anymore. >> >> So, two things >> 1) "ipa-csreplica-manage del" somehow failed (it's probably too late to >> look at logs) >> 2) how can I still remove the old hosts? > I'm not sure how to remove hosts from the CA-managed security domain but > you can show the hosts it knows about with pki securitydomain-show to > confirm that this is where it is finding the old one. > > This check is provided by dogtag and executed within ipa-healthcheck. > Can you open a ticket on it at https://github.com/dogtagpki/pki/ > > rob > https://github.com/dogtagpki/pki/issues/3552 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto: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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to look
at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12 --pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in.
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert) "
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to look
at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12 --pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup -- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert) "
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late to look
at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12 --pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert) "
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late
to look at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12 --pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
-- Kees
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to
/root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert)
"
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late
to look at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12
--pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
rob
-- Kees
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert) "
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote:
But I did use "ipa-csreplica-manage del" as well. However, I remember that it complained it couldn't remove that host. I was assuming it was already gone. When I list with ipa-csreplica-manage then I don't see the old hosts anymore.
Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
So, two things
- "ipa-csreplica-manage del" somehow failed (it's probably too late
to look at logs) 2) how can I still remove the old hosts?
I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12 --pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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 13-07-2021 17:08, Rob Crittenden wrote:
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
See https://github.com/dogtagpki/pki/issues/3650
rob
-- Kees
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading
nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert)
"
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote:
On 29-05-2021 10:21, Alexander Bokovoy wrote: > But I did use "ipa-csreplica-manage del" as well. However, I > remember that it > complained it couldn't remove that host. I was assuming it was > already gone. > When I list with ipa-csreplica-manage then I don't see the old hosts > anymore. Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage del` just prints a deprecated message and doesn't seem to do anything.
> So, two things > 1) "ipa-csreplica-manage del" somehow failed (it's probably too late > to look > at logs) > 2) how can I still remove the old hosts? I have/had the same problem. I used https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth into the CA to remove the dead host.
pki client-cert-import --pkcs12 /root/ca-agent.p12
--pkcs12-password [redact] pki -n ipa-ca-agent securitydomain-host-find # you need the full Host ID section to remove pki -n ipa-ca-agent securitydomain-host-del "CA freeipa2[redact].net 443"
Keep in mind I'm fairly new to IPA, so maybe you don't want to do this on a production system without someone else more experienced chiming in. But, so far, the health check stopped complaining, replication is fine, and all my users can still log in. _______________________________________________ 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 13-07-2021 17:24, Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 17:08, Rob Crittenden wrote:
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
I wrote some more details in the issue. First part of the problem is that I have this in /etc/pki/pki-tomcat/ca/CS.cfg
ca.subsystem.tokenname=Internal Key Storage Token
The second part of the problem is that this name should be normalized to "internal".
In pki.nssdb there is a normalize function but that is not called in the case. Furthermore, the function is not implemented as I would have done it.
If the above two problems were to be solved then the plugin would get the password from /etc/pki/pki-tomcat/password.conf -- Kees
rob
-- Kees
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote:
It is now time for me to try and follow the suggested pki commands. However, I don't have a /root/ca-agent.p12
There is quite a bit of documentation on the Internet, but it might not all be up-to-date.
Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin Certificate".
"PKI admin certificate is stored in several locations:
/root/ca-agent.p12 with nickname ipa-ca-agent (misleading nickname). /root/.dogtag/pki-tomcat/ca_admin.cert /root/.dogtag/pki-tomcat/ca_admin.cert.der /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to /root/ca-agent.p12) "
I don't have any of them. Then [1] continues with
"PKI Agent Certificate
PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA:
ipaCert (CN=IPA RA)
For IPA Password Vault the certificate is exported and cached into /etc/httpd/alias/kra-agent.pem since python-requests does not support NSS. The cache is invalidated if the KRA authentication fails. IPA Certificates
IPA certificates are stored in /etc/httpd/alias:
<REALM> IPA CA (CN=Certificate Authority) <External CA DN> ipa-ca-agent (CN=ipa-ca-agent) ipaCert (CN=IPA RA) Signing-Cert (CN=Object Signing Cert) "
But all I have in /etc/httpd/alias is a file ipasession.key
I'm confused.
[1] https://www.dogtagpki.org/wiki/IPA_Certificates -- Kees
On 14-06-2021 16:39, github--- via FreeIPA-users wrote: > On 29-05-2021 10:21, Alexander Bokovoy wrote: >> But I did use "ipa-csreplica-manage del" as well. However, I >> remember that it >> complained it couldn't remove that host. I was assuming it was >> already gone. >> When I list with ipa-csreplica-manage then I don't see the old hosts >> anymore. > Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage > del` just prints a deprecated message and doesn't seem to do anything. > >> So, two things >> 1) "ipa-csreplica-manage del" somehow failed (it's probably too late >> to look >> at logs) >> 2) how can I still remove the old hosts? > I have/had the same problem. I used > https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth > into the CA to remove the dead host. > > pki client-cert-import --pkcs12 /root/ca-agent.p12 > --pkcs12-password [redact] > pki -n ipa-ca-agent securitydomain-host-find > # you need the full Host ID section to remove > pki -n ipa-ca-agent securitydomain-host-del "CA > freeipa2[redact].net 443" > > Keep in mind I'm fairly new to IPA, so maybe you don't want to do > this on a production system without someone else more experienced > chiming in. But, so far, the health check stopped complaining, > replication is fine, and all my users can still log in. > _______________________________________________ > 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
On 13-07-2021 19:47, Kees Bakker via FreeIPA-users wrote:
*** EXTERNAL E-MAIL ***
On 13-07-2021 17:24, Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 17:08, Rob Crittenden wrote:
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
Hi Flo,
Do you have a hint how I can get to the point where I can execute the pki securitydomain-host-del command? All examples [2] on the Internet are from the time when there was a /root/ca-agent.p12 and ipaCert. I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} [1].
Maybe you are going to say that I shouldn't need that pki command. But I have two deleted masters in the pki database. Using pki securitydomain-host-del seems the only way to get rid of them. If you have a better suggestion then please let me know.
[1] https://www.freeipa.org/page/Releases/4.8.1 [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup
The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
I wrote some more details in the issue. First part of the problem is that I have this in /etc/pki/pki-tomcat/ca/CS.cfg
ca.subsystem.tokenname=Internal Key Storage Token
The second part of the problem is that this name should be normalized to "internal".
In pki.nssdb there is a normalize function but that is not called in the case. Furthermore, the function is not implemented as I would have done it.
If the above two problems were to be solved then the plugin would get the password from /etc/pki/pki-tomcat/password.conf
I am a bit surprised that nobody has this problem but me. The solution is probably as simple as this:
diff --git a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py index bea2872ea..2472f35b5 100644 --- a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py +++ b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py @@ -168,7 +168,7 @@ class ClonesPlugin(Plugin): # Set some vars we will be using later self.db_dir = self.security_domain.config.get('jss.configDir') self.subsystem_token = self.security_domain.config.get('ca.subsystem.tokenname') - self.passwd = self.instance.get_password(self.subsystem_token) + self.passwd = self.instance.get_token_password(self.subsystem_token)
return sec_domain, sechost, secport
-- Kees
rob
-- Kees
rob
-- Kees
On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote: > It is now time for me to try and follow the suggested pki commands. > However, I don't have a /root/ca-agent.p12 > > There is quite a bit of documentation on the Internet, but it might > not all be > up-to-date. > > Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin > Certificate". > > "PKI admin certificate is stored in several locations: > > /root/ca-agent.p12 with nickname ipa-ca-agent (misleading > nickname). > /root/.dogtag/pki-tomcat/ca_admin.cert > /root/.dogtag/pki-tomcat/ca_admin.cert.der > /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to > /root/ca-agent.p12) > " > > I don't have any of them. Then [1] continues with > > "PKI Agent Certificate > > PKI agent certificate is stored in /etc/httpd/alias and tracked by IPA: > > ipaCert (CN=IPA RA) > > For IPA Password Vault the certificate is exported and cached into > /etc/httpd/alias/kra-agent.pem since python-requests does not support > NSS. The cache is invalidated if the KRA authentication fails. > IPA Certificates > > IPA certificates are stored in /etc/httpd/alias: > > <REALM> IPA CA (CN=Certificate Authority) > <External CA DN> > ipa-ca-agent (CN=ipa-ca-agent) > ipaCert (CN=IPA RA) > Signing-Cert (CN=Object Signing Cert) > " > > But all I have in /etc/httpd/alias is a file ipasession.key > > I'm confused. > > [1] https://www.dogtagpki.org/wiki/IPA_Certificates > -- Kees > > On 14-06-2021 16:39, github--- via FreeIPA-users wrote: >> On 29-05-2021 10:21, Alexander Bokovoy wrote: >>> But I did use "ipa-csreplica-manage del" as well. However, I >>> remember that it >>> complained it couldn't remove that host. I was assuming it was >>> already gone. >>> When I list with ipa-csreplica-manage then I don't see the old hosts >>> anymore. >> Its worth noting my install (4.9.3) on Fedora `ipa-csreplica-manage >> del` just prints a deprecated message and doesn't seem to do anything. >> >>> So, two things >>> 1) "ipa-csreplica-manage del" somehow failed (it's probably too late >>> to look >>> at logs) >>> 2) how can I still remove the old hosts? >> I have/had the same problem. I used >> https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth >> into the CA to remove the dead host. >> >> pki client-cert-import --pkcs12 /root/ca-agent.p12 >> --pkcs12-password [redact] >> pki -n ipa-ca-agent securitydomain-host-find >> # you need the full Host ID section to remove >> pki -n ipa-ca-agent securitydomain-host-del "CA >> freeipa2[redact].net 443" >> >> Keep in mind I'm fairly new to IPA, so maybe you don't want to do >> this on a production system without someone else more experienced >> chiming in. But, so far, the health check stopped complaining, >> replication is fine, and all my users can still log in. >> _______________________________________________ >> 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
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
Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 19:47, Kees Bakker via FreeIPA-users wrote:
*** EXTERNAL E-MAIL ***
On 13-07-2021 17:24, Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 17:08, Rob Crittenden wrote:
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote: > Hi Flo, > > Do you have a hint how I can get to the point where I can execute > the pki securitydomain-host-del command? All examples [2] on the > Internet > are from the time when there was a /root/ca-agent.p12 and ipaCert. > I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} > [1]. > > Maybe you are going to say that I shouldn't need that pki > command. But I > have two deleted masters in the pki database. Using > pki securitydomain-host-del seems the only way to get rid of > them. If > you > have a better suggestion then please let me know. > > [1] https://www.freeipa.org/page/Releases/4.8.1 > [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup The CA agent is something different and not used by IPA at all. If your installation is > 2 years old it is expired anyway.
The dogtag documentation is woefully out-of-date in this regard unfortunately (and yes, I realize I also live in a glass house regarding wikis).
You don't need to import anything, the entries you need are already there. Try:
# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA ipa.example.test 443'
Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
I wrote some more details in the issue. First part of the problem is that I have this in /etc/pki/pki-tomcat/ca/CS.cfg
ca.subsystem.tokenname=Internal Key Storage Token
The second part of the problem is that this name should be normalized to "internal".
In pki.nssdb there is a normalize function but that is not called in the case. Furthermore, the function is not implemented as I would have done it.
If the above two problems were to be solved then the plugin would get the password from /etc/pki/pki-tomcat/password.conf
I am a bit surprised that nobody has this problem but me. The solution is probably as simple as this:
diff --git a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py index bea2872ea..2472f35b5 100644 --- a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py +++ b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py @@ -168,7 +168,7 @@ class ClonesPlugin(Plugin): # Set some vars we will be using later self.db_dir = self.security_domain.config.get('jss.configDir') self.subsystem_token = self.security_domain.config.get('ca.subsystem.tokenname') - self.passwd = self.instance.get_password(self.subsystem_token) + self.passwd = self.instance.get_token_password(self.subsystem_token)
return sec_domain, sechost, secport
You're not the only one who has reported this, just the first to have reported it upstream AFAIK.
Nice work on the patch.
rob
-- Kees
rob
-- Kees
rob
> -- Kees > > On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote: >> It is now time for me to try and follow the suggested pki commands. >> However, I don't have a /root/ca-agent.p12 >> >> There is quite a bit of documentation on the Internet, but it might >> not all be >> up-to-date. >> >> Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin >> Certificate". >> >> "PKI admin certificate is stored in several locations: >> >> /root/ca-agent.p12 with nickname ipa-ca-agent (misleading >> nickname). >> /root/.dogtag/pki-tomcat/ca_admin.cert >> /root/.dogtag/pki-tomcat/ca_admin.cert.der >> /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to >> /root/ca-agent.p12) >> " >> >> I don't have any of them. Then [1] continues with >> >> "PKI Agent Certificate >> >> PKI agent certificate is stored in /etc/httpd/alias and tracked >> by IPA: >> >> ipaCert (CN=IPA RA) >> >> For IPA Password Vault the certificate is exported and cached into >> /etc/httpd/alias/kra-agent.pem since python-requests does not >> support >> NSS. The cache is invalidated if the KRA authentication fails. >> IPA Certificates >> >> IPA certificates are stored in /etc/httpd/alias: >> >> <REALM> IPA CA (CN=Certificate Authority) >> <External CA DN> >> ipa-ca-agent (CN=ipa-ca-agent) >> ipaCert (CN=IPA RA) >> Signing-Cert (CN=Object Signing Cert) >> " >> >> But all I have in /etc/httpd/alias is a file ipasession.key >> >> I'm confused. >> >> [1] https://www.dogtagpki.org/wiki/IPA_Certificates >> -- Kees >> >> On 14-06-2021 16:39, github--- via FreeIPA-users wrote: >>> On 29-05-2021 10:21, Alexander Bokovoy wrote: >>>> But I did use "ipa-csreplica-manage del" as well. However, I >>>> remember that it >>>> complained it couldn't remove that host. I was assuming it was >>>> already gone. >>>> When I list with ipa-csreplica-manage then I don't see the old >>>> hosts >>>> anymore. >>> Its worth noting my install (4.9.3) on Fedora >>> `ipa-csreplica-manage >>> del` just prints a deprecated message and doesn't seem to do >>> anything. >>> >>>> So, two things >>>> 1) "ipa-csreplica-manage del" somehow failed (it's probably >>>> too late >>>> to look >>>> at logs) >>>> 2) how can I still remove the old hosts? >>> I have/had the same problem. I used >>> https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth >>> into the CA to remove the dead host. >>> >>> pki client-cert-import --pkcs12 /root/ca-agent.p12 >>> --pkcs12-password [redact] >>> pki -n ipa-ca-agent securitydomain-host-find >>> # you need the full Host ID section to remove >>> pki -n ipa-ca-agent securitydomain-host-del "CA >>> freeipa2[redact].net 443" >>> >>> Keep in mind I'm fairly new to IPA, so maybe you don't want to do >>> this on a production system without someone else more experienced >>> chiming in. But, so far, the health check stopped complaining, >>> replication is fine, and all my users can still log in. >>> _______________________________________________ >>> 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
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
Rob Crittenden via FreeIPA-users wrote:
Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 19:47, Kees Bakker via FreeIPA-users wrote:
*** EXTERNAL E-MAIL ***
On 13-07-2021 17:24, Kees Bakker via FreeIPA-users wrote:
On 13-07-2021 17:08, Rob Crittenden wrote:
Kees Bakker wrote:
On 12-07-2021 21:51, Rob Crittenden wrote: > Kees Bakker via FreeIPA-users wrote: >> Hi Flo, >> >> Do you have a hint how I can get to the point where I can execute >> the pki securitydomain-host-del command? All examples [2] on the >> Internet >> are from the time when there was a /root/ca-agent.p12 and ipaCert. >> I think that has been migrated to /var/lib/ipa/ra-agent.{key,pem} >> [1]. >> >> Maybe you are going to say that I shouldn't need that pki >> command. But I >> have two deleted masters in the pki database. Using >> pki securitydomain-host-del seems the only way to get rid of >> them. If >> you >> have a better suggestion then please let me know. >> >> [1] https://www.freeipa.org/page/Releases/4.8.1 >> [2] https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup > The CA agent is something different and not used by IPA at all. If > your > installation is > 2 years old it is expired anyway. > > The dogtag documentation is woefully out-of-date in this regard > unfortunately (and yes, I realize I also live in a glass house > regarding > wikis). > > You don't need to import anything, the entries you need are already > there. Try: > > # pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C > /etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA > ipa.example.test 443' Thanks Rob,
That did it.
I'm now almost there to get a clean outcome of ipa-healthcheck. It reports no errors anymore, but ... there is one healthcheck that wants a password. I have no idea what or why.
[root@linge ~]# /usr/bin/ipa-healthcheck --source pki.server.healthcheck.clones.connectivity_and_data keyctl_search: Required key not available Enter password for Internal Key Storage Token: []
This comes out of the pki healthcheck plugins.
The check does some client cert connections, so I assume it needs the NSS database password. I'm guessing it looks in the kernel keyring (keyctl_search) and then prompts the user.
You can open an issue against them at https://github.com/dogtagpki/pki/issues
I wrote some more details in the issue. First part of the problem is that I have this in /etc/pki/pki-tomcat/ca/CS.cfg
ca.subsystem.tokenname=Internal Key Storage Token
The second part of the problem is that this name should be normalized to "internal".
In pki.nssdb there is a normalize function but that is not called in the case. Furthermore, the function is not implemented as I would have done it.
If the above two problems were to be solved then the plugin would get the password from /etc/pki/pki-tomcat/password.conf
I am a bit surprised that nobody has this problem but me. The solution is probably as simple as this:
diff --git a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py index bea2872ea..2472f35b5 100644 --- a/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py +++ b/base/server/healthcheck/pki/server/healthcheck/clones/plugin.py @@ -168,7 +168,7 @@ class ClonesPlugin(Plugin): # Set some vars we will be using later self.db_dir = self.security_domain.config.get('jss.configDir') self.subsystem_token = self.security_domain.config.get('ca.subsystem.tokenname') - self.passwd = self.instance.get_password(self.subsystem_token) + self.passwd = self.instance.get_token_password(self.subsystem_token)
return sec_domain, sechost, secport
You're not the only one who has reported this, just the first to have reported it upstream AFAIK.
Nice work on the patch.
BTW there is also a BZ for this, https://bugzilla.redhat.com/show_bug.cgi?id=1980378
rob
-- Kees
rob
-- Kees > rob > >> -- Kees >> >> On 12-07-2021 15:01, Kees Bakker via FreeIPA-users wrote: >>> It is now time for me to try and follow the suggested pki commands. >>> However, I don't have a /root/ca-agent.p12 >>> >>> There is quite a bit of documentation on the Internet, but it might >>> not all be >>> up-to-date. >>> >>> Here [1] the file /root/ca-agent.p12 is mentioned under "PKI Admin >>> Certificate". >>> >>> "PKI admin certificate is stored in several locations: >>> >>> /root/ca-agent.p12 with nickname ipa-ca-agent (misleading >>> nickname). >>> /root/.dogtag/pki-tomcat/ca_admin.cert >>> /root/.dogtag/pki-tomcat/ca_admin.cert.der >>> /root/.dogtag/pki-tomcat/ca_admin_cert.p12 (moved to >>> /root/ca-agent.p12) >>> " >>> >>> I don't have any of them. Then [1] continues with >>> >>> "PKI Agent Certificate >>> >>> PKI agent certificate is stored in /etc/httpd/alias and tracked >>> by IPA: >>> >>> ipaCert (CN=IPA RA) >>> >>> For IPA Password Vault the certificate is exported and cached into >>> /etc/httpd/alias/kra-agent.pem since python-requests does not >>> support >>> NSS. The cache is invalidated if the KRA authentication fails. >>> IPA Certificates >>> >>> IPA certificates are stored in /etc/httpd/alias: >>> >>> <REALM> IPA CA (CN=Certificate Authority) >>> <External CA DN> >>> ipa-ca-agent (CN=ipa-ca-agent) >>> ipaCert (CN=IPA RA) >>> Signing-Cert (CN=Object Signing Cert) >>> " >>> >>> But all I have in /etc/httpd/alias is a file ipasession.key >>> >>> I'm confused. >>> >>> [1] https://www.dogtagpki.org/wiki/IPA_Certificates >>> -- Kees >>> >>> On 14-06-2021 16:39, github--- via FreeIPA-users wrote: >>>> On 29-05-2021 10:21, Alexander Bokovoy wrote: >>>>> But I did use "ipa-csreplica-manage del" as well. However, I >>>>> remember that it >>>>> complained it couldn't remove that host. I was assuming it was >>>>> already gone. >>>>> When I list with ipa-csreplica-manage then I don't see the old >>>>> hosts >>>>> anymore. >>>> Its worth noting my install (4.9.3) on Fedora >>>> `ipa-csreplica-manage >>>> del` just prints a deprecated message and doesn't seem to do >>>> anything. >>>> >>>>> So, two things >>>>> 1) "ipa-csreplica-manage del" somehow failed (it's probably >>>>> too late >>>>> to look >>>>> at logs) >>>>> 2) how can I still remove the old hosts? >>>> I have/had the same problem. I used >>>> https://www.dogtagpki.org/wiki/IPA_PKI_Admin_Setup to help me auth >>>> into the CA to remove the dead host. >>>> >>>> pki client-cert-import --pkcs12 /root/ca-agent.p12 >>>> --pkcs12-password [redact] >>>> pki -n ipa-ca-agent securitydomain-host-find >>>> # you need the full Host ID section to remove >>>> pki -n ipa-ca-agent securitydomain-host-del "CA >>>> freeipa2[redact].net 443" >>>> >>>> Keep in mind I'm fairly new to IPA, so maybe you don't want to do >>>> this on a production system without someone else more experienced >>>> chiming in. But, so far, the health check stopped complaining, >>>> replication is fine, and all my users can still log in.
freeipa-users@lists.fedorahosted.org