In the final step of upgrading my freeIPA servers to fedora26/freeIPA 4.4.4, I removed the current demoted the current renewal master, and promoted a CA (sif) as new renewal master, following instructions from < https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Reco... >.
Since then, pki-tomcatd will not start, here's an excerpt of /var/log/pki/pki-tomcat/ca/debug : ``` [17/Jul/2018:15:34:57][localhost-startStop-1]: CMSEngine: ready to init id=dbs [17/Jul/2018:15:34:57][localhost-startStop-1]: DBSubsystem: init() mEnableSerialMgmt=true [17/Jul/2018:15:34:57][localhost-startStop-1]: Creating LdapBoundConnFactor(DBSubsystem) [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapBoundConnFactory: init [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapBoundConnFactory:doCloning true [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init() [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init begins [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapAuthInfo: init ends [17/Jul/2018:15:34:57][localhost-startStop-1]: init: before makeConnection errorIfDown is true [17/Jul/2018:15:34:57][localhost-startStop-1]: makeConnection: errorIfDown true [17/Jul/2018:15:34:57][localhost-startStop-1]: TCP Keep-Alive: true [17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificateSelectionCB: Setting desired cert nickname to: subsystemCert cert-pki-ca [17/Jul/2018:15:34:57][localhost-startStop-1]: LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca [17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificatSelectionCB: Entering! [17/Jul/2018:15:34:57][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: null [17/Jul/2018:15:34:57][localhost-startStop-1]: SSL handshake happened Could not connect to LDAP server host sif.quartzbio.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48) ``` I found this very useful blog: < https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcat... > and checked all the steps. From what I checked: - my certificates are valid - there was two userCertificate for pkidbuser, one expired. I removed it using Apache Directory Studio - the pkidbuser certificate match the one from /etc/pki/pki-tomcat/alias
One possibly relevant info: the previous renewal master/CA was the main DNS, it is no longer running since I was about to recreate it when I discovered that the pki-tomcatd was not running when I tried to execute ipa-prepare-replicate.
I would be grateful if you could help me or guide me debugging this. Thanks, Karl.
Additional info: ipa config-show ----------------------- Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: example.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=QUARTZBIO.COM Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: nfs:NONE, MS-PAC IPA masters: amora.example.com, sif.example.com IPA CA servers: amora.example.com, sif.example.com IPA NTP servers: amora.example.com, sif.example.com IPA CA renewal master: sif.example.com
grep internaldb.ldap /etc/pki/pki-tomcat/ca/CS.cfg ------------------------------ internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.cloneReplicationPort=389 internaldb.ldapconn.host=sif.example.com internaldb.ldapconn.masterReplicationPort=389 internaldb.ldapconn.port=636 internaldb.ldapconn.replicationSecurity=TLS internaldb.ldapconn.secureConn=true
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' ------------------------------------ Data: Version: 3 (0x2) Serial Number: 86 (0x56) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=QUARTZBIO.COM" Validity: Not Before: Wed May 31 15:49:31 2017 Not After : Tue May 21 15:49:31 2019 Subject: "CN=CA Subsystem,O=QUARTZBIO.COM" ...
sudo grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt sudo 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" < 0> rsa 4c9dcd686df2a289ef1bcd21d2dfb195a0d7bc9c subsystemCert cert-pki-ca
sudo cat /etc/dirsrv/slapd-IPADOMAIN-COM/certmap.conf ---------------------- default:DNComps default:FilterComps uid certmap ipaca CN=Certificate Authority,O=QUARTZBIO.COM ipaca:CmapLdapAttr seeAlso ipaca:verifycert on
ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca description ----------------------------- dn: uid=pkidbuser,ou=people,o=ipaca description: 2;86;CN=Certificate Authority,O=QUARTZBIO.COM;CN=CA Subsystem,O=Q UARTZBIO.COM
sudo certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial ------------------------ Serial Number: 86 (0x56)
getcert list | grep "expires|status|subject" | perl -pe 's/quartzbio/example/ig' status: MONITORING subject: CN=sif.example.com,O=example.COM expires: 2020-07-13 13:44:48 CEST status: MONITORING subject: CN=CA Audit,O=example.COM expires: 2019-05-21 17:50:42 CEST status: MONITORING subject: CN=OCSP Subsystem,O=example.COM expires: 2019-05-21 17:50:01 CEST status: MONITORING subject: CN=CA Subsystem,O=example.COM expires: 2019-05-21 17:49:31 CEST status: MONITORING subject: CN=Certificate Authority,O=example.COM expires: 2035-07-09 11:41:54 CEST status: MONITORING subject: CN=sif.example.com,O=example.COM expires: 2020-07-02 16:57:18 CEST status: MONITORING subject: CN=sif.example.com,O=example.COM expires: 2020-07-13 13:44:52 CEST status: MONITORING subject: CN=IPA RA,O=example.COM expires: 2019-05-21 17:50:10 CEST
Your CS.cfg file looks odd to me, but it could be the lower version you're running or some manual changes made at sometime.
--->8--- grep internaldb.ldap /etc/pki/pki-tomcat/ca/CS.cfg ------------------------------ internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager #AFAIK this should be pkidbuser's DN internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca --->8---
FreeIPA uses ldap as the backend for pki-tomcat, it it uses the ldapauth cert you have listed to look for a UID that has a matching userCert value (more to it, but this sums it up)
I believe you might want to try and use the pkidbuser DN instead of the Directory Manager DN as that would produce the proper match for you.
I would also verify that the CA that signed your subsystemCert exists in your dirserv ldap nssdb in /etc/dirsrv/slapd-DOMAIN.NAME. If it doesn't exist install it using pk12util and set trust on it with certutil.
Hopefully this helps.
c0ff33d c0ff33d via FreeIPA-users wrote:
Your CS.cfg file looks odd to me, but it could be the lower version you're running or some manual changes made at sometime.
--->8--- grep internaldb.ldap /etc/pki/pki-tomcat/ca/CS.cfg
internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager #AFAIK this should be pkidbuser's DN internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca --->8---
cn=Directory Manager is correct. dogtag uses client auth so bind DN is sent in the typical case either way.
FreeIPA uses ldap as the backend for pki-tomcat, it it uses the ldapauth cert you have listed to look for a UID that has a matching userCert value (more to it, but this sums it up)
I believe you might want to try and use the pkidbuser DN instead of the Directory Manager DN as that would produce the proper match for you.
I would also verify that the CA that signed your subsystemCert exists in your dirserv ldap nssdb in /etc/dirsrv/slapd-DOMAIN.NAME. If it doesn't exist install it using pk12util and set trust on it with certutil.
The cert is not needed in the 389-ds cert database. It uses certmap.conf to map the cert that dogtag provides to an LDAP entry.
rob
cn=Directory Manager is correct. dogtag uses client auth so bind DN is sent in the typical case either way.
"Can also be correct" would be more accurate wouldn't it? Default value for CentOS is the pkidbuser DN. I'd be surprised if the Fedora packages were that different here.
The cert is not needed in the 389-ds cert database. It uses certmap.conf to map the cert that dogtag provides to an LDAP entry.
With 'verifycert on' in certmap.conf by default the cert is certainly needed in LDAP isn't it?
c0ff33d c0ff33d via FreeIPA-users wrote:
cn=Directory Manager is correct. dogtag uses client auth so bind DN is sent in the typical case either way.
"Can also be correct" would be more accurate wouldn't it? Default value for CentOS is the pkidbuser DN. I'd be surprised if the Fedora packages were that different here.
The cert is not needed in the 389-ds cert database. It uses certmap.conf to map the cert that dogtag provides to an LDAP entry.
With 'verifycert on' in certmap.conf by default the cert is certainly needed in LDAP isn't it?
Correct, but not in the NSS database.
rob
freeipa-users@lists.fedorahosted.org