bonjour,
J'ai créé sur mon serveur de domain une autorité de certificat. (windows 2003)
Je l'ai installé sur mes client Windows grâce a une GPO, ça fonctionne.
 
J'ai un serveur linux red hat qui me reclame un renouvellement de certificat
" ################# SSL Certificate Warning ################"
j'ai suivi cette doc.
http://www.centos.org/docs/5/html/ [...] ngkey.html
Je n'arrive pas a définir la durée de validité du certificat avec genkey...
mais cette methode ne me va pas.
Comment faire pour generer un certificat pour mon serveur linux, non pas avec genkey mais plutot avec mon serveur windows 2003 ?
Le certificat pour ce linux sera utilisé par apache.

va sur l'interface web pour générer un certificat puis exporte le.
 
La bonne méthode sinon c'est que sur ton linux tu génères la keypair et la requête puis que tu en génères un certificat signé par ton autorité.
 
Sinon c'est pas très malin d'installer une CA sur un DC

 
HS, mais juste pour ma culture, pourquoi ?

Parce que le jour où tu voudras migrer ton DC, il te faudra désinstaller ta CA pour commencer.

Parce que ca te force a garder le même nom de machine lors des upgrades, parce que niveau sécu c'est pas Gégé. Ca apporte beaucoup de Pb pour aucun avantage su ce n'est gagner une machine mais a l'heure de la virtu c'est pas une raison

ok je ne savais pas...
On va bientot migré de serveur de domaine, donc ça va pas etre le top.
Pour l'instant mon ca est utilisé pour diffusé des certif ia GPO a mes pc client pour l'auth sur mes antennes wifi. Si je change de CA de place, je pourrais assez facilement republier via GPO le nouveau.
sinon sous linux j'ai fait ceci pour le generer le certificat auto signé.
genkey monserveur --days 4000
11ans de validité... ça ira.
Sinon j'ai trouvé sur mon CA windows http://127.0.0.1/certsrv/
Apres je ne vois pas quel option prendre et comment le mettre sous linux
"Sélectionnez une tâche :  
 Demander un certificat  
 
Afficher le statut d'une requête de certificat en attente  
 
Télécharger un certificat d'autorité de certification, une chaîne de certificats ou une liste de révocation de certificats  
 
"

Je pense qu'il vaut mieux redéfinir le rôle de chaque élément, ensuite la solution coulera de source
 
Tu disposes donc d'une autorité de certification (CA) sur ton AD windows. Pour être utilisable cette CA est composée de 2 éléments:
- la clef "privée" qui ne doit pas quitter l'AD et qui a pour vocation à signer d'autres certificats. L'action de "signer" d'autres certificats avec cette CA a pour objectif de les étiqueter comme étant de confiance. Comme un sceau/signature sur un document notarié, etc...
- la clef "publique" ou certificat qui doit être installée sur les postes/applications et qui permet de leur dire de faire confiance à cette autorité de certification et à tous les certificats signés par celle-ci. C'est ce certificat/clef publique qui une fois signé porte les propriétés d'utilisation : type d'usage, durée d'expiration, CommonName (CN), etc...
 
Ensuite il y a différents "formats" pour stocker et/ou diffuser ces deux éléments et il est facile de les convertir pour passer de l'un à l'autre. Parmi eux il y a: pkcs#7 (format d'exportation par défaut de windows de mémoire), pkcs#12, keystore (java), x509 (utilisé dans la plupart des implémentations sous linux), etc...
 
 
Ceci étant dit, ce que tu cherches à faire c'est signer un certificat pour ton application qui tourne sous linux.
Tu as deux façons de t'y prendre:
1)
- Tu génères ta clef privée sur ton serveur linux. Pour rappel la clef privée ne contient aucune information (date de validité, etc...) et constitue ton "secret". Il vaut mieux éviter de le faire sortir de son lieu d'utilisation pour garantir sa confidentialité.
- A partir de cette clef privée tu dois générer un CSR (Certificate Signing Request): une demande de signature à utiliser pour que ta CA puisse plus tard te générer un certificat. C'est au moment de générer le CSR que tu peux lui préciser les propriétés souhaitées pour ton futur certificat: Durée de validité, commonName, etc... Mais rien n'empêche de modifier ces propriétés à nouveau lors de la signature du certificat par la CA (si les outils windows le permettent). Tu peux donc le faire aux deux endroits.
- Tu récupères le CSR, tu le transmets à ta CA et tu récupères le certificat signé fourni en retour. (nb: le certificat retourné ne sera peut-être pas dans le format souhaité et devra probablement être converti)
- Tu as désormais ta clef privée et ton certificat qui peuvent être utilisés sur ta machine linux.
 
2)
- Tu demandes à ta CA sur ton AD de te générer un couple clef privée / clef publique
- Tu les exportes au format x509 pem (si windows le permet). S'il te propose de les exporter qu'au format pkcs#7 alors il faudra ensuite les convertir au format x509 pour qu'ils soient utilisables sur ta machine linux.
 
 
Je préfère la solution 1) car du coup le "secret" (clef privée) ne sort jamais de ta machine linux.
J'ai volontairement pas détaillé les commandes précises pour chaque étape car ça va dépendre de ce que tu souhaites faire et les tutos se trouvent facilement sur internet.
Sinon je ne vois pas ce qui empêche d'extraire la CA de ton AD et de la réimporter après migration ou même de la transformer pour ensuite gérer ta CA depuis une machine linux. Mais par contre je ne nies pas que ça puisse être compliqué, je connais mal le fonctionnement de la PKI sous windows.

En effet tu connais pas le fonctionnement d'une pki ms parce que la clé privée n'est pas stockée dans AD et la migration a un certain nombre de prérequis dont la du nom de machine et divers élément sur les ksp

Ué j'ai dû sous-estimer la capacité de Microsoft à se compliquer la vie et celle de ses utilisateurs    
 
Comme tu le dis je connais pas l'implémentation de la PKI faite par MS mais ils doivent être sacrément tordus pour se rajouter de telles contraintes en tout cas si c'est tel que tu le décris.

Remarque, je viens de checker, ça a changé. Maintenant on peut changer le nom de la machine par contre le nom de la CA doit rester le même.
Après ça dépend comment ça a été configuré mais si les URL des AIA/CRL ont été mis à l'arrache en mettant le nom de la machine alors t'es baisé faut garder aussi le nom de machine ou faire des alias crados sur l'ancien nom.
Guide de migration d'une CA MS http://technet.microsoft.com/en-us [...] 10%29.aspx

merci pour ces éclaircissement.