Renouveler ou recréer un certificat wildcard pour Dynamics CRM 2016 On‑Premise (ADFS/Claims)

Votre certificat SSL wildcard a expiré sur un déploiement Dynamics CRM 2016 On‑Premise avec ADFS (authentification par revendications). Ce guide pas‑à‑pas montre comment régénérer le certificat, le déployer dans IIS, ADFS et CRM, et rétablir l’authentification en toute sécurité.

Sommaire

Vue d’ensemble

Un environnement Microsoft Dynamics CRM 2016 on‑premise configuré en claims‑based authentication (ADFS) ne peut plus authentifier les utilisateurs car le certificat SSL wildcard a expiré, et la façon dont il avait été généré n’a pas été documentée. L’objectif est de renouveler ou recréer le certificat avec le même nom de domaine générique (par ex. *.votre‑domaine.com), puis de le redéployer proprement dans IIS, ADFS (et éventuellement Web Application Proxy), et CRM, afin de maintenir la chaîne de confiance et rétablir l’authentification.

Plan rapide de la solution

Étape	Action	Détails clés
Identifier le type de certificat actuel	Déterminer s’il s’agit d’un certificat « self‑signed/privé » (AD CS interne) ou d’un certificat public émis par une AC tierce.	Un certificat public simplifie la confiance côté clients/ navigateurs ; un certificat interne peut suffire mais nécessite la diffusion de la chaîne de confiance.
Générer une nouvelle demande (CSR)	Dans IIS → Server Certificates → Create Certificate Request : CN = `.votre‑domaine.com`, algorithme SHA‑256, clé ≥ 2048 bits*.	Conserver le fichier `.txt` / `.csr` pour la soumission à l’AC. Inclure des SAN (`DNS=*.votre‑domaine.com`, `DNS=votre‑domaine.com`).
Obtenir le certificat signé	AC interne : soumettre la CSR à AD CS et récupérer le `.cer`/`.p7b`. AC publique : acheter/renouveler le wildcard, valider le domaine (DNS/e‑mail) et télécharger le bundle complet.	Préférer RSA‑SHA256 (compatibilité maximale) ; éviter ECDSA si des clients anciens doivent se connecter.
Installer le certificat	Dans IIS : Complete Certificate Request, magasin Personal de l’Ordinateur local.	Marquer la clé privée exportable si des sauvegardes/fermes sont utilisées. Donner un Friendly Name explicite.
Lier le certificat dans IIS	Pour chaque site HTTPS (CRM, sites externes) : Bindings → https → Edit → Select certificate. Cocher SNI si partage d’IP.	Renseigner le Host name pour chaque binding SNI : `crm.votre‑domaine.com`, `adfs.votre‑domaine.com`, etc.
Mettre à jour ADFS	ADFS Management → Service → Certificates : Set Service Communications Certificate. En PowerShell : `Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint ...` et `Set-AdfsSslCertificate -Thumbprint ...`.	Redémarrer le service `adfssrv`. Si les token‑signing/decrypting changent, régénérer et republier la federation metadata et mettre à jour les trusts dans CRM.
Actualiser la config CRM (si nécessaire)	Exécuter l’assistant Configure Claims‑Based Authentication dans Deployment Manager ou PowerShell : `Set-CrmSetting -SettingType ClaimsSettings -Settings @{CertificateThumbprint="THUMBPRINT"}`.	Si ADFS a basculé de CA interne à CA publique (ou inversement), vérifier la chaîne de confiance sur tous les serveurs CRM.
Redémarrer & tester	`iisreset`, redémarrer ADFS et le service Microsoft Dynamics CRM Asynchronous Processing. Tester : `https://adfs.votre‑domaine.com/federationmetadata/2007‑06/federationmetadata.xml` puis l’accès à CRM.	Les navigateurs ne doivent plus alerter sur le certificat ; l’authentification claims doit fonctionner de bout en bout.

Pré‑requis et bonnes pratiques

Accès administrateur aux serveurs CRM, ADFS, WAP (si présent) et IIS.
Nom de domaine et DNS prêts (crm.votre‑domaine.com, adfs.votre‑domaine.com, etc.).
Décider AC publique vs AC interne. Une AC publique évite l’installation manuelle de la chaîne sur les postes.
Algorithme : SHA‑256/RSA avec 2048 bits (ou 3072 bits si acceptable). Éviter ECDSA sur infrastructures hétérogènes.
TLS 1.2+ uniquement ; désactiver TLS 1.0/1.1 si possible (politique système et compatibilité client à valider).
Préparer un plan de retour arrière : export PFX de l’ancien certificat et captures de la config.

Cartographie des composants et chaîne de confiance

Pour réussir le remplacement, bien comprendre qui utilise quoi :

Client/ navigateur → CRM (IIS) : handshake TLS avec le certificat wildcard.
CRM → ADFS : redirection/échanges WS‑Fed/WS‑Trust protégés par TLS (certificat service communications) et signés par les certificats token‑signing/token‑decrypting d’ADFS.
ADFS Proxy (WAP) : si présent, il expose adfs.votre‑domaine.com vers Internet et doit aussi recevoir le nouveau certificat.

[Client] <--TLS (wildcard)--> [IIS/CRM]
                    |
                    +--TLS (wildcard)--> [ADFS / WAP]
                                |
                                +--Tokens signés par ADFS (token-signing/decrypting)

Étapes détaillées

Identifier le certificat actuel et collecter les paramètres

Ouvrez certlm.msc sur un serveur CRM/ADFS : Ordinateur local → Personnel → Certificats. Relevez Subject, Thumbprint, NotAfter, Friendly Name et la chaîne (AC intermédiaires).
En PowerShell, listez les certificats utiles : Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*votre-domaine.com*" } | Select-Object Subject,Thumbprint,NotAfter,EnhancedKeyUsageList
Vérifiez que les noms DNS réellement utilisés correspondent au wildcard : crm.votre‑domaine.com, adfs.votre‑domaine.com, auth.votre‑domaine.com…

Générer une CSR via IIS (méthode la plus simple)

Ouvrez IIS Manager → sélectionnez le serveur (racine) → Server Certificates → Create Certificate Request….
Renseignez :
- Common Name : *.votre‑domaine.com
- Organization/OU, City, State, Country
- Cryptographic service provider : Microsoft RSA SChannel
- Bit length : 2048 (ou 3072)
Important : la plupart des navigateurs ignorent désormais le CN au profit des SAN. Après émission, assurez‑vous que le certificat contient DNS=*.votre‑domaine.com et DNS=votre‑domaine.com.

Alternative avancée : CSR par `certreq` avec fichier INF

Utile pour AD CS ou pour automatiser :

; request.inf
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=*.votre-domaine.com"
KeyLength = 2048
HashAlgorithm = sha256
KeySpec = 1
Exportable = TRUE
KeyUsage = 0xa0
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[Extensions]
2.5.29.17 = "{text}"
*continue* = "dns=*.votre-domaine.com&"
*continue* = "dns=votre-domaine.com"

certreq -new request.inf request.csr
:: Soumission (AD CS) puis acceptation
certreq -submit request.csr certnew.cer
certreq -accept certnew.cer

Obtenir le certificat signé

AC interne (AD CS) : soumettez la CSR au gabarit « Web Server » (ou spécifique TLS) et récupérez .cer et .p7b (chaîne complète).
AC publique : renouvelez/achetez un wildcard. La validation se fait souvent par DNS (TXT) ou e‑mail d’approbation. Téléchargez le bundle (certificat + intermédiaires).

Conseil : restez en RSA‑SHA256 pour une compatibilité maximale avec ADFS/CRM 2016 et les clients Windows plus anciens.

Installer le certificat dans le magasin Windows

Dans IIS → Server Certificates : Complete Certificate Request… → sélectionnez le .cer/.p7b reçu, donnez un Friendly Name parlant (CRM Wildcard 2025), cible : Personal (ordinateur local).
Si vous disposez d’un .pfx (clé privée incluse), importez‑le : $pwd = ConvertTo-SecureString "MotDePassePfx" -AsPlainText -Force Import-PfxCertificate -FilePath "C:\Certs\crm-wildcard.pfx" ` -Password $pwd -CertStoreLocation Cert:\LocalMachine\My
Vérifiez la présence de la clé privée (icône clé) et que la chaîne remonte jusqu’à l’AC racine.

Créer/mettre à jour les liaisons HTTPS dans IIS

Pour chaque site (ex. Microsoft Dynamics CRM) : Bindings… → https → Edit → choisissez le nouveau certificat.
Si plusieurs noms partagent la même IP, activez Require Server Name Indication (SNI) et renseignez Host name : crm.votre‑domaine.com, auth.votre‑domaine.com, etc.
PowerShell (optionnel) : $thumb = "THUMBPRINT_SANS_ESPACES" New-Item "IIS:\SslBindings\0.0.0.0!443!crm.votre-domaine.com" -Thumbprint $thumb -SSLFlags 1

Mettre à jour ADFS (Service Communications et SSL)

Dans ADFS, deux éléments sont à distinguer :

Service Communications certificate : présenté par le service ADFS lui‑même (IIS/http.sys), visible dans la console ADFS.
SSL certificate (http.sys) du nom de service de fédération (adfs.votre‑domaine.com) : géré par ADFS via PowerShell et utilisé aussi par les proxys WAP.

Via la console : ADFS Management → Service → Certificates → Set Service Communications Certificate….

Via PowerShell (recommandé et traçable) :

# Sur les serveurs ADFS
$thumb = "THUMBPRINT_SANS_ESPACES"
Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $thumb
Set-AdfsSslCertificate -Thumbprint $thumb

# Vérifier

Get-AdfsCertificate -CertificateType Service-Communications
Get-AdfsSslCertificate

# Redémarrer le service

Restart-Service adfssrv

Si Web Application Proxy (WAP) est en place (DMZ) : exécuter également sur chaque proxy :

Set-WebApplicationProxySslCertificate -Thumbprint $thumb

Attention : ne touchez pas aux certificats Token‑Signing et Token‑Decrypting sauf si vous savez ce que vous faites. Leur renouvellement implique une mise à jour de la fédération côté CRM.

Actualiser la configuration Claims dans CRM 2016

Si vous avez simplement remplacé le certificat TLS (wildcard) sans modifier ADFS ni les URL, CRM continuera souvent à fonctionner sans action supplémentaire. Toutefois, si la configuration antérieure référençait explicitement une empreinte ou si vous avez modifié la chaîne/AC, procédez comme suit :

Ouvrez Deployment Manager → Microsoft Dynamics CRM → Configure Claims‑Based Authentication et suivez l’assistant pour valider la nouvelle métadonnée ADFS.
Option PowerShell (Deployment Shell) : Add-PSSnapin Microsoft.Crm.PowerShell $thumb = "THUMBPRINT_SANS_ESPACES" Set-CrmSetting -SettingType ClaimsSettings -Settings @{ CertificateThumbprint = $thumb }
Si les certificats token‑signing/decrypting ont été renouvelés, mettez à jour la Federation Metadata dans CRM (assistant) pour régénérer les trusts.

Redémarrer les services et réaliser les tests de bout en bout

Redémarrez IIS : iisreset.
Redémarrez ADFS : Restart-Service adfssrv (et WAP si utilisé).
Redémarrez le service Microsoft Dynamics CRM Asynchronous Processing sur les serveurs d’applications.
Tests :
- Vérifier la chaîne : certutil -verify "chemin\crm-wildcard.cer".
- Tester l’endpoint ADFS : https://adfs.votre‑domaine.com/federationmetadata/2007‑06/federationmetadata.xml (en texte brut, sans avertissement de certificat).
- Tester la page CRM en HTTPS et le parcours d’authentification (redirection ADFS, saisie, retour CRM).
- Tester via PowerShell : Test-NetConnection adfs.votre-domaine.com -Port 443.

Choisir entre AC publique et AC interne (comparatif)

Critère	AC publique	AC interne (AD CS)
Confiance côté clients	Native (navigateurs/terminaux)	Nécessite déploiement des AC racine/intermédiaires
Coût	Payant (sauf Let’s Encrypt)	Gratuit en interne (coût d’exploitation)
Wildcard	Simple (validation DNS/E‑mail)	Simple (gabarit serveur Web)
Renouvellement	Automatisable (ACME, outils)	Automatisable (scripts/AD CS)
Exposition Internet	Idéale (aucune chaîne à pousser)	À éviter si clients externes non gérés

Automatiser les renouvellements (ACME / Let’s Encrypt)

Pour les futurs renouvellements, envisagez l’automatisation via le protocole ACME. Remarques clés :

Les wildcards exigent la validation DNS‑01 (ajout d’un enregistrement TXT), pas de HTTP‑01.
Des outils Windows populaires : Certify The Web, win‑acme. Ils peuvent exécuter des scripts post‑renouvellement : import PFX, Set-AdfsSslCertificate, mise à jour IIS, redémarrages contrôlés.
Cycle court (≈ 90 jours) : prévoyez un plan de bascule sans interruption et des alertes proactives.

Pièges fréquents et comment les éviter

Clé privée manquante : le certificat importé n’a pas l’icône de clé. Solution : toujours terminer la requête avec le même serveur ayant généré la CSR, ou importez un .pfx incluant la clé.
Chaîne incomplète : Intermediate CA non installée. Importez les intermédiaires dans Intermediate Certification Authorities de l’ordinateur local.
Nom d’hôte absent des SAN : ajoutez DNS=*.votre‑domaine.com et DNS=votre‑domaine.com dans la demande.
Bindings IIS erronés : oubli du Host name avec SNI, ports en conflit, mauvais certificat sélectionné.
ADFS non mis à jour : seul IIS a été modifié. Exécutez Set-AdfsCertificate et Set-AdfsSslCertificate puis redémarrez adfssrv.
Clients anciens : si TLS 1.0 est désactivé, assurez‑vous que toutes les applications consommatrices supportent TLS 1.2.

Dépannage : erreurs courantes et correctifs

Symptôme / Message	Cause probable	Résolution
Avertissement navigateur « certificat non valide »	Nom d’hôte non présent dans le certificat, chaîne incomplète, date invalide	Recréez la CSR avec SAN adéquats ; installez les intermédiaires ; vérifiez l’horloge serveur
Erreur ADFS `MSIS7065` ou `503`	Certificat ADFS non lié, service non redémarré	Reliez via `Set-AdfsSslCertificate`, puis `Restart-Service adfssrv`
CRM : boucle d’authentification ou HTTP 401/403	Métadonnées de fédération obsolètes, horloge désynchronisée	Rafraîchissez la config claims dans Deployment Manager ; synchronisez NTP
WAP publie toujours l’ancien certificat	WAP non mis à jour	Exécutez `Set-WebApplicationProxySslCertificate` sur chaque proxy
Impossible d’exporter la clé	CSR générée sans clé exportable	Générez une nouvelle CSR avec `Exportable = TRUE` (ou cochez l’option dans IIS)

Scripts PowerShell utiles (exemples)

Inventorier les certificats et trouver le bon wildcard

$certs = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Subject -match "\*\.[\w\-]+\.[\w\.]+" } |
  Select-Object Subject, Thumbprint, NotBefore, NotAfter, FriendlyName
$certs | Format-Table -Auto

Lier automatiquement un certificat à un site IIS (SNI)

param(
  [string]$SiteName = "Microsoft Dynamics CRM",
  [string]$HostName = "crm.votre-domaine.com",
  [string]$Thumbprint
)

if (-not $Thumbprint) { throw "Renseignez -Thumbprint" }

# Crée/maj la liaison 443 SNI

Remove-Item "IIS:\SslBindings\0.0.0.0!443!$HostName" -ErrorAction SilentlyContinue
New-Item "IIS:\SslBindings\0.0.0.0!443!$HostName" -Thumbprint $Thumbprint -SSLFlags 1

# Vérifier

Get-WebBinding -Name $SiteName -Protocol https

Basculer ADFS sur le nouveau certificat

$thumb = "THUMBPRINT_SANS_ESPACES"
Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $thumb
Set-AdfsSslCertificate -Thumbprint $thumb
Restart-Service adfssrv

Mettre à jour CRM (ClaimsSettings)

Add-PSSnapin Microsoft.Crm.PowerShell
$thumb = "THUMBPRINT_SANS_ESPACES"
Set-CrmSetting -SettingType ClaimsSettings -Settings @{ CertificateThumbprint = $thumb }

Checklist par rôle

Rôle	Tâches clés	Validation
Administrateur DNS	Valider les enregistrements publics/privés (ADFS, CRM, WAP)	Résolution correcte interne/externe
Admin Certificats	Émettre le wildcard, fournir `.cer`/`.pfx` + chaîne	Certificat RSA‑SHA256, SAN corrects, clé exportable
Admin IIS	Importer, lier sur tous les sites concernés, SNI	Bindings OK, pas d’avertissement navigateur
Admin ADFS/WAP	Basculer Service‑Comms + SSL, redémarrer	Métadonnées accessibles, Event Log sain
Admin CRM	Vérifier/rafraîchir la config Claims/IFD	Connexion utilisateur fonctionnelle

Plan de retour arrière

Exporter l’ancien certificat en .pfx (avec mot de passe) depuis LocalMachine\My.
Noter les bindings IIS existants (captures d’écran).
En cas d’échec : réimporter le .pfx, rétablir les bindings précédents, exécuter Set-AdfsSslCertificate avec l’ancienne empreinte.

Considérations de sécurité

Interdire TLS 1.0/1.1 si la compatibilité le permet ; forcer TLS 1.2+.
Utiliser des droits minimaux pour manipuler les certificats et supprimer les exports .pfx après usage (stockage sûr).
Surveiller l’expiration : alertes 60/30/15/7 jours, Health checks automatisés.

FAQ

Changer le certificat ADFS casse‑t‑il les trusts ?
Non, si vous ne touchez qu’au Service Communications/SSL. En revanche, si les certificats token‑signing/decrypting sont renouvelés, mettez à jour la fédération dans CRM.

Dois‑je regénérer l’IFD ?
Non si les FQDN ne changent pas. Rafraîchissez la configuration claims uniquement si nécessaire.

Wildcard ou certificats dédiés ?
Le wildcard simplifie la gestion multi‑sous‑domaines. Des certs dédiés par service renforcent l’isolement. Choisissez selon vos contraintes de sécurité/ops.

Puis‑je utiliser ECDSA ?
Techniquement oui, mais préférez RSA pour la compatibilité avec CRM 2016 et des clients anciens.

Checklist finale de documentation (run‑book)

Élément	À consigner
Emplacement du `.pfx`	Chemin sécurisé, mot de passe, contrôle d’accès
Détails du certificat	Subject, SAN, Thumbprint, NotAfter, AC
Commandes PowerShell	Historique exact des commandes exécutées
Serveurs impactés	Liste des nœuds CRM, ADFS, WAP, SSRS
Calendrier de renouvellement	Dates d’échéance, rappels, responsable

Conclusion

En suivant cette procédure, vous recréez ou renouvelez en toute sécurité un certificat wildcard pour un environnement Dynamics CRM 2016 On‑Premise utilisant ADFS/claims, tout en préservant la chaîne de confiance. Le point crucial est la cohérence : même nom de domaine, chaîne complète, liaisons IIS correctes, ADFS basculé proprement, et—si nécessaire—rafraîchissement de la configuration claims côté CRM. Profitez de l’occasion pour automatiser les renouvellements futurs et renforçez vos contrôles TLS.

Renouveler ou recréer un certificat wildcard pour Dynamics CRM 2016 On‑Premise (ADFS/Claims)