Exigences de certificat d’infrastructure à clé publique (PKI) Azure Stack Hub

Azure Stack Hub dispose d’un réseau d’infrastructure publique utilisant des adresses IP publiques accessibles en externe affectées à un petit ensemble de services Azure Stack Hub et éventuellement des machines virtuelles clientes. Les certificats PKI avec les noms DNS appropriés pour ces points de terminaison d’infrastructure publique Azure Stack Hub sont requis pendant le déploiement d’Azure Stack Hub. Cet article fournit des informations sur :

• Exigences de certificat pour Azure Stack Hub.
• Certificats obligatoires requis pour le déploiement d’Azure Stack Hub.
• Certificats facultatifs requis lors du déploiement de fournisseurs de ressources à valeur ajoutée.

Remarque

Par défaut, Azure Stack Hub utilise également des certificats émis par une autorité de certification intégrée Active Directory interne pour l’authentification entre les nœuds. Pour valider le certificat, toutes les machines d’infrastructure Azure Stack Hub approuvent le certificat racine de l’autorité de certification interne en ajoutant ce certificat à leur magasin de certificats local. Il n’existe pas d’épinglage ou de filtrage de certificats dans Azure Stack Hub. Le san de chaque certificat de serveur est validé par rapport au nom de domaine complet de la cible. La chaîne d’approbation entière est également validée, ainsi que la date d’expiration du certificat (authentification du serveur TLS standard sans épinglage de certificat).

Conditions requises pour les certificats

La liste suivante décrit les exigences générales relatives à l’émission, à la sécurité et à la mise en forme des certificats :

• Les certificats doivent être émis par une autorité de certification interne ou une autorité de certification publique. Si une autorité de certification publique est utilisée, elle doit être incluse dans l’image du système d’exploitation de base dans le cadre du programme Microsoft Trusted Root Authority. Pour voir la liste complète, consultez liste des participants – Programme de certification racine approuvé Microsoft.
• Votre infrastructure Azure Stack Hub doit avoir accès au réseau de l’emplacement de la liste de révocation de certificats de l’autorité de certification publiée dans le certificat. Cette CRL doit être un point de terminaison http. Remarque : pour les déploiements déconnectés, les certificats émis par une autorité de certification publique ne sont pas pris en charge, si le point de terminaison de la liste de révocation de certificats n’est pas accessible. Pour plus d’informations, consultez Fonctionnalités qui sont altérées ou indisponibles dans les déploiements déconnectés.

• Lors de la rotation des certificats pour les builds 1903 et ultérieures, les certificats peuvent être émis par n’importe quelle autorité de certification d’entreprise ou publique.

• L’utilisation de certificats auto-signés n’est pas prise en charge.
• Pour le déploiement et la rotation, vous pouvez utiliser un certificat unique couvrant tous les espaces de noms dans le nom de l’objet du certificat et l’autre nom de l’objet (SAN). Vous pouvez également utiliser des certificats individuels pour chacun des espaces de noms ci-dessous que les services Azure Stack Hub que vous envisagez d’utiliser nécessitent. Les deux approches nécessitent l’utilisation de caractères génériques pour les points de terminaison où elles sont requises, telles que KeyVault et KeyVaultInternal.
• L’algorithme de signature de certificat ne doit pas être SHA1.
• Le format de certificat doit être PFX, car les clés publiques et privées sont requises pour l’installation d’Azure Stack Hub. La clé privée doit être définie pour l’attribut de clé Ordinateur local.
• Le chiffrement PFX doit être 3DES (ce chiffrement est par défaut lors de l’exportation à partir d’un client Windows 10 ou d’un magasin de certificats Windows Server 2016).
• Les fichiers pfx de certificat doivent avoir une valeur « Signature numérique » et « KeyEncipherment » dans son champ « Utilisation de la clé ».
• Les fichiers pfx de certificat doivent avoir les valeurs « Authentification du serveur (1.3.6.1.5.5.7.3.1) » et « Authentification du client (1.3.6.1.5.7.3.2) » dans le champ « Utilisation améliorée de la clé ».
• Le champ « Émis à : » du certificat ne doit pas être identique à son champ « Émis par : ».
• Les mots de passe de tous les fichiers pfx de certificat doivent être identiques au moment du déploiement.
• Le mot de passe du certificat pfx doit être un mot de passe complexe. Notez ce mot de passe, car vous l’utiliserez comme paramètre de déploiement. Le mot de passe doit répondre aux exigences de complexité de mot de passe suivantes :
  • Longueur minimale de huit caractères.
  • Au moins trois des caractères suivants : lettre majuscule, lettre minuscule, chiffres compris entre 0 et 9, caractères spéciaux, caractère alphabétique qui n’est pas majuscule ou minuscule.
• Vérifiez que les noms d’objet et les autres noms d’objet dans l’extension de nom de l’objet (x509v3_config) correspondent. Le champ de nom alternatif de l’objet vous permet de spécifier des noms d’hôtes supplémentaires (sites web, adresses IP, noms communs) à protéger par un seul certificat SSL.

Remarque

Les certificats auto-signés ne sont pas pris en charge.
Lors du déploiement d’Azure Stack Hub en mode déconnecté, il est recommandé d’utiliser des certificats émis par une autorité de certification d’entreprise. Cela est important, car les clients accédant aux points de terminaison Azure Stack Hub doivent être en mesure de contacter la liste de révocation de certificats (CRL).

Remarque

La présence d’autorités de certification intermédiaires dans les chaînes de confiance d’un certificat est prise en charge.

Certificats obligatoires

Le tableau de cette section décrit les certificats PKI de point de terminaison public Azure Stack Hub requis pour les déploiements Microsoft Entra ID et AD FS Azure Stack Hub. Les exigences de certificat sont regroupées par zone, et les espaces de noms utilisés et les certificats requis pour chaque espace de noms. Le tableau décrit également le dossier dans lequel votre fournisseur de solutions copie les différents certificats par point de terminaison public.

Des certificats avec des noms de DNS appropriés pour chaque point de terminaison d’infrastructure publique Azure Stack Hub sont requis. Le nom DNS de chaque point de terminaison est exprimé au format : <préfixe>.<région>.<fqdn>.

Pour votre déploiement, les <valeurs de région> et <de fqdn> doivent correspondre à la région et aux noms de domaine externes que vous avez choisis pour votre système Azure Stack Hub. Par exemple, si la région est Redmond et que le nom de domaine externe est contoso.com, les noms DNS auront le préfixe> de format.redmond.contoso.com<. Les <valeurs de préfixe> sont prédéfinisées par Microsoft pour décrire le point de terminaison sécurisé par le certificat. En outre, les <valeurs de préfixe> des points de terminaison d’infrastructure externe dépendent du service Azure Stack Hub qui utilise le point de terminaison spécifique.

Pour les environnements de production, nous recommandons de générer des certificats individuels pour chaque point de terminaison et de les copier dans le répertoire correspondant. Pour les environnements de développement, les certificats peuvent être fournis en tant que certificat générique unique couvrant tous les espaces de noms dans les champs Subject and Subject Alternative Name (SAN) copiés dans tous les répertoires. Un certificat unique couvrant tous les points de terminaison et services pose des problèmes de sécurité ; cette approche est donc destinée aux équipes de développement uniquement. N’oubliez pas que les deux options requièrent l’utilisation de certificats avec caractères génériques pour les points de terminaison tels que acs et le coffre de clés lorsqu’ils sont requis.

Remarque

Pendant le déploiement, vous devez copier des certificats dans le dossier de déploiement qui correspond au fournisseur d’identité sur lequel vous effectuez le déploiement (Microsoft Entra ID ou AD FS). Si vous utilisez un certificat unique pour tous les points de terminaison, vous devez copier ce fichier de certificat dans chaque dossier de déploiement, comme indiqué dans les tableaux suivants. La structure de dossiers est prédéfinie dans la machine virtuelle de déploiement et se trouve à l’adresse : C :\CloudDeployment\Setup\Certificates.

Dossier de déploiement	Objet du certificat requis et autres noms d’objet (SAN)	Étendue (par région)	Espace de noms de sous-domaine
Portail public	portail.<région>.<Fqdn>	Portails	<région>.<Fqdn>
Portail d’administration	adminportal.<région>.<Fqdn>	Portails	<région>.<Fqdn>
Azure Resource Manager Public	gestion.<région>.<Fqdn>	Azure Resource Manager	<région>.<Fqdn>
Administrateur Azure Resource Manager	adminmanagement.<région>.<Fqdn>	Azure Resource Manager	<région>.<Fqdn>
ACSBlob	*.BLOB.<région>.<Fqdn> (Certificat SSL générique)	Stockage Blob	BLOB.<région>.<Fqdn>
ACSTable	*.table.<région>.<Fqdn> (Certificat SSL générique)	Stockage de tables	table.<région>.<Fqdn>
ACSQueue	*.queue.<région>.<Fqdn> (Certificat SSL générique)	Stockage de files d'attente	queue.<région>.<Fqdn>
KeyVault	*.voûte.<région>.<Fqdn> (Certificat SSL générique)	Coffre-fort de clés	voûte.<région>.<Fqdn>
KeyVaultInternal	*.adminvault.<région>.<Fqdn> (Certificat SSL générique)	Coffre de clés interne	adminvault.<région>.<Fqdn>
Hôte d’extension d’administration	*.adminhosting.<région>.<fqdn> (certificats SSL génériques)	Hôte d’extension d’administration	adminhosting.<région>.<Fqdn>
Hôte d’extension public	*.hébergement.<région>.<fqdn> (certificats SSL génériques)	Hôte d’extension public	hébergement.<région>.<Fqdn>

Si vous déployez Azure Stack Hub à l’aide du mode de déploiement Microsoft Entra, vous devez uniquement demander les certificats répertoriés dans le tableau précédent. Toutefois, si vous déployez Azure Stack Hub à l’aide du mode de déploiement AD FS, vous devez également demander les certificats décrits dans le tableau suivant :

Dossier de déploiement	Objet du certificat requis et autres noms d’objet (SAN)	Étendue (par région)	Espace de noms de sous-domaine
ADFS	adfs. <région>.<Fqdn> (Certificat SSL)	ADFS	<région>.<Fqdn>
Graphique	graphique. <région>.<Fqdn> (Certificat SSL)	Graphique	<région>.<Fqdn>

Important

Tous les certificats répertoriés dans cette section doivent avoir le même mot de passe.

Certificats PaaS facultatifs

Si vous envisagez de déployer des services PaaS Azure Stack Hub (tels que SQL, MySQL, App Service ou Event Hubs) après le déploiement et la configuration d’Azure Stack Hub, vous devez demander des certificats supplémentaires pour couvrir les points de terminaison des services PaaS.

Important

Les certificats que vous utilisez pour les fournisseurs de ressources doivent avoir la même autorité racine que celles utilisées pour les points de terminaison Azure Stack Hub globaux.

Le tableau suivant décrit les points de terminaison et les certificats requis pour les fournisseurs de ressources. Vous n’avez pas besoin de copier ces certificats dans le dossier de déploiement Azure Stack Hub. Au lieu de cela, vous fournissez ces certificats pendant l’installation du fournisseur de ressources.

Étendue (par région)	Certificat	Objet du certificat requis et autres noms d’objet (SAN)	Espace de noms de sous-domaine
Service d'application	Certificat SSL par défaut du trafic web	*.appservice. <région>.<Fqdn> *.scm.appservice. <région>.<Fqdn> *.sso.appservice. <région>.<Fqdn> (Certificat SSL à caractères génériques multi-domaines1)	appservice. <région>.<Fqdn> scm.appservice. <région>.<Fqdn>
Service d'application	API (Interface de Programmation d'Applications)	api.appservice. <région>.<Fqdn> (Certificat SSL2)	appservice. <région>.<Fqdn> scm.appservice. <région>.<Fqdn>
Service d'application	FTP	ftp.appservice. <région>.<Fqdn> (Certificat SSL2)	appservice. <région>.<Fqdn> scm.appservice. <région>.<Fqdn>
Service d'application	Authentification unique (SSO)	sso.appservice. <région>.<Fqdn> (Certificat SSL2)	appservice. <région>.<Fqdn> scm.appservice. <région>.<Fqdn>
Event Hubs	SSL	*.eventhub. <région>.<Fqdn> (Certificat SSL générique)	eventhub. <région>.<Fqdn>
SQL, MySQL	SQL et MySQL	*.dbadapter. <région>.<Fqdn> (Certificat SSL générique)	dbadapter. <région>.<Fqdn>

¹ Nécessite un certificat avec plusieurs noms d’autres sujets génériques. Plusieurs SAN génériques sur un seul certificat peuvent ne pas être pris en charge par toutes les autorités de certification publiques.

² A *.appservice. <région>.<Le certificat générique fqdn> ne peut pas être utilisé à la place de ces trois certificats (api.appservice.<région>.<fqdn>, ftp.appservice. <région>.<fqdn> et sso.appservice. <région>.<fqdn>. Appservice nécessite explicitement l’utilisation de certificats distincts pour ces points de terminaison.

Étapes suivantes

Découvrez comment générer des certificats PKI pour le déploiement d’Azure Stack Hub.