Timothy Geier wrote:

On Feb 9, 2016, at 2:58 AM, Rob Crittenden <rcrit...@redhat.com> wrote:

Timothy Geier wrote:


The debug log has a lot of instances of:

Could not connect to LDAP server host xxx.xxxx port 636 Error
netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
Internal Database Error encountered: Could not connect to LDAP server
host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)

The 389-ds access log may show connection attempts and you might be able to 
correlate from there.


[09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL connection from 
master_ip to master_ip
[09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT oid="1.3.6.1.4.1.1466.20037" 
name="startTLS"
[09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120 nentries=0 
etime=0
[09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime error -8181 
(Peer's Certificate has expired.); unauthenticated client CN=CA 
Subsystem,O=XXXXXXX.NET; issuer CN=Certificate Authority,O=XXXXXXX.NET
[09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's 
Certificate has expired.


Ok, right. The subsystem cert expired on Feb 1 so you'd have to back at least that far in time to do the renewals.

<snip>


Some data is also stored in CS.cfg so you might ensure that the certificates 
stored there are correct as well.


CS.cfg is correct/restored from backup.

There are a few entries in ou=People,o=ipaca that need to reflect the current 
state of certificates as well.


While looking in cn=config for any o=ipaca entries, the following popped up..it 
looks like most of the old replicas and the old master hostnames weren’t 
properly cleaned up and there’s still RUVs for them..nsDS5ReplicaHost and Port 
also seem to be improperly set:

A problem for a future day I think.

ou=People doesn’t seem to exist in either the main tree or cn=config.

The base is ou=People,o=ipaca

Ok, you'll need to look at the host keytabs because something seems wrong with 
them. certmonger can't get a ticket using them. This could be because IPA isn't 
fully running but it is worth a look.

All of the host keytabs on all of the IPA servers are correct..are there any 
other keytabs to check?

No, just /etc/krb5.keytab. I think you should focus on getting the CA subsystem certs renewed and then we can look at the other things. So I'd go back in time to Jan 30 or so and just restart certmonger.

rob



Is this the correct procedure to follow when time shifted?

- Stop IPA
- Change the system clock (and the hardware clock) to a point before the
expiration
- Start IPA
- Run getcert resubmit on the appropriate request IDs
- Stop IPA
- Return to real time
- Start IPA

We haven’t tried it this week yet but all attempts at it last week
failed without any indication as to why the certs weren’t renewing; are
there any other logs to check/other steps in the procedure?

Yes, that is correct.


Thanks for the clarification.  The IPA cluster itself is still doing ok after 
about a week of being in this state but something else we’re wondering is if 
we’ll be able to add replica servers while this is going on..it’s not critical 
to do so, but it is going to come up fairly soon.

rob



"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited.
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to