bobbintb Absent Member.
Absent Member.
519 views

Cert about to expire, error = -5875 when using new cert


I have been trying to figure this out for a while now and I need to get
it done before too long. We have certificates expiring soon. I know very
little about dealing with certs and the person that set this up has
moved on. We have two eDirs setup behind a VIP for load balancing. They
used to be just behind a DNS round robin. The certs for the servers and
the VIP will be expiring soon. I got the certs for the two eDir servers,
imported the one on one server to make sure everything goes ok. It
imported ok and I double checked to make sure it was valid and
everything. Once I changed the LDAP config to use the new cert then
authentication started to fail for that server so I switched it back. I
have been told I need to configure any LDAP consumers to use the new
certificate but I am not sure if that is the case. Is that
correct/typical? I talked to one of the admins of one of the services
that uses out LDAP and they talked to their co-workers and no one
remembers doing anything like that previously.

I keep getting this in the trace:


Code:
--------------------
09:05:09 601B4700 LDAP: New TLS connection 0x7c0127b0 from xxx.xxx.xxx.xxx:28158, monitor = 0xe1e09700, index = 26
09:05:09 E1E09700 LDAP: Monitor 0xe1e09700 initiating TLS handshake on connection 0x7c0127b0
09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) DoTLSHandshake on connection 0x7c0127b0
09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) TLS accept failure 5 on connection 0x7c0127b0, setting err = -5875. Error stack:
09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) TLS handshake failed on connection 0x7c0127b0, err = -5875
09:05:09 ADBBD700 LDAP: Server closing connection 0x7c0127b0, socket error = -5875
09:05:09 ADBBD700 LDAP: Connection 0x7c0127b0 closed
--------------------


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

Labels (1)
0 Likes
10 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Cert about to expire, error = -5875 when using new cert

On 03/01/2016 09:14 AM, bobbintb wrote:
>
> I have been trying to figure this out for a while now and I need to get
> it done before too long. We have certificates expiring soon. I know very
> little about dealing with certs and the person that set this up has
> moved on. We have two eDirs setup behind a VIP for load balancing. They
> used to be just behind a DNS round robin. The certs for the servers and
> the VIP will be expiring soon. I got the certs for the two eDir servers,
> imported the one on one server to make sure everything goes ok. It
> imported ok and I double checked to make sure it was valid and
> everything. Once I changed the LDAP config to use the new cert then
> authentication started to fail for that server so I switched it back. I
> have been told I need to configure any LDAP consumers to use the new
> certificate but I am not sure if that is the case. Is that
> correct/typical? I talked to one of the admins of one of the services


Typically LDAP clients should trust a CA, not a specific certificate, so
if you did that originally with whatever CA signed your current
certificate, then any new certificate signed by that same CA should also
work until that CA is expired or no-longer trusted. Trust is established
by importing the CA's public key certificate (and any intermediate
certificates from the root CA to the certificate used by (in your case)
LDAP) to the client application.

An incorrect alternative is to import the leaf-most certificate (the one
associated with your LDAP service) directly; it's wrong because trust
should be made to CAs, not the certs minted by them.

> that uses out LDAP and they talked to their co-workers and no one
> remembers doing anything like that previously.


If nobody did something previously, that implies either your applications
behave very poorly (in which case they should not be complaining now) or
else you are using a third-party CA (Digicert, etc.) so the client
applications trusted them out of the box because third-party CAs' root
certificates are present in a lot of truststores by default (e.g. your web
browser trusts your financial institution without prompting you about
certificates because they already trust the financial institution's CA).

> Code:
> --------------------
> 09:05:09 601B4700 LDAP: New TLS connection 0x7c0127b0 from xxx.xxx.xxx.xxx:28158, monitor = 0xe1e09700, index = 26
> 09:05:09 E1E09700 LDAP: Monitor 0xe1e09700 initiating TLS handshake on connection 0x7c0127b0
> 09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) DoTLSHandshake on connection 0x7c0127b0
> 09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) TLS accept failure 5 on connection 0x7c0127b0, setting err = -5875. Error stack:
> 09:05:09 ADBBD700 LDAP: (xxx.xxx.xxx.xxx:28158)(0x0000:0x00) TLS handshake failed on connection 0x7c0127b0, err = -5875
> 09:05:09 ADBBD700 LDAP: Server closing connection 0x7c0127b0, socket error = -5875
> 09:05:09 ADBBD700 LDAP: Connection 0x7c0127b0 closed
> --------------------


Get a LAN trace and post that somewhere. With tcpdump, do this:


sudo /usr/sbin/tcpdump -n -s 0 -i any -v -w /tmp/tcp636.cap port 636


Everything within should be encrypted, so not a big worry to post it.
Basically we're looking for which side tears down the connection. If the
client side, the above notes apply. If the server side, perhaps a SSL
ciphresuite/version incompatibility, which is more-common now then at any
other point in history, but really should not be the issue since you are
using the same clients/servers in all cases.

With the new LDAP certificate in place, output from the following command
may also be good to post here:


echo | openssl s_client -connect your.ldap.serverip.here:636 -showcerts


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
bobbintb Absent Member.
Absent Member.

Re: Cert about to expire, error = -5875 when using new cert


ab;265638 Wrote:
>
> Typically LDAP clients should trust a CA, not a specific certificate,
> so
> if you did that originally with whatever CA signed your current
> certificate, then any new certificate signed by that same CA should
> also
> work until that CA is expired or no-longer trusted. Trust is
> established
> by importing the CA's public key certificate (and any intermediate
> certificates from the root CA to the certificate used by (in your case)
> LDAP) to the client application.
>
> An incorrect alternative is to import the leaf-most certificate (the
> one
> associated with your LDAP service) directly; it's wrong because trust
> should be made to CAs, not the certs minted by them.
>
> If nobody did something previously, that implies either your
> applications
> behave very poorly (in which case they should not be complaining now)
> or
> else you are using a third-party CA (Digicert, etc.) so the client
> applications trusted them out of the box because third-party CAs' root
> certificates are present in a lot of truststores by default (e.g. your
> web
> browser trusts your financial institution without prompting you about
> certificates because they already trust the financial institution's
> CA).
>


Here's a little more detail on what I did. Initially I got an error
importing the certs but got that fixed with some help. I was given 2
certs after I submitted the CSR. These are GoDaddy intermediate certs.
One was "gd_bundle-g2-g1.crt" and the other had a long alpha numeric
filename. I downloaded "gd_bundle-g2.crt" from GoDaddy's repo. Following
the instruction I was given I installed the alphanumeric cert on my
Windows machine as well as "gd_bundle-g2.crt". I then went into the
Windows internet options to export the entire chain into one cert and
that allowed me to import it. I'm sure there are better ways of doing it
but those were the instructions I was given. Then I configured LDAP to
use it and that's when I got the new problem. So then does that mean I
am just missing a piece in that chain? I'll work on getting the LAN
trace and all up soon.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Cert about to expire, error = -5875 when using new cert

On 03/01/2016 11:04 AM, bobbintb wrote:
>
> Here's a little more detail on what I did. Initially I got an error
> importing the certs but got that fixed with some help. I was given 2
> certs after I submitted the CSR. These are GoDaddy intermediate certs.
> One was "gd_bundle-g2-g1.crt" and the other had a long alpha numeric
> filename. I downloaded "gd_bundle-g2.crt" from GoDaddy's repo. Following
> the instruction I was given I installed the alphanumeric cert on my
> Windows machine as well as "gd_bundle-g2.crt". I then went into the
> Windows internet options to export the entire chain into one cert and
> that allowed me to import it. I'm sure there are better ways of doing it


Ah, your other forum thread. Gotcha.

> but those were the instructions I was given. Then I configured LDAP to
> use it and that's when I got the new problem. So then does that mean I
> am just missing a piece in that chain? I'll work on getting the LAN
> trace and all up soon.


It probably means that the root certificate is not trusted by the LDAP
client/application. We will see what that reveals.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
bobbintb Absent Member.
Absent Member.

Re: Cert about to expire, error = -5875 when using new cert


After talking to our certificate guy he reminded me that the two certs
for our eDir replicas are for them to talk to each other, not for LDAP
auth. Our cert naming scheme needs work. So that makes sense that
configuring LDAP to use them doesn't work. How can I configure the
servers to use these certs between them and verify it's working? Sorry,
I'm all over the place with this.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Cert about to expire, error = -5875 when using new cert

On 03/01/2016 01:17 PM, bobbintb wrote:
>
> After talking to our certificate guy he reminded me that the two certs
> for our eDir replicas are for them to talk to each other, not for LDAP


I'm not sure at all what you mean. The certificates you put within
eDirectory have nothing to do with normal eDirectory communications, as
eDirectory comms use NCP, and do not use the PKI objects within.

> auth. Our cert naming scheme needs work. So that makes sense that
> configuring LDAP to use them doesn't work. How can I configure the
> servers to use these certs between them and verify it's working? Sorry,
> I'm all over the place with this.


Configure which servers? If you want eDirectory servers to use these
certificates for the LDAP interfaces, just link them to the LDAP Server
objects and then restart the LDAP service, or all of that eDirectory
instance if nothing else. That, by itself, will not show what you saw in
your trace, which was a connection from a client of some sort. That
client is the one that needs to trust the certificate used in eDirectory
on the LDAP server object.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
bobbintb Absent Member.
Absent Member.

Re: Cert about to expire, error = -5875 when using new cert


Sorry, it's hard to be clear when I'm confusing even myself. I have a
very limited understanding of certs, obviously, so it's hard to even ask
the right question sometimes. So our eDir servers are, say, edir01 and
edir02, and our loadbalancer, vip01. This is how I understand it: all
our services connect to vip01 and they aren't even aware of edir01 and
edir02. edir01 and edir02 are replicas for failover. I have certs
expiring for all three of these machines.

In my first post I mentioned I had added a new cert on edir01 and set
LDAP to use it resulting in that error. I thought that might be because
I don't have everything I needed in the chain. Now I am wondering if my
understand is wrong and the cert for edir01 isn't to be used for LDAP
auth but for communication between edir01 and edir02 when replicating
and also maybe for communicating with vip01. From what I understand, our
LDAP clients should be getting a cert for vip01, not edir01 or edir02.

I get the concepts mostly. I'm just having a hard time understanding the
technical details since I'm trying to understand by reverse engineering.
Hopefully I'm starting to make sense.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

0 Likes
bobbintb Absent Member.
Absent Member.

Re: Cert about to expire, error = -5875 when using new cert


So, basically, when I configured the LDAP for edir01 to use the new
certificate, I think I should have used the cert for cn=vip01 instead of
cn=edir01. Looking at the config now, that's how it was originally.
Again, I was really confusing myself. So then what do I need to do with
the cert for cn=edir01? Do I need to configure something to use it. I
hope I'm not just adding more and more to the confusion.


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Cert about to expire, error = -5875 when using new cert

On 03/01/2016 03:44 PM, bobbintb wrote:
>
> So, basically, when I configured the LDAP for edir01 to use the new
> certificate, I think I should have used the cert for cn=vip01 instead of
> cn=edir01. Looking at the config now, that's how it was originally.


That makes perfect sense if the VIP is just forwarding packets without
doing any SSL termination of its own. Since the client believes it is
connecting to vip01, the certificate offered from vip01 (meaning from
eDirectory) needs to have a Subject field that matches vip01 as accessed
by the client (e.g. vip01.company.tld).

> Again, I was really confusing myself. So then what do I need to do with
> the cert for cn=edir01? Do I need to configure something to use it. I


The only certificate that really matters to the client is the one given to
the client, which is probably (per your description) the vip01
certificate, hosted on the eDirectory boxes and accessed when the vip
forwards packets.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
bobbintb Absent Member.
Absent Member.

Re: Cert about to expire, error = -5875 when using new cert


ab;265662 Wrote:
> On 03/01/2016 03:44 PM, bobbintb wrote:
> >
> > So, basically, when I configured the LDAP for edir01 to use the new
> > certificate, I think I should have used the cert for cn=vip01 instead

> of
> > cn=edir01. Looking at the config now, that's how it was originally.

>
> That makes perfect sense if the VIP is just forwarding packets without
> doing any SSL termination of its own. Since the client believes it is
> connecting to vip01, the certificate offered from vip01 (meaning from
> eDirectory) needs to have a Subject field that matches vip01 as
> accessed
> by the client (e.g. vip01.company.tld).
>
> > Again, I was really confusing myself. So then what do I need to do

> with
> > the cert for cn=edir01? Do I need to configure something to use it. I

>
> The only certificate that really matters to the client is the one given
> to
> the client, which is probably (per your description) the vip01
> certificate, hosted on the eDirectory boxes and accessed when the vip
> forwards packets.
>
>
> --
> Good luck.
>
> If you find this post helpful and are logged into the web interface,
> show your appreciation and click on the star below...


Ok, I think I'm making some progress, after causing myself much
confusion.
So, I generated a CSR for vip01 by using iManager on edir01. I got the 2
certs back from GoDaddy and formatted them into one like I did before,
imported the new cert into edir01 and validated it. Then, as a test, I
configured LDAP on edir01 to use the new cert while I watched the trace.
Only some connections were getting a TLS failure while others seemed to
work fine. So I think i'm getting it now. It sounds like I just need to
import or configure whichever other systems (the ones that aren't
working out of the box) to use the new cert. Does that sound correct?

Additionally, when I create a CSR in iManager there then appears an
"import" link next to the nickname of the cert and I use that to import
the cert. Now that I have the cert I need to put it on edir02 as well
but since I never created a CSR on edir02, how do I import it? I tried
going to Roles and Tasks>Novell Certificate Access>Server Certificates
and creating a new one and selecting "import" but I am getting "NDS
Error -603". I'm thinking that's not the way to do it. Do I need to
create another CSR on edir02 and then import it or would that not work?


--
bobbintb
------------------------------------------------------------------------
bobbintb's Profile: https://forums.netiq.com/member.php?userid=5629
View this thread: https://forums.netiq.com/showthread.php?t=55453

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Cert about to expire, error = -5875 when using new cert

On 03/08/2016 03:54 PM, bobbintb wrote:
>
> Ok, I think I'm making some progress, after causing myself much
> confusion.
> So, I generated a CSR for vip01 by using iManager on edir01. I got the 2
> certs back from GoDaddy and formatted them into one like I did before,
> imported the new cert into edir01 and validated it. Then, as a test, I
> configured LDAP on edir01 to use the new cert while I watched the trace.
> Only some connections were getting a TLS failure while others seemed to
> work fine. So I think i'm getting it now. It sounds like I just need to
> import or configure whichever other systems (the ones that aren't
> working out of the box) to use the new cert. Does that sound correct?


Yes, precisely.

> Additionally, when I create a CSR in iManager there then appears an
> "import" link next to the nickname of the cert and I use that to import
> the cert. Now that I have the cert I need to put it on edir02 as well
> but since I never created a CSR on edir02, how do I import it? I tried
> going to Roles and Tasks>Novell Certificate Access>Server Certificates
> and creating a new one and selecting "import" but I am getting "NDS
> Error -603". I'm thinking that's not the way to do it. Do I need to
> create another CSR on edir02 and then import it or would that not work?


I think it is possible to export and import an entire certificate, but I
have not done it for a while. Worst case, request another with the same
subject name and it should be fine. I do not know about all CAs, but some
(DigiCert) give you many certs for a single subject name for a single fee.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.