For context this server has been using LDAPS for a year or more now. And i even recently had to test the settings and update the bind user. So it was working fine.
Im trying to figure out why jenkins is trying to resolve this SAN instead of the FQDN that we use or even the machine hostname plus the domain.
Jenkins is failing LDAPS authentication with an error 'No subject alternative DNS name matching OURDOMAIN net found,’ despite updating all truststores and certificates, our IT department has confirmed there have been no CA/DC configuration changes.
Caused: javax.naming.CommunicationException: OURDOMAIN.net:636 [Root exception is javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching OURDOMAIN.net found.]
We are running 2 Jenkins servers on 2 separate Windows machines currently it is a slightly older version of Jenkins: 2.426.3 is the one i am focused on.
One of them has to remain an older version due to some compatibility issues.
Both broke at the same time, our root CA seemed to fix this LDAPS on another server not related to jenkins but im at a loss for Jenkins.
Ive re installed and imported and made multiple CSR etc even altering the Jenkins truststore to point to the jdk11.0.10 cacert as well as tried to use Windows-ROOT for MMC.
None of the Certs are expired either.
Neither fixes this error when attempting to login while LDAPS is setup.
this is the plugin info from the config.xml