#6521 [tracker] pki-tomcat will not start after certificate renewal
Closed: insufficientinfo 5 years ago by rcritten. Opened 7 years ago by jose256.

pki-tomcat fails with the following error when it starts. I believe this is due to the certificate being renewed, since this issue started around that time.

[20/Nov/2016:22:07:04][localhost-startStop-1]: init: before makeConnection errorIfDown is true
[20/Nov/2016:22:07:04][localhost-startStop-1]: makeConnection: errorIfDown true
[20/Nov/2016:22:07:04][localhost-startStop-1]: LdapJssSSLSocket set client auth cert nicknamesubsystemCert cert-pki-ca
Could not connect to LDAP server host ipa.example.com port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:204)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
        at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:651)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013)
        at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:510)
        at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
        at com.netscape.certsrv.apps.CMS.start(CMS.java:1601)
        at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
        at javax.servlet.GenericServlet.init(GenericServlet.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
        at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
        at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
        at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
        at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

This is the same error as https://access.redhat.com/solutions/2022123 but trust args are set correctly.
I have verified the certs, they are signed by my CA and are valid. I have also checked the related LDAP attributes under o=ipaca and dc=example,dc=com. The certificates in /etc/pki/pki-tomcat/ca/CS.cfg are the new ones.


Hello, what version of FreeIPA do you use, what OS. After what renewal of what certificate it happened?

Could you paste output of ipactl start, and directory server error log? Is directory server listening on port 636?

directory server error log from same time period as ipactl
error_report.log.xz

ipa version 4.2.0 release 15.0.1.el7.centos.19 on CentOS 7.2 The certificates related to tomcat that renenewd around the same time are subsystemCert, auditSigningCert, and ocspSigningCert.

I have included ipactl start and ipactl start --ignore-service-failures, since this is a production system and it needed to be running even with tomcat broken. I have attached a copy of the dirsrv error log from since I ran ipactl start. It is listening to port 636, I can connect to it with openssl and the certificate is ok.

[root@ipa tmp]# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Aborting ipactl
[root@ipa tmp]# ipactl --ignore-service-failures start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Forced start, ignoring pki-tomcatd Service, continuing normal operation
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

if not done already, it might be better to reach on freeipa-users mailing list. More people will see the issue and will be able to help.

DS error log seems to list issue with replication but that should not be related to local CS.

More info will be in pki ca debug log.

Also check if getcert list shows status: MONITORING in all certs on IPA server.

Looking at the replication error, it is looking that the replica received a replicated update (583d061d000000080000) and failed to apply it. master keeps trying sending this update but as it was failing on the replica side it is sending it again and again (for at least 30 min).

Do you have the access logs available (master/consumer).

I fixed the replications issues by reninilizing a couple hosts and also cleaning up some old ruvs. I also updated FreeIPA when Cantos 7.3 came out. There is nothing in the ldap debug log associated with the issue. However the tomcat ca debug log now looks like the following.

[20/Dec/2016:10:12:32][localhost-startStop-1]: ============================================
[20/Dec/2016:10:12:32][localhost-startStop-1]: =====  DEBUG SUBSYSTEM INITIALIZED   =======
[20/Dec/2016:10:12:32][localhost-startStop-1]: ============================================
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: done init id=debug
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initialized debug
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initSubsystem id=log
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: ready to init id=log
[20/Dec/2016:10:12:32][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[20/Dec/2016:10:12:32][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[20/Dec/2016:10:12:32][localhost-startStop-1]: Creating RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: done init id=log
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initialized log
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: ready to init id=jss
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: restart at autoShutdown? false
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: autoShutdown crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: about to look for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: found cert:auditSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: done init id=jss
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initialized jss
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
[20/Dec/2016:10:12:32][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[20/Dec/2016:10:12:32][localhost-startStop-1]: DBSubsystem: init()  mEnableSerialMgmt=true
[20/Dec/2016:10:12:32][localhost-startStop-1]: Creating LdapBoundConnFactor(DBSubsystem)
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapBoundConnFactory: init
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapBoundConnFactory:doCloning true
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapAuthInfo: init()
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapAuthInfo: init begins
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapAuthInfo: init ends
[20/Dec/2016:10:12:32][localhost-startStop-1]: init: before makeConnection errorIfDown is true
[20/Dec/2016:10:12:32][localhost-startStop-1]: makeConnection: errorIfDown true
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSLClientCertificateSelectionCB: Setting desired cert nickname to: subsystemCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSLClientCertificatSelectionCB: Entering!
[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: caSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: Server-Cert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: null
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host ipa.example.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
        at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
        at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
        at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571)
        at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
        at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
        at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
        at javax.servlet.GenericServlet.init(GenericServlet.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
        at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
        at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
        at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:124)
        at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1270)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1195)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1085)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
        at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
        at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
        at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

We also have an interesting error that may be effecting it from a long time ago when a coworker of mine migrated us from centos6 to centos7. There are two certificates under cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA certificates and when I run openssl verify with ether of them as the CA and the new subsystem certificate I get an OK message.

getcert list shows MONITORING for all certs on the IPA server where tomcat is not starting.

On working system I have:

[15/Dec/2016:13:37:48][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[15/Dec/2016:13:37:48][localhost-startStop-1]: DBSubsystem: init()  mEnableSerialMgmt=false
[15/Dec/2016:13:37:48][localhost-startStop-1]: Creating LdapBoundConnFactor(DBSubsystem)
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapBoundConnFactory: init 
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapBoundConnFactory:doCloning true
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapAuthInfo: init()
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapAuthInfo: init begins
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapAuthInfo: init ends
[15/Dec/2016:13:37:48][localhost-startStop-1]: init: before makeConnection errorIfDown is true
[15/Dec/2016:13:37:48][localhost-startStop-1]: makeConnection: errorIfDown true
[15/Dec/2016:13:37:48][localhost-startStop-1]: SSLClientCertificateSelectionCB: Setting desired cert nickname to: subsystemCert cert-pki-ca
[15/Dec/2016:13:37:48][localhost-startStop-1]: LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca
[15/Dec/2016:13:37:48][localhost-startStop-1]: SSLClientCertificatSelectionCB: Entering!
[15/Dec/2016:13:37:48][localhost-startStop-1]: Candidate cert: storageCert cert-pki-kra
[15/Dec/2016:13:37:48][localhost-startStop-1]: Candidate cert: subsystemCert cert-pki-ca
[15/Dec/2016:13:37:48][localhost-startStop-1]: SSLClientCertificateSelectionCB: desired cert found in list: subsystemCert cert-pki-ca
[15/Dec/2016:13:37:48][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: subsystemCert cert-pki-ca
[15/Dec/2016:13:37:48][localhost-startStop-1]: SSL handshake happened
[15/Dec/2016:13:37:48][localhost-startStop-1]: Established LDAP connection with SSL client auth to ipa.example.com:636

Yours has

[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: caSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: Server-Cert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: null
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host ipa.example.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48)

In the logs we can see that both systems tries to look for "subsystemCert cert-pki-ca" certificate but yours doesn't have it listed as "Candidate cert", it doesn't find it and then the hanshake fails.

Even though the getcert list shows monitoring for all certs, I would focus on the "subsystemCert cert-pki-ca". Could you paste what is its state, e.g.:

# getcert list | grep "subsystemCert cert-pki-ca" -B 4 -A 3
    auto-renew: yes
Request ID '20160825124526':
    status: MONITORING
    stuck: no
    key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set
    certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
    CA: dogtag-ipa-ca-renew-agent
    issuer: CN=Certificate Authority,O=TEST.EXAMPLE.COM
    subject: CN=CA Subsystem,O=TEST.EXAMPLE.COM
    expires: 2018-07-01 14:24:59 UTC
    key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
    eku: id-kp-serverAuth,id-kp-clientAuth
    pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
    post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
    track: yes
    auto-renew: yes
Request ID '20160825124527':

You might also try to run ipa-certupdate on the system. The command adds missing (if any) CA certs to all(httpd, pki, ds) IPA NSS databases. Usually this should be run on all IPA enabled system after changes in CA certs.

[root@ipa tmp]# getcert list | grep "subsystemCert cert-pki-ca" -B 4 -A 3
        auto-renew: yes
Request ID '20160220071850':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set
        certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
        CA: dogtag-ipa-ca-renew-agent
        issuer: CN=Certificate Authority,O=EXAMPLE.COM
        subject: CN=CA Subsystem,O=EXAMPLE.COM
        expires: 2018-10-11 01:44:12 UTC
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
        post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
        track: yes
        auto-renew: yes
Request ID '20160220071851':

That looks OK.

Endi, how does dogtag pick the certs to use for the socket?

Seems to me that it cannot pick the right one:

[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: caSigningCert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: Candidate cert: Server-Cert cert-pki-ca
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: null
[20/Dec/2016:10:12:32][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host ipa.example.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48)

Is there a mapping in LDAP or does looks purely in NSS database or something like that?

I decided to try and run ipa-certupdate I got the error {{{failed to update EXAMPLE.COM IPA CA in /etc/dirsrv/slapd-EXAMPLE-COM: Command '/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM IPA CA -t CT,C,C' returned non-zero exit status 255}}}. At first I thought maybe this was happening since there was already an EXAMPLE.COM IPA CA in the nss database. So I deleted the entry from each and ran the script again. So based off of the below output I think it's trying to load the first CA cert and then failing to add the second CA cert. Could this be the problem?

ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM IPA CA -t CT,C,C
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM IPA CA -t CT,C,C
ipa: DEBUG: Process finished, return code=255
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: could not add certificate to token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to database.

ipa.ipaclient.ipa_certupdate.CertUpdate: ERROR: failed to update EXAMPLE.COM IPA CA in /etc/dirsrv/slapd-EXAMPLE-COM: Command '/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM 
IPA CA -t CT,C,C' returned non-zero exit status 255
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/bin/systemctl is-active dirsrv@EXAMPLE-COM.service
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=active

Could you please post the output of:

# ldapsearch -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -b cn=certificates,cn=ipa,cn=etc,dc=example,dc=com

?

This might be a duplicate of #6415.

# extended LDIF
#
# LDAPv3
# base <cn=certificates,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# certificates, ipa, etc, example.com
dn: cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
cn: certificates
objectClass: nsContainer
objectClass: top

# EXAMPLE.COM IPA CA, certificates, ipa, etc, example.com
dn: cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com
ipaConfigString: ipaCa
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;1
ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;26817332
 7
ipaKeyTrust: trusted
cACertificate;binary:: MIID....
cACertificate;binary:: MIID....
ipaPublicKey:: MIIB....
ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.COM
objectClass: ipaCertificate
objectClass: pkiCA
objectClass: ipaKeyPolicy
objectClass: top
cn: EXAMPLE.COM IPA CA
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3
ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4

# search result
search: 4
result: 0 Success

# numResponses: 3
# numEntries: 2

This is probably bug PKI bug, which is discussed in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1417766#c24 Comment 24 contains a workaround.

for the workaround the the CA's CS.cfg, note the order may be important:
X500Name.directoryStringEncodingOrder=UTF8String,PrintableString,T61String,BMPString,UniversalString
versus
X500Name.directoryStringEncodingOrder=PrintableString,UTF8String,T61String,BMPString,UniversalString
may not have the same effect

Adding ether line for the workaround to my CS.cfg did not cause pki-tomcat to start when I ran ipactl --ignore-service-failures restart

Metadata Update from @jose256:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5

7 years ago

Metadata Update from @mbasti:
- Issue close_status updated to: None
- Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)

7 years ago

Metadata Update from @mbasti:
- Issue set to the milestone: FreeIPA 4.5.2 (was: FreeIPA 4.5.1)

6 years ago

FreeIPA 4.5.1 has been released, moving to FreeIPA 4.5.2 milestone

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.5.3 (was: FreeIPA 4.5.2)

6 years ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.5.4 (was: FreeIPA 4.5.3)

6 years ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.5.5 (was: FreeIPA 4.5.4)

6 years ago

Metadata Update from @rcritten:
- Issue close_status updated to: insufficientinfo
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata