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?
ipactl start
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.
getcert list
status: MONITORING
Additional debugging info: https://www.freeipa.org/page/Troubleshooting#PKI_Issues
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.
ipa-certupdate
[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:
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
Metadata Update from @mbasti: - Issue close_status updated to: None - Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)
Metadata Update from @mbasti: - Issue set to the milestone: FreeIPA 4.5.2 (was: FreeIPA 4.5.1)
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)
Metadata Update from @tkrizek: - Issue set to the milestone: FreeIPA 4.5.4 (was: FreeIPA 4.5.3)
Metadata Update from @tkrizek: - Issue set to the milestone: FreeIPA 4.5.5 (was: FreeIPA 4.5.4)
Metadata Update from @rcritten: - Issue close_status updated to: insufficientinfo - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.