Designer error. The certificate of host is either expired or not valid yet

[wferguson]

The certificates were updated on our IDV server and are valid...but now when launching Designer and trying to authenticate to the server, I am getting the message 'The certificate of host is either expired or not valid yet'. I did get prompted to import the new cert which looked fine...but after that is when I now get the error.

I have viewed the C:\netiq\idm\apps\Designer\configuration\LDAPServerCerts keystore and removed the contents and also the entire keystore with additional attempts to of trying to resolve the error...and even with that file removed I still get prompted with the same error.

Designer for NetIQ Identity Manager

Version: 4.8.2
Build id: 20200918

[tljunggren]

Just a quick thought, do the certificate CN or alternate names match the connection details (IP/name)?

[wferguson]

Yes sir they do match and looking at the Subject Alternative Names.....the IP address and DNS Name match.

[lhaeger]

---

@wferguson wrote:

... 'The certificate of host is either expired or not valid yet'...

So did you check the not-before and not-after attributes of the certificate?

echo | openssl s_client -connect idmserver:636 | openssl x509 -dates

Sometimes error messages just say what they mean, actually...

---

[wferguson]

I do not recall having ever run this command nor do I really understand its output....what is this telling me?

root@server ]# echo | openssl s_client -connect idmserver:636 | openssl x509 -dates
140454311712576:error:2008F002:BIO routines:BIO_lookup_ex:system lib:crypto/bio/b_addr.c:710:Name or service not known
connect:errno=11
unable to load certificate
139870460413760:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE

[lhaeger]

You would have to replace the "idmserver" part with your server's hostname or ip address as you have it configured in Designer. It will then tell you the validity of the certificate Designer sees when trying to connect to the id vault

[wferguson]

Well that makes sense...I apologize...so this is the message I get now

[root@server01 bld]# echo | openssl s_client -connect server01:636 | openssl x509 -dates
depth=0 O = QA, CN = server01
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = QA, CN = server01
verify error:num=21:unable to verify the first certificate
verify return:1
DONE
notBefore=Mar 29 18:34:30 2021 GMT
notAfter=Mar 29 18:34:30 2023 GMT
-----BEGIN CERTIFICATE-----
removed this data
-----END CERTIFICATE-----

[wferguson]

and getting this output from a server in our dev environment that is not having issues....I see the differences in failing QA environment to working DEV environment in these two commands from this post and my previous post from QA....but I am not sure what the depth of 0 in the failing server and depth of 1 success here means or how to correct.

[root@server02 ~]# echo | openssl s_client -connect server02.edu:636 | openssl x509 -dates
depth=1 OU = Organizational CA, O = DEV
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 OU = Organizational CA, O = DEV
verify return:1
depth=0 O = DEV, CN = server02.edu
verify return:1
DONE
notBefore=May 29 19:03:39 2020 GMT
notAfter=May 29 19:03:39 2022 GMT

[lhaeger]

The depth=x is about how many steps a certificate is away from the server cert in the chain. Here you have depth=0 for the server cert and depth=1 for the signing CA. If you had intermediate CAs in the chain, you'd see depth=2 or even higher values as well.

In your first case the server is using a self-signed certificate (only depth=0 O = QA, CN = server01, no depth=1 entry), in the second case the server cert is signed by the tree CA ("depth=1 OU = Organizational CA, O = DEV"). You could try to switch the server01 LDAP cert to a signed one, or maybe run the "repair default certificates" task in iManager if that's what LDAP is using.

You could also try replacing the "-dates" option with "-noout -text" to get all certificate details printed in human readable format. Maybe that reveals some more hints like SANs not matching the hostname or so.

[lhaeger]

---

@wferguson wrote:

notBefore=Mar 29 18:34:30 2021 GMT

---

Btw. when did you last see the error in Designer? Before or after yesterday evening 6:34pm?What is GMT in your timezone?

Maybe it was just a simple time sync/mismatch issue between your server and the Designer workstation that has already solved itself?

[wferguson · Accepted solution]

The issue was that after the move of the CA and the repair of the default certs were completed on the other two servers......eDirectory needed to be restarted. We did not know that was needed since we had to have eDirectory down in order to do the backup and move of the CA...thank you all for the responses and I have saved the ssl commands 🙂