Turned on TLS for my AD source. It was working on 389 and in the server field, I add the domain name.
When i turn on TLS and switch to 636 it no longer works with the domain name. If i change the name in the server to one of my DCs it works. Any reason why it won’t work with the domain name? One of my teammates suggested added the cert to the java cacert store in the VA but i couldn’t find where to do that. Any other possible solutions.
Error below
java.lang.Exception: [ERROR 1] Failed to connect to server:ldap://carp.fishy.com:636 - javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed
You need to have a certificate where the name of the server being requested matches the name of the response. So, I would guess that your servers are returning their host names and not the domain.
You can add certificates to your virtual appliance by placing the certificate in the /home/sailpoint/certificates directory.
What are you calling the “sub certificate”? Is your Domain Controller signed directly by the root certificate, or by an intermediate certificate authority?
Either way, you should only need the root certificate, if all of the DCs to which you connect are ultimately signed by the same same root CA.
One the PXIK path-building error goes away, that means you have fixed the VA. However, it will likely move on to a new error returned from the IQService unless you also add the root CA to the Trusted Root Certification Authorities trust store on for the Computer on the IQService machine(s) that connect to the DC.
Now when I do test connection, it says connection reset. That is odd because it was working and now it doesn’t want to work. I unchecked tls in the iqservice area and checked it again. that is the only setting i changed. Finding it odd that it broke the communication.
So your root and intermediate certificates should be in the certificate chain of your AD domain certificate.
Now you need to look in the certificate for the domain as Vipinjeet suggested. Make sure that the certificate chain had the intermediate and root certificates. Also verify that the name that you are putting in the command for <DC_FQDN> in the certificate either in the name or subject alternate name field.
When you ran the openssl command was the domain name in the name field of the certificate or the subject alternate name for the certificate?
Since your certificates are on your virtual appliance, you can try to reference the path in the openssl command to get past the verification error. Try this: