Vous en avez assez de l’avertissement « Select a certificate for authentication » qui surgit à chaque ouverture de session ? Découvrez comment forcer Windows 11 et les applications à choisir automatiquement le bon certificat pour une authentification fluide.
Pourquoi cette boîte de dialogue apparaît‑elle ?
Lorsque plusieurs certificats clients remplissent les critères d’un serveur TLS (même usage Client Authentication, même autorité de certification, même période de validité), Windows n’est pas en mesure de deviner lequel présenter. Il affiche donc la fenêtre de sélection afin d’éviter qu’un mauvais certificat ne provoque un rejet d’authentification. Sur un poste de travail géré et doté de processus de PKI maîtrisés, cette étape devient vite inutile — pire : elle ralentit l’expérience utilisateur et multiplie le risque d’erreur.
Stratégie globale
Pour éliminer définitivement l’invite, il faut agir sur tous les maillons de la chaîne d’authentification :
- Réduire le nombre de certificats présentables.
- Configurer les applications pour un choix explicite.
- Déployer des stratégies d’auto‑sélection cohérentes (GPO ou JSON policy).
- Automatiser l’approvisionnement PKI pour empêcher le retour de certificats parasites.
Étapes essentielles
Étapes | Détails pratiques |
---|---|
Vérifier la présence du bon certificat | Ouvrez certlm.msc (certificats ordinateur) ou certmgr.msc (utilisateur) → Personnel. Confirmez l’existence d’un certificat Client Authentication valide, émis par la bonne autorité, avec clé privée exportable si l’application l’exige. |
Configurer l’application ou le service | Si le logiciel le permet (VPN, client SMTP, navigateur, Wi‑Fi 802.1X, etc.), sélectionnez manuellement le certificat ou saisissez son empreinte SHA‑1/SHA‑256. |
Supprimer les certificats périmés ou en double | Dans le magasin Personnel, identifiez les doublons : dates d’expiration similaires, même CN. Exportez-les (Toutes les tâches → Exporter) puis supprimez (Supprimer). Cela réduit immédiatement la liste des candidats. |
Automatisation dans les navigateurs Chromium
Edge et Chrome acceptent la stratégie AutoSelectCertificateForUrls
distribuée par GPO ou JSON MDM. Exemple :
{
"AutoSelectCertificateForUrls": [
{
"pattern": "https://intranet.contoso.com",
"filter": {
"ISSUER": {"CN": "Contoso Issuing CA"},
"SUBJECT": {"O": "Contoso", "OU": "IT"},
"EKU": "CLIENT_AUTH"
}
}
]
}
Dès la prochaine ouverture du site intranet, le certificat correspondant à ce filtre sera envoyé sans intervention.
Cas particulier : IE mode et applications héritées
Pour les contrôles ActiveX ou anciens portails dépendant d’Internet Explorer, activez la GPO :
User Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Advanced Page → Do not prompt for client certificate selection when only one certificate exists
Veillez toutefois à n’avoir réellement qu’un seul certificat éligible dans le magasin “Personnel”.
Nettoyage automatique du magasin de certificats
Dans un environnement d’entreprise, la cohabitation de certificats provisoires, expirés ou issus de tests est la cause principale de la fenêtre de sélection. Ajoutez au script de connexion PowerShell un bloc de purge :
Get-ChildItem Cert:\CurrentUser\My |
Where-Object {
($_.NotAfter -lt (Get-Date)) -or
($_.Extensions |
Where-Object {$_.Oid.FriendlyName -eq 'Extended Key Usage'} |
Select-String -NotMatch 'Client Authentication')
} |
Remove-Item
L’administrateur garde un contrôle total : seule la partie “Client Authentication” valide est conservée.
Auto‑enrôlement PKI et modèles de certificats
Pour empêcher la prolifération de certificats “fantômes”, activez l’auto‑inscription (Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto‑Enrollment). Paramétrez ensuite le modèle de certificat client de manière stricte :
- Durée de vie courte (1 an) pour accélérer le renouvellement.
- Extension EKU limitée à
Client Authentication (1.3.6.1.5.5.7.3.2)
. - Subject Name construit à partir du sAMAccountName afin d’éviter les collisions.
Contrôle avancé de la pile TLS
SchUseStrongCrypto (HKLM\Software\Microsoft\.NETFramework\v4.0.30319
) ou les politiques TLS 1.2/1.3 peuvent parfois empêcher Windows de considérer un certificat pourtant valide. Vérifiez :
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols /v Enabled
Assurez‑vous que les suites de chiffrement offertes par le serveur acceptent toujours la clé publique du certificat client (elliptique ou RSA) que vous conservez.
Diagnostic pas‑à‑pas
1. Lister les certificats disponibles
certutil -store My
Identifiez le Serial Number et l’empreinte (Thumbprint) du certificat que vous souhaitez conserver.
2. Observer un échec d’authentification
Ouvrez l’observateur d’événements : Applications and Services Logs → Microsoft → Windows → CAPI‑2 → Operational. Les IDs 11
(début de la sélection) et 42
(échec) sont révélateurs.
3. Capturer le handshake
Avec pktmon
ou Wireshark, filtrez TLS
et recherchez la trame Certificate Request envoyée par le serveur ; vous verrez quelles autorités et quels EKU sont requis.
Scénarios hors navigateur
VPN (IKEv2 ou OpenVPN)
Les clients modernes laissent saisir l’empreinte SHA‑256 du certificat dans le profil. Exemple IKEv2 PowerShell :
Add-VpnConnection -Name "Corp VPN" -ServerAddress vpn.contoso.com `
-AuthenticationMethod Eap -EapConfigXmlStream (Get-Content .\EapConfig.xml) `
-TunnelType Ikev2 -EncryptionLevel Required -RememberCredential
Dans EapConfig.xml
, renseignez la balise CertificateHash
avec l’empreinte souhaitée.
Wi‑Fi entreprise (802.1X, EAP‑TLS)
Le profil XML de Wi‑Fi (netsh wlan export profile
) contient la section <clientCertificate hash="…" storeLocation="CurrentUser" />
. Ainsi le système n’affichera jamais de boîte de dialogue, même si d’autres certificats résident encore dans le magasin.
Authentification par carte à puce
Dans les environnements CAC/PIV ou badges d’entreprise, la présence simultanée de plusieurs cartes (lecteur virtuel compris) peut déclencher l’invite. Utilisez la stratégie PinCaching ou marquez les certificats secondaires comme “non présentables” via la propriété Smart Card Logon disabled.
Checklist “zéro‑invite”
- Un seul certificat client valide dans le magasin.
- JSON policy ou GPO d’auto‑sélection activée pour chaque application.
- Auto‑inscription PKI verrouillée et scripts de purge déployés.
- Protocoles TLS et suites de chiffrement compatibles avec le certificat.
- Surveillance régulière des journaux CAPI‑2 pour détecter de nouveaux doublons.
Questions fréquentes (FAQ)
Comment savoir si un certificat est réellement utilisé ?
Lancez la commande :
Get-WinEvent -LogName "Microsoft-Windows-CAPI2/Operational" |
Where-Object { $_.Id -eq 70 } |
Select-Object -First 10 -Property TimeCreated,Properties
L’Id 70 consigne le certificat effectivement présenté lors du handshake.
Peut‑on déléguer la suppression à Intune plutôt qu’à un script ?
Oui. Créez un profil “Trusted certificate” vide assorti d’une Compliance Policy : non‑conformité si plus d’un certificat “Client Authentication” présent. Un Remediation script Intune se charge alors du nettoyage sans exiger de droits locaux élevés.
Quels risques si deux certificats identiques subsistent ?
Outre la fenêtre d’invite, le serveur peut mal interpréter la chaîne de certificats et rejeter la connexion (erreur TLS 13 ou 400 Bad Request). La suppression proactive évite ces incohérences.
Conclusion
Supprimer l’invite « Select a certificate for authentication » n’est pas qu’une astuce de confort : c’est aussi une bonne pratique de sécurité et d’hygiène PKI. En rationalisant le magasin de certificats, en appliquant des politiques d’auto‑sélection précises et en automatisant l’enrôlement, vous éliminez les zones d’ombre susceptibles de compromettre vos connexions chiffrées. Investissez quelques heures dans la mise en place initiale ; vous gagnerez des centaines de clics et supprimerez une source de friction embarrassante pour vos utilisateurs.