Giulio Casella via FreeIPA-users wrote:
> Hi Striker,
>
> On 5/14/2026 12:11 PM, Striker Leggette via FreeIPA-users wrote:
>> On 5/14/26 4:40 AM, Giulio Casella via FreeIPA-users wrote:
>>> Hello everyone,
>>> on two out of three ipa server of my setup pki-tomcatd refuse to
>>> start, giving:
>>>
>>> SEVERE: LdapBoundConnFactory: Unable to connect to LDAP server:
>>> Authentication failed
>>>
>>> After some quick research I tried to verify tomcat internal password:
>>>
>>> grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d=
>>> -f2 > /tmp/pwdfile.txt
>>
>> This might not be clean enough. Try this instead:
>>
>> # awk -F= '$1=="internal"{print $2}' /var/lib/pki/pki-tomcat/conf/
>> password.conf > /tmp/pwdfile.txt
>>
>> And then:
>>
>> # certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt
>>
>
> Ok, if I issue "certutil -K -d /etc/pki/pki-tomcat/alias -f
> /tmp/pwdfile.txt" I get:
>
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> < 0> rsa acb51ead6f615210f38d09c203dca7fa5b19bfe6 NSS Certificate
> DB:caSigningCert cert-pki-ca
> < 1> rsa 303aa4083ca5bd39b87e9665240fdba8c63d7388 NSS Certificate
> DB:ocspSigningCert cert-pki-ca
> < 2> rsa c85a20be2c6c0c64f63cdeab7306cd048049374c NSS Certificate
> DB:auditSigningCert cert-pki-ca
> < 3> rsa c2b7f46ab50e418dc541b4505b607aaf34146786 NSS Certificate
> DB:subsystemCert cert-pki-ca
> < 4> rsa c3481569e05a90be023deccd18b6a590f87b8b05 NSS Certificate
> DB:Server-Cert cert-pki-ca
>
> But if I try to get one specific key name ("certutil -K -d
> /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'NSS Certificate
> DB:subsystemCert cert-pki-ca') I get the invalid algoithm error:
>
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> certutil: problem listing keys: SEC_ERROR_INVALID_ALGORITHM: security
> library: invalid algorithm.
I wouldn't focus on this at all. Listing individual keys doesn't really
tell us anything useful. That the keys are present is what is important.
You can compare the ids between systems as well to ensure they are the
same private keys.
>> Also, can you give:
>>
>> # grep-nE'internaldb\.ldapauth\.(authtype|bindDN|bindPWPrompt|
>> clientCertNickname)|internaldb\.ldapconn\.(host|port|secureConn)'
>> /var/ lib/pki/pki-tomcat/ca/conf/CS.cfg
>>
>
> I get:
>
> 795:internaldb.ldapauth.authtype=SslClientAuth
> 796:internaldb.ldapauth.bindDN=cn=Directory Manager
> 797:internaldb.ldapauth.bindPWPrompt=internaldb
> 798:internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
> 799:internaldb.ldapconn.host=dc1.my.dom.ain
> 800:internaldb.ldapconn.port=636
> 801:internaldb.ldapconn.secureConn=true
>
>
>>> The password seems to be ok, but when I try to list keys I get:
>>>
>>> certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n
>>> 'subsystemCert cert-pki-ca'
>>>
>>> certutil: Checking token "NSS Certificate DB" in slot "NSS User
>>> Private Key and Certificate Services"
>>> certutil: problem listing keys: SEC_ERROR_INVALID_ALGORITHM: security
>>> library: invalid algorithm.
>>>
>>> (no SEC_ERROR_BAD_PASSWORD message, but SEC_ERROR_INVALID_ALGORITHM)
>>>
>>> Any ideas?
>>
>> Flo wrote a good blog to help debug this:
>>
>> https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-
>> tomcatd-fails-to-start/
>
> I did read Flo's blog, but I'm a little confused... Serial number I get
> from "certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> cert-pki-ca'" is different in one (out of 3) ipa server (BTW: serial is
> expressed in hex format, so I have to convert to decimal in ldif).
> When I change the ldap accordingly, the serial number propagate
> (replica), and pki-tomcatd is not starting anymore.
You've hit on what is likely the root of the problem.
You'll want to look at the certificates issuance dates. I'm guessing
that one is newer than the other two. It was likely renewed recently?
The way that IPA CA certificate renewals works is that one server, the
so-called renewal master, handles the renewals. It uploads the updated
certificate into LDAP and the other CAs should update their local copy
from that.
These are all clones of the same original CA so should literally have
all the same certificates and keys.
> Maybe the problem is in /etc/pki/pki-tomcat/alias folder...
The problem isn't within the NSS database, but it is likely that some or
all of the subsystem certificates are different. They need to be the
same on all servers.
This is all tracked with certmonger. You can see what it thinks about
the certificates with:
getcert list -d /etc/pki/pki-tomcat/alias
rob
>
>
>>
>> Can you provide the generated logs in /var/log/pki/pki-tomcat/ca/debug
>> when PKI fails to start?
>>
>
> Sure, find attached
>
>
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
