MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Certificat SSL auto‑signé sans avertissement ? La méthode qui marche (Windows Server 2022, IIS, SQL Server, ACME)

Certificat SSL auto‑signé sans avertissement ? La méthode qui marche (Windows Server 2022, IIS, SQL Server, ACME)

Windows Server

Vous cherchez à activer TLS sur un Windows Server 2022 en workgroup pour des démos, sans aucune alerte navigateur ? Voici la réponse claire et la méthode qui marche partout (IIS, API REST, SQL Server), avec scripts et check‑list terrain.

Sommaire

Peut‑on créer un certificat TLS/SSL auto‑signé qui n’affiche aucun avertissement navigateur ?

Vue d’ensemble de la question

Contexte typique : un Windows Server 2022 isolé (workgroup, non joint à un domaine) héberge vos briques de démo : SQL Server, API REST, application web sous IIS. Des clients hétérogènes (postes de votre domaine, ordinateurs appartenant à un client, smartphones/PC sur un Wi‑Fi invité) doivent s’y connecter via HTTPS/TLS sans rencontrer de bannière d’alerte « connexion non sécurisée ».

La question posée : existe‑t‑il une « procédure auto‑signée » universelle qui supprimerait tous les avertissements sur tous les navigateurs et appareils ?

Réponse & solution

Réponse courte : non. Un certificat auto‑signé n’est jamais universellement approuvé. Il ne sera accepté sans avertissement que si chaque client a, au préalable, importé votre certificat (ou la racine qui l’a signé) dans son magasin d’autorités de confiance. C’est irréaliste dès que des appareils externes (que vous ne contrôlez pas) entrent en jeu.

Pour éliminer les alertes sur tout appareil tiers, vous avez besoin d’un certificat émis par une autorité de certification (AC) publique connue des systèmes (chaîne de confiance préinstallée). Deux stratégies s’offrent à vous selon le niveau de contrôle des clients :

Option A — Certificat d’AC publique (recommandé pour les démos chez des clients)

Principe : obtenir un certificat pour un FQDN public que vous possédez (ex. demo.votre-domaine.tld), puis l’installer sur le serveur. Même en environnement offline, la validation repose sur les racines déjà présentes dans les navigateurs ; pas besoin d’Internet au moment de la visite (les clients peuvent tenter de joindre des points OCSP/CRL ; par défaut la plupart des navigateurs ne bloquent pas si ces services sont inaccessibles).

Étapes pas à pas (Windows Server 2022 + IIS + API + SQL Server)

  1. Choisir les noms (SAN) que vos clients utiliseront : demo.votre-domaine.tld, api.demo.votre-domaine.tld, sql.demo.votre-domaine.tld, etc. Évitez localhost et les adresses IP ; les AC publiques n’émettent pas pour des IP privées et n’émettent plus pour des « internal names » non enregistrés publiquement.
  2. Obtenir le certificat :
    • Gratuit & rapide : via un client ACME (p. ex. Let’s Encrypt) avec défi DNS‑01. Vous prouvez que vous contrôlez le domaine en ajoutant un enregistrement TXT dans votre DNS public ; votre service n’a pas besoin d’être exposé.
    • Commercial : acheter un certificat (durée typique : 1 an). Pratique si l’automatisation DNS est complexe.
  3. Installer le PFX (avec clé privée) dans Ordinateur local \ Personnel : # Importer le PFX (mot de passe demandé) Import-PfxCertificate -FilePath "C:\certs\demo.pfx" -CertStoreLocation Cert:\LocalMachine\My Vérifiez que l’EKU contient « Server Authentication » et que la clé privée est présente.
  4. Lier dans IIS (SNI + host name) : Import-Module WebAdministration $thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*CN=demo.votre-domaine.tld*" } | Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint # Créer/mettre à jour le binding HTTPS avec SNI (SslFlags=1) New-WebBinding -Name "Default Web Site" -Protocol https -Port 443 -HostHeader "demo.votre-domaine.tld" -IPAddress "\*" New-Item "IIS:\SslBindings\0.0.0.0!443!demo.votre-domaine.tld" -Thumbprint \$thumb -SSLFlags 1 -Force Si votre API n’est pas sous IIS (Kestrel/http.sys), utilisez un reverse‑proxy (IIS/NGINX) ou chargez le PFX directement dans l’application.
  5. SQL Server (TLS côté SQL) :
    • Ouvrez SQL Server Configuration Manager → Protocols for <instance> → onglet Certificate → sélectionnez le certificat (EKU Server Authentication, clé privée présente, SAN/CN correspondant au nom que vos clients utiliseront).
    • Optionnel : Force Encryption = Yes pour imposer le chiffrement.
    • Le nom de serveur utilisé dans les chaînes de connexion doit figurer dans le SAN du certificat. Exemple .NET : Encrypt=True;TrustServerCertificate=False;Server=sql.demo.votre-domaine.tld,1433;
    • Accordez l’accès à la clé privée au compte de service SQL : MMC > Certificats (ordinateur) > Personnel > certificat > Gérer les clés privées…
  6. Résolution DNS pendant la démo (fonctionne même hors Internet) :
    • Apportez un petit routeur Wi‑Fi configuré en DHCP/DNS pour vos invités.
    • Utilisez un DNS local (split‑horizon) qui pointe demo.votre-domaine.tld vers l’IP locale du serveur (ex. 192.168.10.10).
    • Tout appareil connecté à votre Wi‑Fi résout le bon FQDN ; le certificat public est vu comme valide → aucun avertissement.
  7. Renouvellement :
    • ACME (Let’s Encrypt) : validité 90 jours ; automatisez via votre API DNS (tâche planifiée).
    • Certificats commerciaux : typiquement 1 an ; renouvelez avant l’expiration.

Scripts utiles (exemples)

ACME via PowerShell (idée générale, à adapter selon votre fournisseur DNS) :

# Exemple conceptuel avec un module ACME/DNS
# 1) Créez un compte ACME et acceptez les CGU
# 2) Déclarez l'ordre pour vos domaines
# 3) Choisissez le défi DNS-01
# 4) Créez/validez les enregistrements TXT dans votre DNS
# 5) Récupérez le PFX, installez, puis liez dans IIS

# Import du PFX et liaison IIS (réutilisable)

Param(
\[Parameter(Mandatory=\$true)] \[string]\$PfxPath,
\[Parameter(Mandatory=\$true)] \[string]\$PfxPassword,
\[Parameter(Mandatory=\$true)] \[string]\$SiteName,
\[Parameter(Mandatory=\$true)] \[string]\$Host
)

\$cert = Import-PfxCertificate -FilePath \$PfxPath -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString \$PfxPassword -AsPlainText -Force)
\$thumb = \$cert.Thumbprint
Import-Module WebAdministration
if (-not (Get-WebBinding -Name \$SiteName -Protocol https -ErrorAction SilentlyContinue | Where-Object { $\_.bindingInformation -like "*:443:\$Host" })) {
New-WebBinding -Name \$SiteName -Protocol https -Port 443 -HostHeader \$Host -IPAddress "*"
}
\$bindingPath = "IIS:\SslBindings\0.0.0.0!443!\$Host"
if (Test-Path \$bindingPath) { Remove-Item \$bindingPath -Force }
New-Item \$bindingPath -Thumbprint \$thumb -SSLFlags 1 -Force
Write-Host "Certificat lié à \$Host (site: \$SiteName) - OK"

Avantages & contraintes

  • Avantages : confiance universelle, aucune modification des appareils invités, évolutif.
  • Contraintes : posséder/contrôler un domaine public et son DNS ; prévoir une résolution locale du nom pendant la démo (routeur/DNS).

Option B — AC privée interne (valable si vous contrôlez tous les clients)

Principe : vous créez une autorité de certification privée (AD CS, Smallstep, etc.), vous émettez vos certificats, puis vous déployez votre racine de confiance sur 100 % des clients (GPO, MDM, profils mobiles). Résultat : pas d’alerte uniquement sur ces appareils gérés.

Limite majeure : dès qu’un appareil externe non géré accède à votre démo, le navigateur affichera un avertissement. Cette approche est parfaite pour un intranet ou un lab maîtrisé, pas pour une démonstration chez un client.

Checklist de déploiement AC privée

  • Mettre en place une hiérarchie (racine hors ligne + émettrice) si long terme.
  • Publier une CRL (liste de révocation) accessible par les postes.
  • Automatiser l’enrôlement/renouvellement (GPO/auto‑enrôlement, MDM).
  • Vérifier que les certificats serveur incluent SAN et l’EKU Server Authentication.

Tableau comparatif rapide

ApprocheAvertissements sur appareils externesPrérequisScénarios idéauxLimites
Auto‑signéOui (incontournable)AucunTests locaux rapides, localhostJamais « universel » ; import manuel requis sur chaque client
AC privée interneNon, si tous les clients ont votre racineInfra PKI + déploiement racineIntranet, postes gérés (GPO/MDM)Inadapté aux visiteurs externes
AC publique (recommandé)Non, partoutDomaine public + contrôle DNSDémos chez des clients, Wi‑Fi invitéOrganisation DNS locale pendant la démo

Informations complémentaires essentielles

SAN obligatoire & choix des noms

  • Inscrivez tous les FQDN réellement utilisés (IIS/SNI, API, SQL). Le Common Name seul ne suffit pas.
  • Préférez un sous‑domaine dédié aux démos (ex. demo.votre-domaine.tld).
  • Les AC publiques n’émettent pas pour des noms internes (.local, machines non enregistrées publiquement) ni pour des IP privées.

Exigences du certificat

  • Clé : RSA ≥ 2048 ou ECDSA P‑256.
  • EKU : Server Authentication (OID 1.3.6.1.5.5.7.3.1).
  • Key Usage : échange de clé (KeyEncipherment) pour RSA ; signature si ECDSA.
  • Chaîne complète (« full chain ») lors de l’export PFX.
  • Horloge correcte (serveur et clients) pour éviter « pas encore valide » / « expiré ».

Wildcard

Un certificat *.demo.votre-domaine.tld peut simplifier la couverture de nombreux sous‑domaines. Il exige presque toujours un défi DNS‑01. Pour IIS, assurez-vous d’activer le SNI sur chaque binding HTTPS utilisant le wildcard.

Multiples applications sur le même serveur (SNI)

  • Soit un certificat multi‑SAN (quelques noms), soit plusieurs certificats séparés, un par host ; dans IIS, cochez Require Server Name Indication (ou -SSLFlags 1 en PowerShell).
  • Chaque binding doit préciser le Host name correct, sinon IIS servira « le premier certificat » → erreurs aléatoires.

SQL Server : points d’attention

  • SQL choisit un certificat dans le magasin Ordinateur. S’il y en a plusieurs, il prend celui correspondant au FQDN de l’instance. Évitez d’avoir des certificats obsolètes qui « matchent » partiellement.
  • Donnez l’accès à la clé privée au compte de service NT SERVICE\MSSQLSERVER ou équivalent (instance nommée).
  • Côté clients, préférez Encrypt=True;TrustServerCertificate=False et utilisez le FQDN figurant dans le SAN.
  • TrustServerCertificate=True supprime l’alerte, mais désactive la validation → à éviter en production et pour des démos sérieuses.

Sécurité TLS moderne (Windows Server 2022)

  • Activez TLS 1.2/1.3 (par défaut sur 2022) et désactivez TLS 1.0/1.1 si compatibilité suffisante.
  • N’activez pas HSTS preload pour un environnement éphémère de démo ; un mauvais réglage peut « bloquer » des navigateurs.
  • Privilégiez des suites robustes ; laissez SChannel gérer par défaut sur 2022 sauf exigence spécifique.

Comprendre la chaîne de confiance (schéma)

[Navigateur/Appareil]
        │
        ▼
[Magasin de racines publiques de l’OS]
        │ (contient déjà les racines des AC publiques)
        ▼
[Certificat serveur présenté par votre site]
        │
        └─► Validation&nbsp;: la chaîne (intermédiaire → racine) est reconnue
             ⇒ Pas d’alerte si le FQDN, la date et l’usage sont corrects

Avec un auto‑signé, la « racine » est votre propre certificat ; comme elle n’existe pas dans les magasins des visiteurs, l’alerte est inévitable à moins d’importer votre racine sur chaque appareil.

Mise en place d’un DNS local de démo (split‑horizon)

Objectif : faire résoudre demo.votre-domaine.tld vers l’IP privée de votre serveur pendant la démo, sans rien modifier sur les appareils invités.

  1. Routeur Wi‑Fi : configurez son serveur DHCP pour fournir l’adresse de votre DNS local (ou un simple « DNS override » si le routeur le permet).
  2. DNS local : créez une zone votre-domaine.tld et un A pour demo pointant vers l’IP du serveur (et api, sql si besoin).
  3. Option express : si vous ne pouvez pas déployer un DNS, remplacez au minimum sur votre propre PC la résolution via hosts. Mais cette méthode n’élimine pas la dépendance côté invités.

Astuce : apportez un plan B (partage 4G/5G + DNS contrôlé) si le site du client impose un proxy ou des restrictions DHCP.

Procédures rapides pour une API .NET (Kestrel)

Si votre API tourne en Kestrel, vous pouvez charger le PFX directement :

// Program.cs (minimal API .NET)
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options =&gt;
{
    options.ListenAnyIP(443, listenOptions =&gt;
    {
        listenOptions.UseHttps("C:\\certs\\demo.pfx", "PfxPasswordIci");
    });
});
var app = builder.Build();
app.MapGet("/health", () =&gt; Results.Ok("OK"));
app.UseHttpsRedirection();
app.Run();

En présence d’autres sites/applications, préférez un reverse‑proxy (IIS) pour centraliser TLS + SNI et délester vos applis.

Erreurs fréquentes & comment les éviter

  • Oublier le SAN : le FQDN client n’est pas listé → alerte. Ajoutez tous les noms utiles dès la demande.
  • Mauvaise liaison IIS : SNI non activé, ou host name absent → mauvais certificat servi. Revoir les bindings.
  • Clé privée indisponible pour SQL/IIS : droits manquants sur la clé → erreurs au démarrage. Attribuez l’accès au compte de service.
  • Mélange IP/FQDN côté clients : ils appellent l’IP directe → le FQDN ne correspond pas au certificat. Forcer l’usage du FQDN.
  • Horloge système fausse : l’heure dérive (VM, BIOS) → « pas encore valide ». Synchronisez NTP.
  • Wildcard mal compris : *.demo.tld ne couvre pas demo.tld lui‑même ; ajoutez aussi le FQDN racine si nécessaire.

Checklist de préparation express (avant votre démo)

ÉlémentPourquoiComment vérifier
FQDN publics définisCorrespondance certif <→> URLLa liste SAN contient 100 % des noms utilisés
Certificat public valideConfiance universelleChaîne complète, dates OK, EKU serveur
Bindings IIS + SNIBon certif par siteHost name renseigné, SSLFlags = 1
SQL Server chiffréDonnées en transitCertif sélectionné + Encrypt=True côté client
DNS local prêtRésolution FQDN hors‑lignePing des noms → IP locale du serveur
Renouvellement planifiéÉviter l’expirationTâche ACME/alerte calendrier

FAQ ciblée

Un certificat auto‑signé peut‑il fonctionner « sans alerte » si j’importe la racine sur mon PC ?
Oui, sur votre PC uniquement. Sur tout autre appareil non préparé, une alerte apparaîtra. Donc pas « universel ».

Et si j’utilise l’adresse IP dans l’URL ?
Les AC publiques n’émettent pas pour les IP privées (et rarement pour des IP publiques). Les navigateurs exigent un nom DNS dans le certificat ; utilisez un FQDN.

Ai‑je besoin d’Internet pendant la démo ?
Non, si les visiteurs se connectent à votre réseau local et que votre DNS local résout le FQDN vers l’IP du serveur. La confiance vient du magasin de racines déjà présent sur leurs appareils.

Le contrôle OCSP/CRL va‑t‑il bloquer ?
En général, non ; la plupart des navigateurs sont en « soft‑fail » si OCSP/CRL est injoignable. Évitez toutefois d’activer « OCSP Must‑Staple » ou des politiques qui imposent la vérification en mode strict pour une démo hors‑ligne.

Puis‑je réutiliser le même certif pour IIS et SQL Server ?
Oui, si le SAN couvre les noms utilisés pour les deux services et si l’EKU inclut Server Authentication. Exportez en PFX avec la clé privée et installez côté machine.

Modèle de plan d’adressage et de noms pour une démo robuste

  • VLAN/Plage locale : 192.168.10.0/24
  • Serveur de démo : 192.168.10.10
  • Wi‑Fi invité : SSID DemoTLS (WPA2/3)
  • DNS local : zone votre-domaine.tld avec enregistrements :
    • demo → 192.168.10.10
    • api.demo → 192.168.10.10
    • sql.demo → 192.168.10.10
  • Certificat : SAN = demo.votre-domaine.tld, api.demo.votre-domaine.tld, sql.demo.votre-domaine.tld

Résumé opérationnel

  • Auto‑signé : jamais universellement fiable → avertissements inévitables sur les appareils externes.
  • Objectif « zéro alerte » partout : certificat d’AC publique sur un FQDN que vous contrôlez + DNS local lors de la démo.
  • Si vous contrôlez les postes : AC privée + déploiement de la racine de confiance via GPO/MDM.
  • IIS : bindings HTTPS par nom + SNI, certificat PFX correctement lié.
  • SQL Server : certificat avec SAN correspondant, Encrypt=True, TrustServerCertificate=False.

Annexe — Commandes rapides d’inspection

Lister les certificats serveur (machine) :

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, EnhancedKeyUsageList, Thumbprint

Voir les liaisons HTTPS IIS :

Import-Module WebAdministration
Get-WebBinding -Protocol https | Select-Object bindingInformation, HostHeader, SslFlags

Vérifier l’accès à la clé privée :

# Ouvre la console MMC ciblée
certlm.msc
# (clic droit sur le certificat &gt; Toutes les tâches &gt; Gérer les clés privées…)

Conclusion

La seule façon fiable et universelle d’éviter toute alerte navigateur lors d’une démo multi‑appareils consiste à présenter un certificat signé par une AC publique pour un FQDN que vous possédez, puis à maîtriser la résolution DNS locale. Les certificats auto‑signés et les AC privées restent d’excellents outils pour les labs internes, mais ils ne répondent pas au cahier des charges « zéro avertissement chez n’importe quel client ». En appliquant le pas‑à‑pas ci‑dessus (SAN exhaustif, bindings IIS avec SNI, configuration SQL Server, scripts d’import PFX et DNS local), vous obtiendrez une expérience fluide et professionnelle, partout où vous présenterez votre solution.

Windows Server
Sommaire