On 08/07/2017 09:22 AM, Florence
Blanc-Renaud via FreeIPA-users wrote:
On 08/04/2017 11:02 PM, Ian Harding via FreeIPA-users
wrote:
On 8/4/17 2:16 AM, Florence Blanc-Renaud
wrote:
On 08/03/2017 11:13 PM, Ian Harding via
FreeIPA-users wrote:
On 08/03/2017 12:28 AM, Florence
Blanc-Renaud wrote:
On 08/02/2017 11:51 PM, Ian Harding
via FreeIPA-users wrote:
On 08/02/2017 12:11 AM, Florence
Blanc-Renaud wrote:
On 08/02/2017 01:43 AM, Ian
Harding wrote:
On 08/01/2017 12:03 PM, Rob
Crittenden wrote:
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?
There wasn't much of a change... I just assumed
someone ran yum upgrade and didn't restart, then the
power outage... it looks like not much of a version
change though.
# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed:
ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed:
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:46:06 Updated:
libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated:
python-libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:08 Installed:
python-ipaddress-1.0.16-2.el7.noarch
Jan 08 04:47:04 Installed:
python2-ipalib-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed:
python2-ipaclient-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Updated:
ipa-admintools-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed:
ipa-server-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:06 Installed:
python2-ipaserver-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:07 Updated:
sssd-ipa-1.14.0-43.el7_3.4.x86_64
Jan 08 04:47:17 Updated:
ipa-client-4.4.0-14.el7.centos.1.1.x86_64
Jan 08 04:47:23 Updated:
ipa-server-4.4.0-14.el7.centos.1.1.x86_64
Jan 08 04:47:27 Updated:
ipa-server-dns-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:36 Installed:
ipa-python-compat-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:50:07 Erased:
ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64
Jul 28 09:55:41 Updated:
ipa-common-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:42 Updated:
ipa-client-common-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:43 Updated:
ipa-server-common-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:43 Updated:
python2-ipalib-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:44 Updated:
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:45 Updated:
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:45 Updated:
ipa-admintools-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:46 Updated:
ipa-client-4.4.0-14.el7.centos.7.x86_64
Jul 28 09:55:48 Updated:
ipa-server-4.4.0-14.el7.centos.7.x86_64
Jul 28 09:55:48 Updated:
ipa-server-dns-4.4.0-14.el7.centos.7.noarch
Jul 28 09:55:48 Updated:
ipa-python-compat-4.4.0-14.el7.centos.7.noarch
# grep pki /var/log/yum.log
Jan 08 04:46:05 Updated:
pki-base-10.3.3-14.el7_3.noarch
Jan 08 04:46:09 Updated:
krb5-pkinit-1.14.1-27.el7_3.x86_64
Jan 08 04:47:19 Installed:
pki-base-java-10.3.3-14.el7_3.noarch
Jan 08 04:47:19 Updated:
pki-tools-10.3.3-14.el7_3.x86_64
Jan 08 04:47:21 Updated:
pki-server-10.3.3-14.el7_3.noarch
Jan 08 04:47:22 Updated:
pki-kra-10.3.3-14.el7_3.noarch
Jan 08 04:47:22 Updated:
pki-ca-10.3.3-14.el7_3.noarch
Jul 28 10:13:16 Updated:
pki-base-10.3.3-19.el7_3.noarch
Jul 28 10:13:17 Updated:
pki-base-java-10.3.3-19.el7_3.noarch
Jul 28 10:13:17 Updated:
pki-tools-10.3.3-19.el7_3.x86_64
Jul 28 10:13:21 Updated:
pki-server-10.3.3-19.el7_3.noarch
Jul 28 10:13:21 Updated:
pki-kra-10.3.3-19.el7_3.noarch
Jul 28 10:13:21 Updated:
pki-ca-10.3.3-19.el7_3.noarch
Are you running in SELinux enforcing mode?
# getenforce
Enforcing
If so can you run:
# ausearch -m AVC
# ausearch -m AVC
The NOLOG option to log_format is deprecated. Please
use the write_logs option.
The NOLOG option is overriding the write_logs
current setting.
----
time->Mon Mar 14 10:39:01 2016
type=SYSCALL msg=audit(1457977141.767:17537):
arch=c000003e syscall=2 success=no exit=-13
a0=7fbcab038d10 a1=800 a2=1 a3=7fbca60f42e0 items=0
ppid=1406 pid=12965 auid=4294967295 uid=0 gid=0
euid=581400001 suid=0 fsuid=581400001 egid=581400001
sgid=0 fsgid=581400001 tty=(none) ses=4294967295
comm="sshd" exe="/usr/sbin/sshd"
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
key=(null)
type=AVC msg=audit(1457977141.767:17537): avc:
denied { read } for pid=12965 comm="sshd"
name="authorized_keys" dev="dm-2" ino=116393517
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:unlabeled_t:s0
tclass=file
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
This returns
$ ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate
description
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
... stuff ...
ZNo4eX7jNT8Aa23gDl6xuLVa1SxlyE8XEo8dfAPXMJoFc=
description: 2;4;CN=Certificate
Authority,O=BPT.ROCKS;CN=CA Subsystem,O=BPT.ROCKS
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
These both return
# certutil -K -d /etc/pki/pki-tomcat/alias -n
'subsystemCert cert-pki-ca' | grep Serial
Enter Password or Pin for "NSS Certificate DB":
certutil: problem listing keys:
SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object
Identifier.
# certutil -K -d /etc/pki/pki-tomcat/alias -n
'subsystemCert cert-pki-ca' -a
certutil: Checking token "NSS Certificate DB" in
slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
certutil: problem listing keys:
SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object
Identifier.
Hi,
you made a typo and requested the keys (-K) instead of
the certs (-L). Please retry with -L and you should be
able to see the certificate serial.
[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory
manager' -W -b uid=pkidbuser,ou=people,o=ipaca
userCertificate description
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
...
ZNo4eX7jNT8Aa23gDl6xuLVa1SxlyE8XEo8dfAPXMJoFc=
description: 2;4;CN=Certificate
Authority,O=BPT.ROCKS;CN=CA Subsystem,O=BPT.ROCKS
So the serial is 4?
[root@seattlenfs ianh]# certutil -L -d
/etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
| grep Serial
Serial Number: 1341718541 (0x4ff9000d)
Which is NOT 4...
[root@seattlenfs ianh]# certutil -L -d
/etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
-a
-----BEGIN CERTIFICATE-----
MIIDbjCCAlagAwIBAgIET/kADTANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
...
sjeiFbUFtoMnfmHLIYpe5QAR
-----END CERTIFICATE-----
And this cert is NOT the same.
Hi,
when certmonger renews a certificate, it runs pre-save and
post-save commands (which you can see in the output of
getcert list). In your case, the post-save command for
subsystemCert cert-pki-ca probably failed.
This command (on the renewal master) is responsible for
copying the new cert from the NSS db to the LDAP server.
You need first to check which IPA server is the renewal
master (as the serial numbers are in a completely
different range, I assume that you have multiple IPA
servers configured with a CA instance):
$ export BASEDN=`grep basedn /etc/ipa/default.conf | cut
-d= -f2-`
$ kinit admin
$ ldapsearch -LLL -Q -h `hostname` -p 389 -Y GSSAPI -b
"cn=masters,cn=ipa,cn=etc,$BASEDN"
'(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
dn:
cn=CA,cn=vm-ipaserver.ipadomain.com,cn=masters,cn=ipa,cn=etc,dc=ipadomain,dc=com
In this example the renewal master is vm-ipaserver.
I get this
$ ldapsearch -LLL -Q -h `hostname` -p 389 -Y GSSAPI -b
"cn=masters,cn=ipa,cn=etc,$BASEDN"
'(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
dn:
cn=CA,cn=freeipa-sea.bpt.rocks,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks
Which is the other FreeIPA server.
Hi Ian,
it's getting difficult to follow this thread, so could we step
back and summarize?
Yes, it is. Sorry.
- On server freeipa-sea (=renewal master), the CA component is
installed and 'subsystemCert cert-pki-ca' has Serial number 4
in the NSSDB /etc/pki/pki-tomcat/alias
No?
[root@freeipa-sea ianh]# certutil -L -d
/etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep
Serial
Serial Number: 1341718541 (0x4ff9000d)
- On server seattlenfs (where PKI fails
to restart), the CA component is installed and 'subsystemCert
cert-pki-ca' has Serial number 1341718541 in the NSSDB
/etc/pki/pki-tomcat/alias.
Yes
[root@seattlenfs ianh]# certutil -L -d /etc/pki/pki-tomcat/alias
-n 'subsystemCert cert-pki-ca' | grep Serial
Serial Number: 1341718541 (0x4ff9000d)
- In the LDAP servers, the cert is stored in the entry
uid=pkidbuser,ou=people,o=ipaca with Serial number 4 (i.e. it
is the cert from freeipa-sea).
This is where the difference is. There are two certificates on
the master and only one on the other. I wonder if this is a
result of the slow motion replication trainwreck I have going on
due to a zombie replica in the ldap database that no longer
exists in the real world and I can't seem to get rid of.
Hi,
the remaining issue is a replication problem. There is a
"Troubleshooting replication" section [1] in IdM Admin guide that
may help you.
Regarding your zombie replica, which commands did you use to try
to remove it, and what was the output?
Flo
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-gen-replication.html
Hi,
To debug replication latency or problem we would need several info
but starting with the results of the following commands
[root@freeipa-sea ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b "uid=pkidbuser,ou=people,o=ipaca" nscpentrywsi
and
[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory manager' -W
-b uid=pkidbuser,ou=people,o=ipaca nscpentrywsi
From the output you may only copy/past the ones related to
userCertificate
Also to dump the current replication status,
send the result of
[root@freeipa-sea ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))"
and
[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory
manager' -W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))"
Regards
thierry
[root@freeipa-sea ianh]# ldapsearch -LLL
-D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca
userCertificate description
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
<truncated>
ZNo4eX7jNT8Aa23gDl6xuLVa1SxlyE8XEo8dfAPXMJoFc=
userCertificate::
MIIDbjCCAlagAwIBAgIET/kADTANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQK
<truncated> fuQQZmP1XrKkrfsjeiFbUFtoMnfmHLIYpe5QAR
description: 2;1341718541;CN=Certificate
Authority,O=BPT.ROCKS;CN=CA Subsystem
,O=BPT.ROCKS
[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory
manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate
description
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
<truncated>
ZNo4eX7jNT8Aa23gDl6xuLVa1SxlyE8XEo8dfAPXMJoFc=
description: 2;4;CN=Certificate Authority,O=BPT.ROCKS;CN=CA
Subsystem,O=BPT.RO
CKS
If you check the certificates dates, I
guess that the most recent one is on server seattlenfs
(because of serial numbers). Can you confirm this (because our
goal is to have the most recent cert stored in all the NSSDBs
and in LDAP)?
Thanks,
Flo
If your renewal master is the
machine on which the NSS DB /etc/pki/pki-tomcat/alias
contains the newer cert, then you can manually run the
scripts:
If I'm interpreting this correctly, then it is... so I ran
this on the broken machine (seattlenfs)
$ sudo
/usr/libexec/ipa/certmonger/stop_pkicad
$ sudo /usr/libexec/ipa/certmonger/renew_ca_cert
"subsystemCert cert-pki-ca"
I ran this, it took a while, then I re-checked and the
serial still seems to be 4
$ ldapsearch -LLL -D 'cn=directory manager' -W -b
uid=pkidbuser,ou=people,o=ipaca userCertificate description
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlC
...
ZNo4eX7jNT8Aa23gDl6xuLVa1SxlyE8XEo8dfAPXMJoFc=
description: 2;4;CN=Certificate Authority,O=BPT.ROCKS;CN=CA
Subsystem,O=BPT.ROCKS
Here's what was in /var/log/pki/pki-tomcat/ca/debug
[03/Aug/2017:13:52:51][localhost-startStop-1]:
============================================
[03/Aug/2017:13:52:51][localhost-startStop-1]: ===== DEBUG
SUBSYSTEM INITIALIZED =======
[03/Aug/2017:13:52:51][localhost-startStop-1]:
============================================
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
restart at autoShutdown? false
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
autoShutdown crumb file path?
/var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
about to look for cert for auto-shutdown
support:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
found cert:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
done init id=debug
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initialized debug
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initSubsystem id=log
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
ready to init id=log
[03/Aug/2017:13:52:51][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[03/Aug/2017:13:52:51][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[03/Aug/2017:13:52:51][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
restart at autoShutdown? false
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
autoShutdown crumb file path?
/var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
about to look for cert for auto-shutdown
support:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
found cert:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
done init id=log
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initialized log
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initSubsystem id=jss
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
ready to init id=jss
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
restart at autoShutdown? false
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
autoShutdown crumb file path?
/var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
about to look for cert for auto-shutdown
support:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
found cert:auditSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
done init id=jss
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initialized jss
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
initSubsystem id=dbs
[03/Aug/2017:13:52:51][localhost-startStop-1]: CMSEngine:
ready to init id=dbs
[03/Aug/2017:13:52:51][localhost-startStop-1]: DBSubsystem:
init() mEnableSerialMgmt=true
[03/Aug/2017:13:52:51][localhost-startStop-1]: Creating
LdapBoundConnFactor(DBSubsystem)
[03/Aug/2017:13:52:51][localhost-startStop-1]:
LdapBoundConnFactory: init
[03/Aug/2017:13:52:51][localhost-startStop-1]:
LdapBoundConnFactory:doCloning true
[03/Aug/2017:13:52:51][localhost-startStop-1]: LdapAuthInfo:
init()
[03/Aug/2017:13:52:51][localhost-startStop-1]: LdapAuthInfo:
init begins
[03/Aug/2017:13:52:51][localhost-startStop-1]: LdapAuthInfo:
init ends
[03/Aug/2017:13:52:51][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[03/Aug/2017:13:52:51][localhost-startStop-1]:
makeConnection: errorIfDown true
[03/Aug/2017:13:52:51][localhost-startStop-1]: TCP
Keep-Alive: true
[03/Aug/2017:13:52:51][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert
nickname to: subsystemCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]:
LdapJssSSLSocket: set client auth cert nickname
subsystemCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[03/Aug/2017:13:52:51][localhost-startStop-1]: Candidate
cert: ocspSigningCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: Candidate
cert: subsystemCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]:
SSLClientCertificateSelectionCB: desired cert found in list:
subsystemCert cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: subsystemCert
cert-pki-ca
[03/Aug/2017:13:52:51][localhost-startStop-1]: SSL handshake
happened
[03/Aug/2017:13:52:51][localhost-startStop-1]:
CMSEngine.shutdown()
I really appreciate you sticking with me through this. I
owe you.
- Ian
After that, check that the LDAP
entry has been updated. If it is the case, you should be
able to restart pki.
Flo
Thank you again for your time!
Ian
Flo.
which seems weird.
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
_______________________________________________
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org