Windows Server 2019 : arrêter l’inflation des conteneurs RSA et nettoyer des millions de fichiers MachineKeys en toute sécurité

Un serveur Windows Server 2019 peut soudain se transformer en véritable « machine à recycler » : le dossier C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Crypto\RSA se remplit à grande vitesse de minuscules fichiers (< 4 Ko) impossibles à éradiquer même pour l’administrateur. Ce guide déroule, de façon pas‑à‑pas et sans risques pour la production, les méthodes d’analyse et de remédiation les plus efficaces pour stopper l’hémorragie et nettoyer proprement les conteneurs de clés RSA orphelins.

Sommaire

Comprendre l’origine de cette avalanche de conteneurs RSA

Windows crée automatiquement un conteneur RSA pour chaque clé générée par CryptoAPI ou CNG : connexions TLS, signatures de code, authentifications SmartCard, chiffrages de disque, etc. Dans un fonctionnement normal, ces fichiers sont éphémères ; une tâche planifiée baptisée KeyManagement purge les clés qui n’ont plus de certificat associé depuis 90 jours. Lorsque cette purge n’agit plus ou qu’un service défectueux régénère continuellement des clés, le dossier explose littéralement :

Symptôme	Explication
Millions de fichiers *.{GUID}	Conteneurs RSA créés par CryptoAPI/CNG pour stocker les paires de clés privées/publiques
Croissance rapide (plusieurs Go/mois)	Un service boucle sur la génération de nouvelles clés sans nettoyage
Suppression impossible	L’ACL de chaque fichier n’accorde aucun droit à `Administrators`; seul le compte système propriétaire peut y toucher

Risques d’une suppression aveugle

Effacer un conteneur encore référencé par un service actif casse immédiatement l’authentification TLS ou la lecture de données chiffrées : un site IIS ne démarre plus, une application métier refuse la connexion, un VPN IPsec tombe, etc. Toute opération doit donc commencer par l’identification du véritable coupable pour éviter la récidive et limiter l’impact.

Trouver le service qui sème la pagaille

Activer le journal CAPI2

Ouvrez l’Observateur d’événements (eventvwr.msc).
Dans Applications and Services Logs > Microsoft > Windows > CAPI2, faites un clic droit sur Operational > Enable Log.
Laissez tourner quelques minutes, puis filtrez sur l’ID 532 (génération de clé) ou 544 (création de conteneur).

La colonne « Process Name » révèle quel exécutable écrit en rafale. Les plus fréquemment responsables sont :

un service .NET custom mal développé ;
un rôle IIS utilisant RSACryptoServiceProvider sans persistance de clé partagée ;
un agent EDR/antivirus exigeant des clés temporaires à chaque analyse.

Isoler et corriger

Désactivez temporairement le service suspect (ou basculez son pool IIS en mode hors connexion) ; surveillez la taille du dossier pendant 15 minutes : si elle n’augmente plus, vous tenez votre générateur infini. Il faudra alors :

Appliquer les derniers correctifs de l’éditeur du service.
Modifier la configuration (par exemple reuseKeys=true dans un web.config .NET).
Ou programmer un recyclage régulier contrôlé.

Réactiver la purge interne de Windows

Contrôler la tâche planifiée KeyManagement

Lancez Taskschd.msc et ouvrez : Microsoft > Windows > CryptographicServices > KeyManagement.
Vérifiez que la tâche est activée et planifiée tous les 7 jours.
Cliquez Exécuter pour la lancer manuellement.
Sur un dossier pollué, la première exécution peut durer plusieurs heures.
Si la tâche échoue avec 0x80070005 (Access Denied), redémarrez le service CryptSvc et relancez.

KeyManagement supprime par conception toutes les clés sans certificat associé âgées d’au moins 90 jours. Inutile de réduire ce seuil : l’algorithme interne vérifie aussi l’empreinte de la clé dans le magasin personnel. S’il échoue, passez aux techniques manuelles ci‑dessous.

Inventorier puis cibler les seuls conteneurs orphelins

Utiliser `certutil`

La commande suivante liste chaque conteneur présent, l’état de la clé et l’empreinte du certificat correspondant :

certutil -key

Les lignes « No associated certificates » signalent les clés détachées. Pour en supprimer une :

certutil -delkey "{GUID}"

Répliquez la commande pour chaque GUID orphelin. C’est fastidieux, mais 100 % sûr.

Script d’automatisation PowerShell

$cutoff = (Get-Date).AddDays(-90)
Get-ChildItem -Path "$env:ProgramData\Microsoft\Crypto\RSA" -Recurse -File |
  Where-Object { $_.LastWriteTime -lt $cutoff } |
  ForEach-Object {
      $guid = $_.Name
      if (-not (certutil -key | Select-String $guid)) {
          certutil -delkey $guid
      }
  }

Ce script recoupe la date, l’existence d’un certificat et supprime ensuite uniquement les conteneurs « fantômes ».

Procéder à un nettoyage massif après sauvegarde

Si le répertoire contient plusieurs millions de fichiers, la méthode certutil peut prendre des jours. Dans ce cas, adoptez une stratégie bulk en trois étapes : prise de possession, délégation des droits, suppression par date.

takeown /F "C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Crypto\RSA" /R
icacls "C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Crypto\RSA" /grant Administrators:F /T
forfiles /P "C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Crypto\RSA" /D -90 /C "cmd /c del @path"

Important : exécutez ces commandes depuis un Maintenance Window avec un snapshot de la VM ou une sauvegarde système complète. Au moindre doute, conservez les fichiers dans un répertoire hors production avant la suppression définitive.

Empêcher le retour du problème

Action préventive	Détails et bénéfices
Appliquer les correctifs Windows & .NET	Les mises à jour cumulatives corrigent régulièrement des fuites de clés temporaires dans Schannel, Winhttp et CLR.
Contrôler la stratégie « Force la protection forte des clés privées »	Un paramètre trop restrictif empêche parfois la réutilisation de clés existantes : GPMC > Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Options de sécurité.
Surveiller l’événement 1014 (CrypKsp) dans le journal Système	Il signale un échec de nettoyage automatique.
Planifier un script mensuel `Remove-Item`	Automatiser la purge des conteneurs vieillis après vérification d’empreinte.

Cas des autres comptes de service

Le phénomène touche parfois NetworkService, un pool IIS spécifique ou le SID d’un service tiers. Reprenez alors les mêmes étapes sur le répertoire :

%PROGRAMDATA%\Microsoft\Crypto\RSA\S-1-5-20        (NetworkService)
%PROGRAMDATA%\Microsoft\Crypto\RSA\MachineKeys     (services locaux)
%SYSTEMDRIVE%\inetpub\temp\appPools\{AppPoolSID}   (IIS)

Guide de décision rapide

Scénario	Action immédiate	Approche long terme
Dossier gonfle de > 100 000 fichiers/jour	Désactiver le service identifié, sauvegarder, lancer KeyManagement	Mise à jour appli + paramétrage `reuseKeys`
Taille disque critique (partition système)	Nettoyage massif par date & snapshot	Programmation tâche PowerShell mensuelle
Serveur frontal IIS en prod 24/7	Purge ciblée avec `certutil` entre deux créneaux de redémarrage	Basculer le site vers certificats à clé partagée
Cluster RDS / Broker	Synchroniser d’abord les certificats, puis supprimer les conteneurs orphelins	GPO homogène sur la protection de clé

FAQ : questions fréquemment posées

Pourquoi la tâche KeyManagement ne se déclenche plus ?

La cause la plus courante est un état « disabled » provoqué par un outil de durcissement ou une GPO héritée. Sur certaines builds, l’échec initial (code 0x8009001d) gèle la tâche jusqu’à redémarrage du service Schedule.

Puis‑je simplement formater le dossier MachineKeys puis redémarrer ?

Non. Certains services système – NLA, WinRM, RDP, DFSR – s’appuient sur des clés stockées ici. Leur suppression sans recréation contrôlée bloque la mise en réseau, l’authentification Kerberos ou la réplication de fichiers.

Un antivirus peut‑il bloquer la suppression ?

Oui : la surveillance temps réel verrouille souvent les fichiers dès que la boucle CreateFile > Scan > Close s’enclenche. Désactivez‑la temporairement ou excluez le chemin pour accélérer le nettoyage.

Existe‑t‑il un correctif officiel Microsoft ?

Aucun patch unique magique : Microsoft corrige ponctuellement des fuites spécifiques (Schannel, .NET 6, Exchange CU), mais chaque scénario dépend du service générateur. Tenez votre CU Windows à jour et lisez attentivement les KB relatives au rôle concerné.

Conclusion

Le gonflement incontrôlé du dossier RSA n’est pas une fatalité ; il révèle un défaut de maintenance ou un développement applicatif perfectible. En combinant journalisation fine (CAPI2), relance de la tâche KeyManagement, scripts certutil ciblés et, en dernier recours, un nettoyage massif sécurisé, vous reprenez le contrôle sans interrompre vos services critiques. Une fois la tempête passée, pérennisez la solution : correctifs, GPO adéquates, surveillance pro‑active et purge planifiée. Vous éviterez ainsi que millions de conteneurs orphelins ne saturent de nouveau votre serveur Windows Server 2019.