[Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
Michael Plemmons
michael.plemmons at crosschx.com
Thu May 18 13:49:49 UTC 2017
*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemmons at crosschx.com
www.crosschx.com
On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <flo at redhat.com>
wrote:
> On 05/15/2017 08:33 PM, Michael Plemmons wrote:
>
>> I have done more searching in my logs and I see the following errors.
>>
>> This is in the localhost log file /var/lib/pki/pki-tomcat/logs
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.ApplicationContext log
>> SEVERE: StandardWrapper.Throwable
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
>> loadOnStartup
>> SEVERE: Servlet [castart] in web application [/ca] threw load() exception
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:09 PM org.apache.catalina.core.StandardHostValve invoke
>> SEVERE: Exception Processing /ca/admin/ca/getStatus
>> javax.ws.rs <http://javax.ws.rs>.ServiceUnavailableException: Subsystem
>> unavailable
>>
>>
>> Looking at the debug log it says Authentication failed for port 636.
>>
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init begins
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init ends
>> [15/May/2017:17:39:25][localhost-startStop-1]: init: before
>> makeConnection errorIfDown is true
>> [15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname to:
>> subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake happened
>> Could not connect to LDAP server host ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com> port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConne
>> ction(LdapBoundConnFactory.java:205)
>>
>>
>> I looked at the validity of the cert it mentions and it is fine.
>>
>> (root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>> cert-pki-ca'
>> State MONITORING, stuck: no.
>>
>>
>> I then looked at the ldap errors around the time of this failure and I
>> am seeing this log entry.
>>
>>
>> [15/May/2017:17:38:42.063080758 +0000] set_krb5_creds - Could not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM
>> <mailto:ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM>] in keytab
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
>> requested realm)
>>
>> When I perform a klist against that keytab nothing appears out of the
>> ordinary compared to working IPA servers.
>>
>> I am not sure what to look at next.
>>
>>
> Hi,
>
> you can try the following to manually replay the connection established by
> Dogtag to LDAP server:
>
> root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
> root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'
>
> The above commands specify the NSSDB containing the user certificate and
> its name for SASL-EXTERNAL authentication.
>
> Then note the value obtained below as it will be used for the next step as
> the password to access the private key in the NSSDB:
> root$ grep internal /etc/pki/pki-tomcat/password.conf
> internal=<some value>
>
> root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
> -LLL dn namingcontexts
> Please enter pin, password, or pass phrase for security token 'ldap(0)':
> <<<< here supply the value found above
> dn:
> namingcontexts: cn=changelog
> namingcontexts: dc=ipadomain,dc=com
> namingcontexts: o=ipaca
>
>
So I guess I found my problem.
(root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token 'ldap(0)':
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
additional info: TLS error -12195:Peer does not recognize and trust the
CA that issued your certificate.
I looked at our certs in /etc/dirsrv/slapd-IPADOMAIN-COM and found the
following.
IPA12 - problem server
(root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
IPADOMAIN-COM IPA CA C,,
IPA11/IPA13 - 11 was the master and 13 is the new master
(root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
IPADOMAIN-COM IPA CA CT,C,C
>
> In the LDAP server access log (in /etc/dirsrv/slapd-IPADOMAIN.COM/access),
> you should see the corresponding connection:
>
> [18/May/2017:13:35:14.822090417 +0200] conn=297 fd=150 slot=150 SSL
> connection from xxx to yyy
> [18/May/2017:13:35:15.789414017 +0200] conn=297 TLS1.2 128-bit AES-GCM;
> client CN=CA Subsystem,O=IPADOMAIN.COM; issuer CN=Certificate Authority,O=
> IPADOMAIN.COM
> [18/May/2017:13:35:15.793108509 +0200] conn=297 TLS1.2 client bound as
> uid=pkidbuser,ou=people,o=ipaca
> [18/May/2017:13:35:15.798101505 +0200] conn=297 op=0 BIND dn=""
> method=sasl version=3 mech=EXTERNAL
> [18/May/2017:13:35:15.800322076 +0200] conn=297 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca"
>
> HTH,
> Flo.
>
>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com>
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Wed, May 10, 2017 at 3:35 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com <mailto:michael.plemmons at crosschx.com>>
>> wrote:
>>
>> The PKI service came up successfully but only when it uses BasicAuth
>> rather than SSL auth. I am not sure about what I need to do in
>> order to get the auth working over SSL again.
>>
>> None of the certs are expired when I run getcert list and
>> ipa-getcert list.
>>
>> Since the failure is with attempts to login to LDAP over 636. I
>> have been attempting to auth to LDAP via port 636 and the ldapsearch
>> is not completing. When looking at packet captures, I see some the
>> TCP handshake and what appears to be the start of a SSL process and
>> then everything hangs.
>>
>> What is the proper method to test performing a ldapsearch over 636?
>> Also, the CS.cfg shows it wants to auth as cn=Directory Manager. I
>> can successfully auth with cn=Directory Manager over 389 but I think
>> I am not performing ldapsearch over 636 correctly.
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com>
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:33 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>> wrote:
>>
>> I think I found the email thread. Asking for help with crashed
>> freeIPA istance. That email pointed to this
>> link, https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html
>> <https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html>.
>> That link talked about changing the CS.cfg file to use port 389
>> for PKI to auth to LDAP. I made the necessary changes and PKI
>> came up successfully.
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com>
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:19 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>> wrote:
>>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com
>> >
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:15 PM, Rob Crittenden
>> <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>
>> Michael Plemmons wrote:
>> > I just realized that I sent the reply directly to Rob
>> and not to the
>> > list. My response is inline
>>
>> Ok, this is actually good news.
>>
>> I made a similar proposal in another case and I was
>> completely wrong.
>> Flo had the user do something and it totally fixed their
>> auth error, I
>> just can't remember what it was or find the e-mail
>> thread. I'm pretty
>> sure it was this calendar year though.
>>
>> rob
>>
>>
>> Do you or Flo know what I could search for in the past
>> emails to find the answer to the problem?
>>
>>
>>
>> >
>> >
>> >
>> > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> > *
>> > 614.427.2411
>> > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> > www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>> >
>> > On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons
>> > <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>
>> > wrote:
>> >
>> >
>> >
>> >
>> >
>> > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> > *
>> > 614.427.2411
>> > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> > www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>> >
>> > On Thu, May 4, 2017 at 9:24 AM, Rob Crittenden
>> <rcritten at redhat.com <mailto:rcritten at redhat.com>
>> > <mailto:rcritten at redhat.com
>> <mailto:rcritten at redhat.com>>> wrote:
>> >
>> > Michael Plemmons wrote:
>> > > I realized that I was not very clear in my
>> statement about
>> > testing with
>> > > ldapsearch. I had initially run it without
>> logging in with a
>> > DN. I was
>> > > just running the local ldapsearch -x
>> command. I then tested on
>> > > ipa12.mgmt and ipa11.mgmt logging in with a
>> full DN for the
>> > admin and
>> > > "cn=Directory Manager" from ipa12.mgmt
>> (broken server) and
>> > ipa11.mgmt
>> > > and both ldapsearch command succeeded.
>> > >
>> > > I ran the following from ipa12.mgmt and
>> ipa11.mgmt as a non
>> > root user.
>> > > I also ran the command showing a line count
>> for the output and
>> > the line
>> > > counts for each were the same when run from
>> ipa12.mgmt and
>> > ipa11.mgmt.
>> > >
>> > > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>> -D "DN" -w PASSWORD -b
>> > >
>> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>> > >
>> > > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>> -D "cn=directory
>> manager" -w
>> > PASSWORD dn
>> >
>> > The CA has its own suffix and replication
>> agreements. Given the auth
>> > error and recent (5 months) renewal of CA
>> credentials I'd check
>> > that the
>> > CA agent authentication entries are correct.
>> >
>> > Against each master with a CA run:
>> >
>> > $ ldapsearch -LLL -x -D 'cn=directory manager'
>> -W -b
>> > uid=ipara,ou=people,o=ipaca description
>> >
>> > The format is 2;serial#,subject,issuer
>> >
>> > Then on each run:
>> >
>> > # certutil -L -d /etc/httpd/alias -n ipaCert
>> |grep Serial
>> >
>> > The serial # should match that in the
>> description everywhere.
>> >
>> > rob
>> >
>> >
>> >
>> > On the CA (IPA13.MGMT) I ran the ldapsearch
>> command and see that the
>> > serial number is 7. I then ran the certutil
>> command on all three
>> > servers and the serial number is 7 as well.
>> >
>> >
>> > I also ran the ldapsearch command against the
>> other two servers and
>> > they also showed a serial number of 7.
>> >
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > *Mike Plemmons | Senior DevOps Engineer |
>> CROSSCHX
>> > > *
>> > > 614.427.2411
>> > > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> > <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> > <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>>
>> > > www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com>
>> > <http://www.crosschx.com/>
>> > >
>> > > On Wed, May 3, 2017 at 5:28 PM, Michael
>> Plemmons
>> > > <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>>
>> > > wrote:
>> > >
>> > > I have a three node IPA cluster.
>> > >
>> > > ipa11.mgmt - was a master over 6 months
>> ago
>> > > ipa13.mgmt - current master
>> > > ipa12.mgmt
>> > >
>> > > ipa13 has agreements with ipa11 and
>> ipa12. ipa11 and
>> > ipa12 do not
>> > > have agreements between each other.
>> > >
>> > > It appears that either ipa12.mgmt lost
>> some level of its
>> > replication
>> > > agreement with ipa13. I saw some level
>> because users /
>> > hosts were
>> > > replicated between all systems but we
>> started seeing DNS
>> > was not
>> > > resolving properly from ipa12. I do not
>> know when this
>> > started.
>> > >
>> > > When looking at replication agreements
>> on ipa12 I did not
>> > see any
>> > > agreement with ipa13.
>> > >
>> > > When I run ipa-replica-manage list all
>> three hosts show
>> > has master.
>> > >
>> > > When I run ipa-replica-manage ipa11.mgmt
>> I see ipa13.mgmt
>> > is a replica.
>> > >
>> > > When I run ipa-replica-manage ipa12.mgmt
>> nothing returned.
>> > >
>> > > I ran ipa-replica-manage connect
>> --cacert=/etc/ipa/ca.crt
>> > > ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>
>> > > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>> on ipa12.mgmt
>> > >
>> > > I then ran the following
>> > >
>> > > ipa-replica-manage force-sync --from
>> > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>
>> > >
>> > > ipa-replica-manage re-initialize --from
>> > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>
>> > >
>> > > I was still seeing bad DNS returns when
>> dig'ing against
>> > ipa12.mgmt.
>> > > I was able to create user and DNS
>> records and see the
>> > information
>> > > replicated properly across all three
>> nodes.
>> > >
>> > > I then ran ipactl stop on ipa12.mgmt and
>> then ipactl start on
>> > > ipa12.mgmt because I wanted to make sure
>> everything was
>> > running
>> > > fresh after the changes above. While
>> IPA was staring up (DNS
>> > > started) we were able to see valid DNS
>> queries returned but
>> > > pki-tomcat would not start.
>> > >
>> > > I am not sure what I need to do in order
>> to get this
>> > working. I
>> > > have included the output of certutil and
>> getcert below
>> > from all
>> > > three servers as well as the debug
>> output for pki.
>> > >
>> > >
>> > > While the IPA system is coming up I am
>> able to
>> > successfully run
>> > > ldapsearch -x as the root user and see
>> results. I am also
>> > able to
>> > > login with the "cn=Directory Manager"
>> account and see results.
>> > >
>> > >
>> > > The debug log shows the following error.
>> > >
>> > >
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > > =============================
>> ===============
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: =====
>> DEBUG
>> > > SUBSYSTEM INITIALIZED =======
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > > =============================
>> ===============
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > restart at
>> > > autoShutdown? false
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > autoShutdown crumb file path?
>> > >
>> /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > about to
>> > > look for cert for auto-shutdown
>> support:auditSigningCert
>> > cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > found
>> > > cert:auditSigningCert cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > done init
>> > > id=debug
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initialized debug
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initSubsystem id=log
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > ready to
>> > > init id=log
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
>> > >
>> >
>> RollingLogFile(/var/lib/pki/pk
>> i-tomcat/logs/ca/signedAudit/ca_audit)
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
>> > >
>> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
>> > >
>> RollingLogFile(/var/lib/pki/p
>> ki-tomcat/logs/ca/transactions)
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > restart at
>> > > autoShutdown? false
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > autoShutdown crumb file path?
>> > >
>> /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > about to
>> > > look for cert for auto-shutdown
>> support:auditSigningCert
>> > cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > found
>> > > cert:auditSigningCert cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > done init
>> > > id=log
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initialized log
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initSubsystem id=jss
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > ready to
>> > > init id=jss
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > restart at
>> > > autoShutdown? false
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > autoShutdown crumb file path?
>> > >
>> /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > about to
>> > > look for cert for auto-shutdown
>> support:auditSigningCert
>> > cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > found
>> > > cert:auditSigningCert cert-pki-ca
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > done init
>> > > id=jss
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initialized jss
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > > initSubsystem id=dbs
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> CMSEngine:
>> > ready to
>> > > init id=dbs
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > DBSubsystem: init()
>> > > mEnableSerialMgmt=true
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
>> > > LdapBoundConnFactor(DBSubsystem)
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > LdapBoundConnFactory:
>> > > init
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > > LdapBoundConnFactory:doCloning true
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > LdapAuthInfo: init()
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > LdapAuthInfo: init begins
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> > LdapAuthInfo: init ends
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]: init:
>> before
>> > > makeConnection errorIfDown is true
>> > >
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> makeConnection:
>> > > errorIfDown true
>> > >
>> [03/May/2017:21:22:02][localhost-startStop-1]:
>> > > SSLClientCertificateSelectionCB: Setting
>> desired cert
>> > nickname to:
>> > > subsystemCert cert-pki-ca
>> > >
>> [03/May/2017:21:22:02][localhost-startStop-1]:
>> > LdapJssSSLSocket: set
>> > > client auth cert nickname subsystemCert
>> cert-pki-ca
>> > >
>> [03/May/2017:21:22:02][localhost-startStop-1]:
>> > > SSLClientCertificatSelectionCB: Entering!
>> > >
>> [03/May/2017:21:22:02][localhost-startStop-1]:
>> > > SSLClientCertificateSelectionCB:
>> returning: null
>> > >
>> [03/May/2017:21:22:02][localhost-startStop-1]: SSL
>> > handshake happened
>> > > Could not connect to LDAP server host
>> > ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.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.DBSu
>> bsystem.init(DBSubsystem.java:654)
>> > > at
>> > >
>> >
>> com.netscape.cmscore.apps.CMSE
>> ngine.initSubsystem(CMSEngine.java:1169)
>> > > at
>> > >
>> >
>> com.netscape.cmscore.apps.CMSE
>> ngine.initSubsystems(CMSEngine.java:1075)
>> > > at
>> >
>> com.netscape.cmscore.apps.CMS
>> Engine.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.NativeMethodAccess
>> orImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > > at
>> > >
>> >
>> sun.reflect.DelegatingMethodAc
>> cessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > > at
>> java.lang.reflect.Method.invoke(Method.java:498)
>> > > at
>> > >
>> >
>> org.apache.catalina.security.S
>> ecurityUtil$1.run(SecurityUtil.java:288)
>> > > at
>> > >
>> >
>> org.apache.catalina.security.S
>> ecurityUtil$1.run(SecurityUtil.java:285)
>> > > at
>> java.security.AccessController.doPrivileged(Native
>> > Method)
>> > > at javax.security.auth.Subject.do
>> <http://javax.security.auth.Subject.do>
>> > <http://javax.security.auth.Subject.do
>> <http://javax.security.auth.Subject.do
>> >>AsPrivileged(Subject.java:549)
>> > > at
>> > >
>> >
>> org.apache.catalina.security.S
>> ecurityUtil.execute(SecurityUtil.java:320)
>> > > at
>> > >
>> >
>> org.apache.catalina.security.S
>> ecurityUtil.doAsPrivilege(SecurityUtil.java:175)
>> > > at
>> > >
>> >
>> org.apache.catalina.security.S
>> ecurityUtil.doAsPrivilege(SecurityUtil.java:124)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Stand
>> ardWrapper.initServlet(StandardWrapper.java:1270)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Stand
>> ardWrapper.loadServlet(StandardWrapper.java:1195)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Stand
>> ardWrapper.load(StandardWrapper.java:1085)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Stand
>> ardContext.loadOnStartup(StandardContext.java:5318)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Stand
>> ardContext.startInternal(StandardContext.java:5610)
>> > > at
>> > >
>> >
>> org.apache.catalina.util.Lifec
>> ycleBase.start(LifecycleBase.java:147)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Conta
>> inerBase.addChildInternal(ContainerBase.java:899)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Conta
>> inerBase.access$000(ContainerBase.java:133)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Conta
>> inerBase$PrivilegedAddChild.run(ContainerBase.java:156)
>> > > at
>> > >
>> >
>> org.apache.catalina.core.Conta
>> inerBase$PrivilegedAddChild.run(ContainerBase.java:145)
>> > > at
>> java.security.AccessController.doPrivileged(Native
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170518/03a72c85/attachment.htm>
More information about the Freeipa-users
mailing list