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
>>> See
https://github.com/dogtagpki/pki/issues/3650
>>
>> 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.