Windows Server (2003) et génération de certificats - Page 1

Bon, dans le genre question débile...
Je cherche quelqu'un qui s'y connaisse en procédures de gestion de certificats (génération et utilisation) entre un serveur 2003 et un serveur Linux.

J'explique brièvement mon problème, je peux donner des détails à la demande (pas la peine de me renvoyer sur des pages trouvées sur Google, ça fait 3 jours que je suis là-dessus et je n'arrive pas à trouver de réponse vraiment détaillée) :

J'ai un serveur W2003 qui gère un domaine et son AD. Sur ce serveur, j'ai installé l'outil de gestion des certificats et IIS.
J'ai besoin de pouvoir changer les mots de passes de l'AD à partir d'une appli Web. Pour ça, il existe un attribut (un peu bâtard, mais c'est pas le problème) unicodePasswd en écriture seule qu'on ne peut mettre à jour que lorsque la connexion entre le client LDAP et l'AD est sécurisée.
J'ai donc généré un certificat (probablement pas exactement comme il faut) que j'ai placé dans mon magasin de certificats sur mon serveur Linux.
J'arrive (après avoir bien bataillé) à ouvrir une connexion sécurisée avec SSL en utilisant ce certificat. Je peux faire des requêtes comme je veux, mais je n'ai toujours pas le droit d'écrire dans l'attribut unicodePwd.
Il ne s'agit pas d'un problème de droits LDAP (le message que j'ai n'est pas "Invalid credentials", mais "Modify: Server is unwilling to perform"), mais bien d'un souci de refus du fait que la sécurité de la connexion n'est pas assurée.
Je pense que ça vient du fait que dans les logs, je vois un message d'erreur au niveau TLS a propos du nom d'hôte du serveur, mais je ne comprends pas pourquoi il accepte quand même de se connecter.

Bref : je ne maîtrise pas du tout la gestion des certificats ; si quelqu'un a des pistes, je suis preneur...

Logs de qui ? du client LDAP (linux) ou du serveur LDAP (windows) ?

Le certificat, est-il bien généré spécifiquement pour le client ? (je sais pas trop comment on fait, juste qu'on peut générer des certifs pour chaque client)

Sinon, ce qui peut se passer, c'est que le client s'en foute que la connexion ne soit pas complètement sécurisée, et que le serveur le demande uniquement pour la modif, non ?
Accessoirement, est-ce que le certif client est vraiment reconnu comme valide par Windows ? Pour ça, il faut que l'AC de ton serveur soit dans le bon magasin.

Flanker (./2) :
Le certificat, est-il bien généré spécifiquement pour le client ? (je sais pas trop comment on fait, juste qu'on peut générer des certifs pour chaque client)

J'ai l'impression, mais bon... c'est bizarre, j'ai l'impression qu'il attend que ma machine soit déclarée sur l'AD, or ça n'est pas possible dans les faits.

Flanker (./2) :
Logs de qui ? du client LDAP (linux) ou du serveur LDAP (windows) ?

Logs du client LDAP... j'ai pas eu le temps de regarder où étaient les logs sur l'AD.

Flanker (./2) :
Sinon, ce qui peut se passer, c'est que le client s'en foute que la connexion ne soit pas complètement sécurisée, et que le serveur le demande uniquement pour la modif, non ?

Oui, c'est ce que je pense... mais je n'ai pas la compétence pour savoir où se situe exactement le problème...

Quelles sont les informations dans le certificat ? (double-clic dessus avec Windows, par exemple, ça devrait marcher)

Je te réponds demain, je ne suis plus au travail ^^

la connexion SSL veut bien s'établir mais le certificat est peut être
-pas encore valide (j'ai déja eu le pb )
-correspond pas au nom d'hote du client (pas son ip, son nom dns)
-n'est pas signé par une CA connue du serveur comme "de confiance"
-est autosigné (ce qui revient au même)
dans tous les cas la connexion est chiffrée et authentifiée, mais comme le serveur ne peut pas vérifier l'identité du certificat client, il refuse d'accorder des droits.

en gros c'est comme quand tu vas sur un site a certificat invalide, firefox t'avertit que la connexion est pas sécurisée même si les données qui transitent sont chiffrées: c'est l'identité des pairs qui n'est pas validée.

quand on joue avec des certifs, il en faut un autosigné qui se comporte comme l'autorité, qui doit être ajouté au magasin windows "autorités de certification de confiance" sur le serveur, puis générer une deuxième clé, une CSR, et la signer avec le certificat 'autorité', et donner la clé+certif au client. Et en prod on envoie le CSR a verisign&al avec du pognon et ils te renvoient un certif vraiment signé avec un truc déja dans les autorités connues de windows/firefox/autre.

je connais pas tes compétences SSL donc ce que je dis est ptet évident, mais ou pas, donc je le dis quand même.

squalyl (./6) :
-correspond pas au nom d'hote du client (pas son ip, son nom dns)

Je pense que c'est ce qui arrive, à voir la tête de ce que j'ai trouvé dans les logs.

squalyl (./6) :
je connais pas tes compétences SSL donc ce que je dis est ptet évident, mais ou pas, donc je le dis quand même.

Euh, on peut dire qu'elles sont quasi nulles, en fait (un peu de théorie, pas mal de découvertes en trifouillant pour ce problème, plus l'expérience utilisateur de tout le monde avec les certificats sur le web).

bon l'incantation magique alors c'est "openssl x509" ^^

oui, ça j'avais compris le problème c'est que je ne suis pas sûr de générer un certificat correct avec l'outil de Microsoft... il me demande effectivement le nom de la machine client, mais...
Je dois faire quoi ? Donner le nom de la machine ? Sous quel format (DNS ? LDAP ? - et comment mon serveur sait que ce client a réellement ce nom, sachant qu'il n'est pas renseigné dans mon DNS ?!) L'adresse IP ?

(m'en doute )

normalement c'est DNS.
a mon avis c'est ça qui merde ^^
a moins qu'il sache utiliser le nom netbios, ou hosts. va falloir tester

(le pb c'est que je ne connais rien à ldap moi y'a ptet des liens avec les CN=truc et tout le bazar)

Bon, j'espère partir en week-end avec un truc qui fonctionne ^^

Putain, je suis une méga tanche x_x

En fait, tout était bon, c'est juste que comme ce putain d'attribut n'est pas un "vrai" attribut LDAP au sens strict du terme (si ça intéresse des gens, voir la box), et que le mot de passe que je voulais mettre en remplacement ne respectais pas les critères de sécurité Windows x_x (il y a une logueur minimale, il faut de l'alphanumérique et un caractère spécial - je ne respectais pas ce dernier point)).


Bon, bref, merci quand même pour tout, ça m'a permis de comprendre des trucs sur les certificats .

c'est le genre de truc sur lequel on bloque 1 semaine parce qu'on'attendait pas du tout ça

tant mieux si t'as trouvé

Un autre détail, si jamais quelqu'un tombe sur ce sujet en faisant des recherches :

Faire suivre
$ldapconn = ldap_connect("ldaps://xxxxxxxx", 636) or die("Impossible de se connecter au serveur LDAP.");
par
ldap_start_tls($ldapconn):

Renverra un warning comme quoi il y a déjà une session TLS/SSL active. le simple fait d'indiquer "ldaps://" fait que l'API négocie automatiquement en SSL, pas besoin de lancer l'autre fonction (particulièrement bien documentée, à ce propos )

mais bon vu qu'elle sert à que dalle vu ldaps://