Lorsque votre certificat est émis, vous recevez par mail l'url où vous pourrez le télécharger ainsi que la chaîne de certification.

Deux cas de figure :

• vous avez fait votre demande à l'aide d'openssl
• vous avez utilisé les outils Microsoft pour générer votre demande de certificat

Lorsque cette demande est faite et que le certificat vous est parvenu, vous vous retrouvez avec deux fichiers :

• le fichier contenant le certificat, XXXXXX.crt
• la clef privée que vous aurez générée au moment de votre demande. Elle est dans un fichier de la forme maclef.key

Vous devez alors :

1. générer un fichier au format PKCS#12 :

   openssl pkcs12 -export -in XXXXXXX.crt -inkey maclef.key -out monserveur.pfx

2. installer monserveur.pfx dans IIS en spécifiant comme mot de passe celui tapé précédemment.

Comme pour le cas openssl, vous avez reçu un fichier au format PEM.

Dans le gestionnaire de certificats de IIS, vous devez trouver une requête de certificat en attente. Sélectionnez l'option qui ne la supprime pas (Process the pending request en anglais) et importez le fichier que vous aviez reçu par mail.

Cliquez sur suivant. Puis sur terminer.

Aucun navigateur (ou systéme d'exploitation) n'intégre nativement dans le trousseau d'autorités de confiance les certificats intermédiaires, seuls les certificats racines sont présent. Le serveur doit donc présenter au client le moyen de faire le lien entre le certificat final et ces autorités de confiance, c'est le principe de la chaine de certification. Ces certificats intermédiaires doivent donc également être importés dans le magasin de certificat du serveur.

Les directives minimales à utiliser sont les suivantes, soit dans un contexte global, soit dans le contexte d'un hôte virtuel spécifique:

# certificat de l'hôte virtuel
SSLCertificateFile /etc/pki/tls/certs/certificat.crt
# clé privée du certificat
SSLCertificateKeyFile /etc/pki/tls/private/certificat.key
# chaine de certification
SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

Aucun navigateur (ou systéme d'exploitation) n'intégre nativement dans le trousseau d'autorités de confiance les certificats intermédiaires, seuls les certificats racines sont présent. Le serveur doit donc présenter au client le moyen de faire le lien entre le certificat final et ces autorités de confiance, c'est le principe de la chaine de certification. Attention, ces chaines différents en fonction du type de certificat, et elle sont détaillées ici

Internet Explorer 7 implémente précisément le RFC 2818 au sujet des wildcard certificates : sous Internet Explorer 7 un certificat *.univ-exemple.fr sera bien validé lors de l'accès à des sous-domaines de type webmail.univ-exemple.fr ou www.univ-exemple.fr mais se sera pas validé pour l'accès à des sous-domaines de profondeur supérieur, par exemple etudiants.webmail.univ-exemple.fr ou www.intranet.univ-exemple.fr. Au contraire les autres navigateurs (versions antérieures d'Internet Explorer 7, Firefox, etc.) reconnaissent un certificat *.univ-exemple.fr quelque soit le niveau de profondeur de sous-domaines des sites.

Vous pouvez résoudre ce problème par l'une des façons suivantes :

• En plus d'un wildcard certificat *.univ-exemple.fr, il est possible d'obtenir un wildcard certificat pour un niveau de profondeur supplémentaire, par exemple un certificat *.intranet.univ-exemple.fr.
• Vous pouvez demander un certificat sous-domaine.domaine.univ-exemple.fr pour chacun des sous-sous-domaines concernés.

Le même problème existe pour la JVM, au moins depuis des versions récentes.

Microsoft Exchange n'utilise pas les certificats uniquement pour le web, POP3 ou IMAP, il les utilise aussi pour sécuriser ses échanges avec les serveurs offrant des fonctionnalités complémentaires comme Activsync, Autodiscover, OWA par exemple.
En conséquence, le certificat utilisé doit être multi-domaine et contenir dans sa liste de « Subject Alternative Names » des noms de serveurs aussi bien externes qu'internes. Les certificats délivrés par TCS ne permettent pas d'inclure des noms de serveurs internes dans le champ SAN.
Comodo propose des certificats UCC adaptés à Exchange 2007 labellisés par Microsoft, mais ils ne font pas partie de l'offre TCS et coûtent plusieurs centaines d'euros selon le nombre de serveurs couverts.

Des stratégies de contournement existent cependant, dépendantes de l'infrastructure dans laquelle s'intègre Exchange. Elles consistent essentiellement à installer un ou des certificats TCS sur un ou des serveurs frontaux et à utiliser un certificat auto-signé pour les échanges internes entre serveurs voire entre serveurs et clients internes. La présence d'un certificat, même auto-signé, dans la configuration d'Active Directory est considérée comme une garantie suffisante pour accorder la confiance dans ce certificat.

Plus de détails sur le Microsoft Exchange Team Blog