Vue d’ensemble des certificats pour Azure Cloud Services (classique)
Important
Cloud Services (classique) est désormais déconseillé pour tous les clients depuis le 1er septembre 2024. Tous les déploiements existants en cours d’exécution seront arrêtés par Microsoft, et les données seront définitivement perdues à partir d’octobre 2024. Les nouveaux déploiements doivent utiliser le nouveau modèle de déploiement basé sur Azure Resource Manager Azure Cloud Services (support étendu) .
Dans Azure, des certificats sont utilisés pour les services cloud (certificats de service) et pour l’authentification auprès de l’API de gestion (certificats de gestion). Cet article offre une vue d’ensemble de ces deux types de certificats et vous explique comment les créer et les déployer dans Azure.
Les certificats utilisés dans Azure sont des certificats x.509 v3. Ils peuvent se signer automatiquement ou être signés par un autre certificat approuvé. Un certificat est auto-signé lorsque son créateur le signe. Les certificats auto-signés ne sont pas approuvés par défaut, mais la plupart des navigateurs peuvent ignorer ce problème. Les certificats auto-signés ne doivent être utilisés que par vous au moment où vous développez et testez vos services cloud.
Les certificats utilisés par Azure peuvent contenir une clé publique. Les certificats comportent une empreinte numérique qui permet de les identifier sans ambiguïté. Cette empreinte numérique est utilisée dans le fichier de configuration Azure pour identifier le certificat qu’un service cloud doit utiliser.
Notes
Azure Cloud Services n’accepte pas de certificat chiffré AES256-SHA256.
Que sont les certificats de service ?
Les certificats de service sont associés aux services cloud et sécurisent les communications à destination et en provenance du service. Par exemple, si vous avez déployé un rôle web, vous pouvez fournir un certificat qui peut authentifier un point de terminaison HTTPS exposé. Les certificats de service, définis dans votre définition de service, sont déployés automatiquement sur la machine virtuelle qui exécute une instance de votre rôle.
Vous pouvez charger les certificats de service dans Azure par l’intermédiaire du portail Azure ou à l’aide du modèle de déploiement classique. Les certificats de service sont associés à un service cloud spécifique. Le fichier de définition de service les affecte à un déploiement.
Les certificats de service peuvent être gérés séparément de vos services et par différentes personnes. Par exemple, un développeur peut charger un package de services qui fait référence à un certificat précédemment chargé sur Azure par un responsable informatique. Un responsable informatique peut gérer et renouveler ce certificat (en modifiant la configuration du service) sans avoir à charger un nouveau package de services. La mise à jour sans nouveau package de service est possible par le fait que le nom logique, ainsi que le nom et l’emplacement du magasin du certificat sont spécifiés dans le fichier de définition de service, alors que l’empreinte numérique du certificat est spécifiée dans le fichier de configuration de service. Pour mettre à jour le certificat, il est uniquement nécessaire de charger un nouveau certificat et de modifier la valeur d’empreinte numérique dans le fichier de configuration de service.
Notes
L’article Forum aux questions sur Azure Cloud Services - Configuration et gestion comporte des informations utiles sur les certificats.
Que sont les certificats de gestion ?
Les certificats de gestion vous permettent de vous authentifier dans le modèle de déploiement classique. De nombreux programmes et outils (tels que Visual Studio ou le Kit de développement logiciel (SDK) Azure) utilisent ces certificats pour automatiser la configuration et le déploiement de divers services Azure. Ces certificats ne sont pas liés aux services cloud.
Avertissement
Soyez prudent ! Ces types de certificat permettent à toute personne qui s’authentifie par leur biais de gérer l’abonnement auquel ils sont associés.
Limites
Le nombre de certificats de gestion est limité à 100 par abonnement. Il existe également une limite de 100 certificats de gestion pour l’ensemble des abonnements figurant sous un identificateur d’utilisateur d’Administrateur de service spécifique. Si l’identificateur d’utilisateur de l’administrateur de compte a déjà été utilisé pour ajouter 100 certificats de gestion et d’autres certificats sont nécessaires, vous pouvez ajouter un coadministrateur pour ajouter plus de certificats.
En outre, les certificats de gestion ne peuvent pas être utilisés avec les abonnements du fournisseur de solutions Cloud (CSP), car les abonnements CSP prennent uniquement en charge le modèle de déploiement Azure Resource Manager, tandis que les certificats de gestion utilisent le modèle de déploiement classique. Pour plus d’informations sur les options disponibles pour les abonnements CSP, consultez les références Azure Resource Manager vs modèle de déploiement classique et Comprendre l’authentification avec le kit de développement logiciel (SDK) Azure pour .NET.
Création d’un certificat auto-signé
Vous pouvez créer un certificat auto-signé au moyen de n’importe quel outil disponible, à condition qu’il remplisse les conditions suivantes :
Certificat X.509.
Contient une clé publique.
Créé pour l’échange de clés (fichier .pfx).
Le nom du sujet doit correspondre au domaine servant à accéder au service cloud.
Vous ne pouvez pas acquérir un certificat SSL/TLS pour le domaine cloudapp.net (ou pour tout domaine lié à Azure). Le nom d’objet du certificat doit correspondre au nom de domaine personnalisé utilisé pour accéder à votre application. Par exemple, contoso.net, mais pas contoso.cloudapp.net.
Chiffrement à 2 048 bits au minimum.
Certificat de service uniquement : le certificat côté client doit résider dans le magasin de certificats personnel .
Vous disposez de deux méthodes simples pour créer un certificat sur Windows : avec l’utilitaire makecert.exe
ou avec IIS.
Makecert.exe
Cet utilitaire est mis hors service et n’est plus documenté ici. Pour plus d’informations, consultez cet article de Microsoft Developer Network (MSDN).
PowerShell
$cert = New-SelfSignedCertificate -DnsName yourdomain.cloudapp.net -CertStoreLocation "cert:\LocalMachine\My" -KeyLength 2048 -KeySpec "KeyExchange"
$password = ConvertTo-SecureString -String "your-password" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath ".\my-cert-file.pfx" -Password $password
Notes
Pour utiliser le certificat avec une adresse IP au lieu d’un domaine, utilisez l’adresse IP dans le paramètre -DnsName.
Si vous souhaitez utiliser ce certificat avec le portail de gestion, exportez-le vers un fichier .cer :
Export-Certificate -Type CERT -Cert $cert -FilePath .\my-cert-file.cer
Internet Information Services (IIS)
Il existe de nombreuses pages sur Internet qui aborde la création de certificats avec IIS, par exemple Quand utiliser un certificat auto-signé IIS.
Linux
Étapes rapides : créer et utiliser une paire de clés SSH publique et privée pour les machines virtuelles Linux dans Azure décrit la procédure de création de certificats avec SSH.
Étapes suivantes
Pour télécharger votre certificat de service sur le portail Azure.
Chargez un certificat d’API de gestion dans le portail Azure.