Ce guide explique comment générer une CSR (Certificate Signing Request) pour Microsoft 365 (Office 365). La réponse honnête d’abord : vous ne générez pas de CSR pour le cloud Microsoft 365 lui-même. Microsoft 365 est une plateforme SaaS hébergée, donc Microsoft possède et gère les certificats TLS sur outlook.office365.com, les points de terminaison de messagerie *.mail.protection.outlook.com, *.sharepoint.com, et les autres services hébergés par Microsoft. Il n’existe aucune page de portail qui accepte un certificat fourni par le client pour ces URL.
Une CSR entre en jeu uniquement lorsque vous exploitez également un serveur sur site ou hébergé dans le cloud qui s’intègre avec Microsoft 365. La CSR est générée sur ce serveur, et non dans le portail d’administration Microsoft 365. Les sections ci-dessous couvrent les scénarios où cela se produit réellement.
Dans quel scénario êtes-vous ?
Choisissez la ligne qui correspond à ce que vous essayez réellement de sécuriser, puis accédez à la section correspondante :
| Ce que vous essayez de sécuriser | Où la CSR est générée | Section |
|---|---|---|
| Les services cloud Microsoft 365 eux-mêmes (Exchange Online, SharePoint Online, Teams, outlook.office365.com) | Nulle part. Microsoft gère ces certificats. | Pourquoi il n’y a pas de CSR pour le cloud |
| Un serveur Exchange sur site en configuration hybride avec Exchange Online | Sur le serveur Exchange sur site (PowerShell, ou l’EAC sur les versions prises en charge) | CSR Exchange hybride |
| Un serveur AD FS fédérant la connexion avec Microsoft 365 / Entra ID | Sur le serveur AD FS (demande de certificat Windows) | CSR de fédération AD FS / Entra |
| Une application web Azure App Service, une fonction ou une API qui se connecte à Microsoft 365 | Générée en externe (n’importe quel outil), puis téléchargée sur Azure | CSR Azure App Service |
| Un serveur web Windows autonome (IIS) qui n’est pas Exchange, mais qui s’intègre avec Microsoft 365 (par exemple un portail, un récepteur de hook, ou un relais) | Dans le Gestionnaire IIS sur ce serveur | CSR pour un serveur IIS autonome |
Pourquoi il n’y a pas de CSR pour le cloud Microsoft 365
Microsoft 365 est une plateforme cloud entièrement hébergée et multi-locataire. Les certificats TLS pour Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, et tous les autres points de terminaison hébergés par Microsoft sont émis, déployés et renouvelés par Microsoft. Il n’existe aucune page du centre d’administration, aucune cmdlet PowerShell, ni aucune API permettant à un client de télécharger un certificat tiers vers outlook.office365.com, les points de terminaison de flux de messagerie *.mail.protection.outlook.com, ou tout autre nom d’hôte appartenant à Microsoft. Cela inclut le cas où vous avez ajouté votre propre domaine personnalisé tel que contoso.com : une fois le domaine vérifié, Microsoft continue de terminer le TLS pour les points de terminaison SMTP, IMAP, POP et HTTPS sous-jacents, donc aucune CSR n’est nécessaire de votre côté.
Si votre objectif est d’imposer le TLS sur le flux de messagerie entre Microsoft 365 et un partenaire externe, vous le faites avec un connecteur Exchange Online qui exige que le partenaire présente un certificat public valide. Aucun certificat n’est téléchargé de votre côté. Consultez notre guide d’installation SSL pour Microsoft 365 pour les étapes du connecteur.
Générer la CSR pour Exchange hybride (Exchange Server sur site)
Si vous avez déjà généré votre CSR sur votre serveur Exchange sur site, passez directement au guide d’installation SSL Microsoft 365 / Exchange. Sinon, voici la raison la plus courante pour laquelle les clients demandent une « CSR Microsoft 365 ». Dans un déploiement hybride, votre serveur Exchange sur site (2016, 2019, ou Subscription Edition) communique avec Exchange Online via OAuth, EWS et Autodiscover, et ces connexions doivent être sécurisées avec un certificat de confiance publique. Vous générez la CSR sur le serveur Exchange sur site, et non sur quoi que ce soit dans Microsoft 365.
Sur chaque version prise en charge d’Exchange (et comme seul chemin pris en charge sur Exchange 2016 CU23+ et Exchange 2019 CU12 à CU14, où Microsoft a supprimé les options de certificat de l’EAC), la CSR est générée avec PowerShell. Exécutez Exchange Management Shell en tant qu’administrateur sur le serveur qui détiendra la clé privée, puis exécutez :
New-ExchangeCertificate `
-GenerateRequest `
-SubjectName "C=US, S=California, L=San Francisco, O=Example Inc, OU=IT, CN=mail.example.com" `
-DomainName mail.example.com, autodiscover.example.com `
-KeySize 2048 `
-PrivateKeyExportable $true `
| Set-Content -Path "C:certsexchange.req"L’utilisation en deux étapes (la sortie de la cmdlet redirigée vers Set-Content) est requise sur les versions actuelles : la mise à jour de sécurité KB5014278 a supprimé l’ancien paramètre -RequestFile de New-ExchangeCertificate sur Exchange 2016 CU23 et Exchange 2019 CU12. Modifiez les valeurs pour correspondre à votre environnement :
- C est le code pays à deux lettres (US, GB, DE, etc.).
- S est le nom complet de l’état ou de la province, pas l’abréviation.
- L est la ville ou la localité complète.
- O est le nom légalement enregistré de l’entreprise.
- OU est le département, souvent « IT ». Optionnel.
- CN est le nom d’hôte principal entièrement qualifié que le certificat sécurisera, par exemple mail.example.com.
- -DomainName est la liste des Subject Alternative Name (SAN) séparés par des virgules. Pour un déploiement hybride, incluez au moins mail.example.com et autodiscover.example.com, ainsi que tous les espaces de noms supplémentaires que vous utilisez (OWA, EWS, noms d’hôtes hybrides).
- -KeySize 2048 correspond aux exigences de base du CA/Browser Forum. Utilisez 4096 uniquement si votre politique de sécurité l’exige. Microsoft ne documente que 1024, 2048 et 4096 comme valeurs valides pour
-KeySize, donc n’utilisez pas 3072 ici. - -PrivateKeyExportable $true vous permet d’exporter la clé plus tard pour une sauvegarde ou pour la partager avec les autres nœuds d’un DAG.
Sur Exchange Server Subscription Edition et Exchange 2019 CU15, l’assistant de certificat de l’EAC dans Serveurs > Certificats est de nouveau disponible comme flux d’interface graphique alternatif. La procédure complète pas à pas (PowerShell et l’assistant EAC, avec des notes version par version) se trouve sur notre guide complémentaire guide de CSR pour Microsoft Exchange. Utilisez cette page pour le flux canonique de CSR Exchange hybride ; la même CSR fonctionne pour le certificat que vous attribuerez aux services Exchange sur site qui se connectent à Microsoft 365.
Une fois la cmdlet exécutée, ouvrez le fichier .req dans le Bloc-notes et vérifiez qu’il ressemble à un bloc PEM normal :
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIC6TCCAdECAQAwgaMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
...
-----END NEW CERTIFICATE REQUEST-----Copiez l’intégralité du bloc, y compris les lignes BEGIN et END (cinq tirets de chaque côté), et collez-le dans le champ CSR de votre commande SSL. Décodez-le d’abord avec notre Décodeur de CSR pour confirmer le nom commun, les SAN et la taille de la clé avant de soumettre.
Générer la CSR pour la fédération AD FS / Entra ID avec Microsoft 365
Si vous utilisez AD FS (Active Directory Federation Services) pour fédérer la connexion entre votre Active Directory sur site et Microsoft Entra ID (anciennement Azure AD) pour l’authentification unique Microsoft 365, le service AD FS a besoin d’un certificat TLS de confiance publique pour son nom de service de fédération (par exemple sts.example.com). Ce certificat est lié au service AD FS et au Web Application Proxy optionnel placé devant lui.
La CSR est générée sur le serveur AD FS (ou n’importe quel serveur Windows) à l’aide du composant logiciel enfichable de certificats de la Console de gestion Microsoft ou de PowerShell, puis soumise à une CA publique. Vous pouvez soit générer la CSR avec notre Générateur de CSR (puis combiner ultérieurement le certificat émis et la clé dans un fichier .pfx), soit suivre notre guide de CSR pour Windows pour produire la demande directement sur le serveur. Le même certificat est ensuite attribué au service AD FS avec Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumb>.
Les certificats de signature de jeton et de déchiffrement de jeton au sein d’AD FS constituent un sujet distinct. Ils sont généralement auto-signés et renouvelés automatiquement par AD FS lui-même, donc vous ne générez pas de CSR pour ceux-ci.
Générer la CSR pour une application Azure App Service qui s’intègre avec Microsoft 365
Si vous hébergez une application web, une fonction ou une API sur Azure App Service qui se connecte à Microsoft 365 (un portail personnalisé, un point de terminaison SSO, un récepteur de webhook), vous sécurisez son domaine personnalisé avec un certificat que vous téléchargez vers Azure. Azure App Service ne génère pas de CSR lui-même : vous générez la demande en dehors d’Azure et téléchargez le fichier .pfx résultant.
Le chemin le plus simple est notre Générateur de CSR : saisissez vos informations, téléchargez la CSR et la clé privée correspondante, soumettez la CSR à la CA, puis combinez le certificat émis, les intermédiaires et la clé privée dans un fichier .pfx (PKCS#12). Téléchargez ce .pfx dans App Service > Certificats > Apportez vos propres certificats (.pfx) et associez-le à votre domaine personnalisé. Si vous préférez un flux entièrement géré par le serveur, générez la CSR sur un poste d’administration Windows en utilisant notre guide de CSR pour Windows et exportez le résultat vers un fichier .pfx avant de le télécharger. Azure exige que le certificat inclue l’usage étendu de la clé Authentification de serveur (OID 1.3.6.1.5.5.7.3.1), ce que fait déjà tout certificat SSL commercial.
Générer la CSR sur un serveur Windows / IIS autonome
Si « Office 365 » signifie en réalité dans votre cas « un serveur Windows exécutant IIS dans le même environnement que Microsoft 365 » (par exemple un portail, un site intranet, ou un relais non-Exchange), alors vous générez la CSR dans le Gestionnaire IIS sur ce serveur. C’est le chemin que décrivait le tutoriel original. C’est le bon flux pour un hôte IIS générique, mais il ne produit pas de certificat pour le cloud Microsoft 365, seulement pour le site hébergé par IIS que vous gérez.
- Ouvrez Démarrer > Outils d’administration Windows > Gestionnaire des services Internet (IIS), ou appuyez sur Win + R, tapez
inetmgr, et appuyez sur Entrée. - Dans le panneau Connexions à gauche, sélectionnez votre nom de serveur.
- Dans le panneau central, double-cliquez sur Certificats de serveur.
- Dans le panneau Actions à droite, cliquez sur Créer une demande de certificat.
- Dans l’assistant Demander un certificat, remplissez les champs des Propriétés du nom distinctif comme suit :
- Nom commun : le nom de domaine entièrement qualifié que vous souhaitez sécuriser, par exemple portal.example.com. Ne saisissez pas outlook.office365.com ni aucun nom d’hôte appartenant à Microsoft.
- Organisation : le nom légal complet de votre entreprise (par exemple Example Inc.).
- Unité organisationnelle : le département, souvent IT.
- Ville/localité : la ville où votre entreprise est enregistrée (ne pas abréger).
- État/province : le nom complet de l’état ou de la province (ne pas abréger).
- Pays/région : le code pays ISO à deux lettres (US, GB, DE, etc.).
- Cliquez sur Suivant.
- Sur l’écran Propriétés du fournisseur de services de cryptographie, laissez le fournisseur sur Microsoft RSA SChannel Cryptographic Provider, réglez la Longueur de bit sur 2048 (ou 3072 / 4096 si votre politique l’exige), puis cliquez sur Suivant.
- Indiquez un nom de fichier pour la CSR (par exemple C:certsportal.req) et cliquez sur Terminer.
IIS ne génère pas de Subject Alternative Names via cet assistant. Pour un certificat SAN ou multi-domaines, générez la CSR avec PowerShell en utilisant un fichier INF personnalisé avec certreq, ou utilisez notre Générateur de CSR et combinez ensuite le certificat émis et la clé dans un fichier .pfx pour l’importation. Pour le flux complet spécifique à IIS avec captures d’écran, consultez notre guide de CSR pour Microsoft IIS.
Ouvrez le fichier .req enregistré dans le Bloc-notes et copiez le bloc complet, y compris les lignes -----BEGIN NEW CERTIFICATE REQUEST----- et -----END NEW CERTIFICATE REQUEST-----, dans le formulaire de commande de votre CA.
Vérifier votre CSR avant de la soumettre
Avant de coller la CSR dans le formulaire de commande, décodez-la pour confirmer que les informations sont correctes. Une faute de frappe dans le nom commun, un SAN manquant, ou une longueur de clé trop courte entraînera le rejet de la commande ou obligera à une réémission plus tard. Collez la CSR dans notre Décodeur de CSR pour voir le nom commun, la liste complète des SAN, l’organisation, le pays, l’algorithme de signature et la taille de la clé.
Une fois que la CA valide la demande et émet le certificat, poursuivez avec notre guide d’installation SSL pour Microsoft 365 pour l’étape d’installation correspondante (importation Exchange hybride, liaison AD FS, téléchargement Azure App Service, ou liaison IIS).
Economisez 10% sur les certificats SSL en commandant aujourd’hui!
Émission rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon: SAVE10
