Ian Harding wrote:
On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:
> On 08/01/2017 03:11 PM, Ian Harding wrote:
>> On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
>>> On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:
>>>>
>>>>
>>>> On 07/31/2017 11:34 AM, Rob Crittenden wrote:
>>>>> Ian Harding via FreeIPA-users wrote:
>>>>>> I had an unexpected restart of an IPA server that had apparently
had
>>>>>> updates run but had not been restarted. ipactl says pki-tomcatd
>>>>>> would
>>>>>> not start.
>>>>>>
>>>>>> Strangely, the actual service appears to be running:
>>>>>>
>>>>>
>>>>> dogtag is an application within tomcat so tomcat can run without
>>>>> dogtag
>>>>> running.
>>>>>
>>>>> We need to see more of the dogtag debug log to see what is going on.
>>>>>
>>>>
>>>> It looks like an authentication problem...
>>>>
>>>> [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened
>>>> Could not connect to LDAP server host seattlenfs.bpt.rocks port 636
>>>> Error netscape.ldap.LDAPException: Authentication failed (49)
>>>>
>>>
>>> Hi,
>>>
>>> dogtag stores its internal data in the LDAP server and needs to
>>> establish a secure LDAP connection. You can check how this
>>> connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for
>>> the lines:
>>>
>>> internaldb.ldapauth.authtype=SslClientAuth
>>> internaldb.ldapauth.bindDN=cn=Directory Manager
>>> internaldb.ldapauth.bindPWPrompt=internaldb
>>> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
>>> internaldb.ldapconn.host=vm-...
>>> internaldb.ldapconn.port=636
>>> internaldb.ldapconn.secureConn
>>>
>>> authtype can be SslClientAuth (authentication with a ssl
>>> certificate) or BasicAuth (authentication with a bind DN and
>>> password stored in /var/lib/pki/pki-tomcat/conf/password.conf).
>>>
>>> You can use this information to manually check the credentials. For
>>> instance with sslclientauth:
>>>
>>> export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
>>> export LDAPTLS_CERT='subsystemCert cert-pki-ca'
>>>
>>> ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
>>> (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt)
>>>
>>
>> I found this:
>>
>> internaldb.ldapauth.authtype=SslClientAuth
>> internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
>> internaldb.ldapauth.bindPWPrompt=internaldb
>> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
>> internaldb.ldapconn.cloneReplicationPort=389
>> ...
>>
>> and when I try the ldapsearch I am presented with a prompt to provide
>> a pin/password
>>
>> Please enter pin, password, or pass phrase for security token 'ldap(0)':
>>
>> but there is no password file...
>>
> Hi,
>
> you are right, in 4.4. there is no pwdfile.txt and the password can be
> found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag
> internal=...)
>
> Can you check if the password with the tag internal=... allows to read
> the keys from the NSS db?
> certutil -K -d /etc/pki/pki-tomcat/alias
> (provide password)
That works...
# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan)
< 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a NSS Certificate
DB:auditSigningCert cert-pki-ca
< 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert
cert-pki-ca
< 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403 NSS Certificate
DB:ocspSigningCert cert-pki-ca
< 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert
cert-pki-ca
< 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856 NSS Certificate
DB:subsystemCert cert-pki-ca
But this doesn't (with the same password from password.conf)
# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
Please enter pin, password, or pass phrase for security token 'ldap(0)':
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
That password is getting me somewhere though, since if I put in a
nonsense or incorrect password it just prompts over and over.
Let's step back a second. You upgraded from what to what?
Are you running in SELinux enforcing mode?
If so can you run:
# ausearch -m AVC
I suspect that the subsystem cert was renewed and everything wasn't
updated properly. If I'm right this is unrelated to the upgrade it just
shone a spotlight on it.
Can you run these commands:
$ ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description
and
# certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' | grep Serial
# certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
The description attribute in the ldapsearch output is of the form 2;#;DN;DN
The # should match the serial number in the first certutil output
The ASCII blob (minus the BEGIN/END headers) should match one of the
userCertificate attributes.
rob