—–BEGIN CERTIFICATE—–
[…]Plein de chiffres et de lettres[…]
—–END CERTIFICATE—–

—–BEGIN RSA PRIVATE KEY—–
[…]Plein de chiffres et de lettres[…]
—–END RSA PRIVATE KEY—–

Il s’agit du format PEM
sauf que votre IIS attend un .PFX ou un .CER …

Comment créer un certificat à partir de ce texte ?

Tout d’abord, il va falloir créer 2 fichiers textes, un contenant le certificat (de —–BEGIN CERTIFICATE—– à —–END CERTIFICATE—–) et un autre contenant la clé privée (de —–BEGIN RSA PRIVATE KEY—– à —–END RSA PRIVATE KEY—–).

Ensuite grâce à openssl – et notamment l’exécutable win32 -, on pourra utiliser la commande :

openssl pkcs12 -export -out moncertficat.p12 -in certificat.txt -inkey cle.txt

Il ne restera plus qu’à l’importer dans la console MMC pour l’utiliser.

Notez que j’ai déjà rencontré des erreurs, par exemple une impossibilité de trouver la clé privée (unable to load private key) ou clé invalide (private key doesn’t match with the certificate), vérifiez le format du fichier texte et recommencez la séparation en 2 fichiers si besoin avec un bon éditeur de texte.

Une des premières choses est qu’on voit beaucoup de choses sur le net et dans les livres avec du localhost partout. Jamais de conditions réelles…

Comment fait-on alors quand on a une ip publique ? ou un nom de domaine ?

1) De ma maigre expérience, ca devient tout de suite plus facile avec un nom de domaine… Dans ce cas, il ne faut pas oublier de le renseigner dans les bindings du site :

2) Et si on doit faire de l’https ?

Ajoutons un binding https me direz vous ?

Oui, mais ce n’est pas suffisant.

On ne peut pas renseigner le nom du domaine … Dans ce cas, il va falloir avoir recourt à une formule magique en ligne de commande :

   1: C:\Windows\System32\inetsrv>appcmd.exe set site /site.name:"MonSite" /+bindings.[protocol='https',bindingInformation='*:443:mon.domaine.com']

on devra ensuite ouvrir le fichier C:\Windows\System32\inetsrv\config\applicationHost.config et supprimer la ligne :

   1: <binding protocol="https" bindingInformation="*:443:" />

3) Si vous travaillez avec des certificats, n’oubliez pas d’accorder les droits adéquats à ceux-ci dans la console MMC : (manage private keys)

Il faut qu’ils correspondent au process défini dans la configuration avancée de l’application pool, disons NetworkService :

4) Si le wsdl génère le nom de la machine à la place du nom du domaine, normalement le binding avec nom de domaine défini au 1) suffit.

Si ca ne suffit pas, une solution est d’utiliser l’attribut factory du fichier svc et d’instancier un custom service host avec quelque chose du genre :

   1: <%@ ServiceHost Language="C#" Debug="true" Service="Service..." Factory="CustomHostFactory" %>

   1: public class CustomHostFactory : System.ServiceModel.Activation.ServiceHostFactory

   2: {

   3:     protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)

   4:     {

   5:         CustomHost customServiceHost = new CustomHost(serviceType, baseAddresses);

   6:         return customServiceHost;

   7:     }

   8: }

   1: public class CustomHost : ServiceHost

   2: {

   3:     public CustomHost(Type serviceType, params Uri[] baseAddresses)

   4:  

   5:         : base(serviceType, GetBaseAddresses())

   6:     { }

   7:  

   8:  

   9:     private static Uri[] GetBaseAddresses()

  10:     {

  11:         List<Uri> addresses = new List<Uri>();

  12:         AddBaseAddress(addresses);

  13:         return addresses.ToArray();

  14:     }

  15:  

  16:     private static void AddBaseAddress(List<Uri> addresses)

  17:     {

  18:  

  19:         string address = "http://mon.domaine.com/MonService.svc";

  20:         addresses.Add(new Uri(address));

  21:     }

  22: }

Par contre, tout ceci ne fonctionnera correctement qu’avec le port 80 … En effet, avec un autre port, le wsdl généré contiendra le numéro de port. S’il est ouvert depuis l’extérieur, tout va bien …

5) Sinon, on se retrouve dans une configuration classique de déploiement.

Un client accède à un nom de domaine : http://mon.domaine.com, une translation NAT est faite pour aller sur une machine interne http://MaMachine, et redirigée vers un port précis : http://MaMachine:12345.

Un Web service est hébergé sur cette machine.

Dans ce cas, le wsdl généré contient des adresses avec le numéro de port, qui est bloqué. Qu’à cela ne tienne, on va définir explicitement que l’adresse du endpoint (dans le web config ou dans la factory) est l’adresse sans le numéro de port. Et là, une magnifique erreur, du genre :

No protocol binding matches the given address ‘http://mon.domaine.com:12345/MonService.svc’. Protocol bindings are configured at the Site level in IIS or WAS configuration.

Pour résoudre ce bug, j’ai nommé le correctif : http://support.microsoft.com/kb/977420. Notez qu’il vous faudra installer le framework 3.5 SP1. (attention, différents correctifs existent en fonction des versions de son windows).

Et voilà pour ces quelques infos. En espérant que ca puisse vous aider.

Loin de moi l’idée de vous faire croire que je suis un expert IIS, au contraire. Je tiens à préciser que d’une manière générale, les informations sont plutôt difficile à trouver. Mais je tiens quand même à reconnaitre que les progrès entre IIS6 et IIS7 sont indéniables, rien que dans la gestion des utilisateurs …

Gageons que la prochaine version d’IIS sera encore plus complète.