De l'importance d'utiliser un nom de serveur correspondant au CN du certificat...
Contexte
Afin de pouvoir tester la connexion d'un OpenIDM sur un serveur AD (et par la suite la mise en place du plugin de synchronisation de mot de passe) j'ai mis en place une maquette simple avec :
- un serveur OpenIDM sous CentOS
- un serveur AD sous Windows 2008R2
J'ai mis en place un certificat sur le serveur AD, qui est aussi le contrôleur de domaine principal, avec un certificat qu'il a généré.
J'ai importé le certificat dans le Keystore OpenIDM, comme pour toute connexion sécurisée.
Problème
Mais cependant, impossible d'avoir une connexion opérationnelle. La connexion en LDAPS ne fonctionne pas (port 636 / ssl = "true"), alors qu'elle est opérationnelle en LDAP (port 389 / ssl="false")
Au démarrage, on trouve ceci dans les logs :
SEVERE: OpenICF connector test of SystemIdentifier{ uri='system/AD/'} failed!
org.identityconnectors.framework.common.exceptions.ConnectionFailedException: javax.naming.CommunicationException: mytest-dc.local:636 [Root exception is java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)]
Même chose en testant via une requête REST :
http://engine.local:8180/openidm/system/AD/?_action=test Caused by: javax.naming.CommunicationException: mytest-dc.local:636 [Root exception is java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)]
Cause et résolution
Au final, il s'agissait d'un problème de nom DNS. En effet, le serveur AD a son propre nom DNS, et ce n'est pas celui que j'utilisais dans ma connexion (mytest-dc.local).
Les logs me donnaient bien une piste :
WARNING: Resource exception: 500 Internal Server Error: "javax.naming.CommunicationException: simple bind failed: mytest-dc.local:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching mytest-dc.local found.]"
J'ai donc modifié le fichier conf/boot/boot.properties pour positionner le nom de machine égal au CN du certificat du serveur, que l'on peut récupérer avec la commande suivante :
openssl x509 -in adldaps.pem -noout -text |grep Subject
Subject: CN=WIN-RLQ30AF9URF.group.id-num.com
Subject Public Key Info:
X509v3 Subject Key Identifier:
X509v3 Subject Alternative Name:Une fois le paramétrage du nom effectué, et après avoir modifié mon fichier /etc/hosts pour que mon serveur OpenIDM arrive à faire le lien entre l'adresse IP et le nom, tout est allé beaucoup mieux.
Pour que la modification soit prise en compte, il a fallu redémarrer OpenIDM (puisque mon paramétrage se trouve dans le fichier boot.properties).
Il a également fallu que je passe par la console d'admin, et que je valide la connexion AD pour que cela soit opérant.