AutoSSL
Certificat de déploiement

Azure Blob Storage

Comment déployer automatiquement des certificats SSL vers un conteneur Azure Blob Storage.

Vue d’ensemble

AutoSSL peut envoyer automatiquement les fichiers de certificat SSL vers un conteneur Azure Blob Storage. Chaque certificat est archivé dans un chemin versionné et mis à jour sous un chemin latest/, afin que les services en aval le trouvent facilement (par exemple Nginx, Caddy ou des scripts qui récupèrent les certificats depuis Blob Storage).

Pour gérer et lancer ce déploiement, consultez la section Gestion des déploiements.

Paramètres de configuration

Lorsque vous ajoutez ou modifiez cette cible de déploiement dans la console AutoSSL, renseignez les paramètres suivants :

ParamètreDescriptionExemple
Nom du compte de stockageNom du compte de stockage Azure qui héberge le conteneur de blobs.mystorageaccount
Nom du conteneurNom du conteneur de blobs vers lequel envoyer les fichiers de certificat.ssl-certs
Préfixe du nom de blob(Facultatif) Préfixe pour ranger les fichiers de certificat dans le conteneur. S’il est défini, les fichiers sont envoyés sous ce préfixe. La barre oblique finale est facultative.certs/example.com/

Fonctionnement

Lorsque AutoSSL déploie un certificat vers un conteneur de blobs (par exemple le compte de stockage mystorageaccount, le conteneur ssl-certs et le préfixe certs/example.com/), il procède ainsi :

  1. Préparation du certificat :

    • Découpe la chaîne complète en fichiers PEM distincts : cert.pem (certificat feuille), privkey.pem (clé privée encodée en PKCS#8), chain.pem (chaîne intermédiaire) et fullchain.pem (chaîne complète).
    • Génère un fichier README.md avec les métadonnées du certificat et un lien vers https://autossl.dev, pour pouvoir le retrouver.
    • Lit la date notBefore et l’empreinte SHA1 du certificat afin de nommer le répertoire d’archive (format : YYYY-MM-DD_<first 8 chars of SHA1>).
  2. Envoi des fichiers :

    • Envoie les fichiers du certificat (quatre fichiers PEM et README.md) vers deux chemins dans le conteneur :
      • Chemin d’archive — certs/example.com/2026-05-30_e5f6a7b8/cert.pem (ainsi que privkey.pem, chain.pem, fullchain.pem et README.md). Ce chemin est propre à chaque émission et n’est jamais écrasé.
      • Chemin latest — certs/example.com/latest/cert.pem (ainsi que privkey.pem, chain.pem, fullchain.pem et README.md). Ce chemin correspond toujours au dernier certificat envoyé.

Le chemin latest/ permet aux services en aval de toujours récupérer le certificat courant depuis un nom de blob fixe. Les certificats précédents restent accessibles dans leurs répertoires d’archive versionnés.

Exemple de structure du conteneur

Après plusieurs renouvellements, la structure ressemble à ceci :

certs/example.com/
├── 2026-03-01_a1b2c3d4/
│   ├── cert.pem
│   ├── privkey.pem
│   ├── chain.pem
│   ├── fullchain.pem
│   └── README.md
├── 2026-05-30_e5f6a7b8/
│   ├── cert.pem
│   ├── privkey.pem
│   ├── chain.pem
│   ├── fullchain.pem
│   └── README.md
└── latest/
    ├── cert.pem
    ├── privkey.pem
    ├── chain.pem
    ├── fullchain.pem
    └── README.md

Format de clé privée

privkey.pem est encodé au format PKCS#8 (-----BEGIN PRIVATE KEY-----). Les serveurs et outils récents le prennent en charge (Nginx, Caddy, Traefik, OpenSSL 1.1+, etc.).

Si votre environnement exige le format PKCS#1 (par exemple -----BEGIN RSA PRIVATE KEY----- pour une clé RSA), convertissez-le localement avant de l’utiliser :

openssl rsa -in privkey.pem -out privkey-pkcs1.pem

Clé d’accès requise

Pour accéder à Azure Blob Storage, ce fournisseur exige un principal de service Azure.

Autorisations requises

Le principal de service doit pouvoir créer et remplacer des blobs dans le conteneur cible. Attribuez le rôle RBAC de plan de données suivant, à l’échelle du compte de stockage ou du conteneur :

  • Storage Blob Data Contributor (recommandé)

Les rôles de plan de contrôle, comme Storage Account Contributor, ne donnent pas le droit d’envoyer des blobs. Si le déploiement échoue avec This request is not authorized to perform this operation, vérifiez à la fois l’attribution du rôle RBAC et le pare-feu du compte de stockage, décrits ci-dessous.

Attribuer le rôle RBAC

Attribuer le rôle à l’échelle du conteneur respecte le principe du moindre privilège :

  1. Dans le portail Azure, ouvrez votre compte de stockage → Conteneurs → sélectionnez le conteneur cible.
  2. Allez dans Contrôle d’accès (IAM) → Ajouter une attribution de rôle.
  3. Sous l’onglet Rôle, choisissez Storage Blob Data Contributor.
  4. Sous l’onglet Membres :
    • Réglez Attribuer l’accès à sur Utilisateur, groupe ou principal de service.
    • Cliquez sur Sélectionner des membres.
    • Recherchez le nom d’affichage de l’inscription d’application (par exemple AutoSSL) ou l’ID client.
    • Sélectionnez le résultat de type Application ou Principal de service, et non un compte d’utilisateur.
  5. Vérifiez, puis attribuez le rôle.

Si l’application n’apparaît pas dans les résultats, ouvrez Microsoft Entra ID → Applications d’entreprise, réglez Type d’application sur Toutes les applications et confirmez que le principal de service existe. Un principal tout juste créé peut mettre quelques minutes à apparaître dans la recherche IAM.

Pour en savoir plus, consultez la documentation sur le contrôle d’accès d’Azure Blob Storage.

Configurer le pare-feu du compte de stockage

AutoSSL se connecte à Blob Storage via l’Internet public. Si le compte de stockage restreint l’accès réseau, les requêtes sont bloquées même lorsque le rôle RBAC est correct.

  1. Ouvrez votre compte de stockage → Mise en réseau → Pare-feu et réseaux virtuels.
  2. Choisissez l’une des options suivantes :
    • Activé à partir de tous les réseaux — le plus simple pour un premier essai.
    • Activé à partir de réseaux sélectionnés — ajoutez la ou les adresses IP de sortie d’AutoSSL dans Plage d’adresses.
  3. Enregistrez, puis relancez le déploiement.

Si le compte de stockage n’est accessible que par un réseau virtuel ou un point de terminaison privé, AutoSSL ne peut pas l’atteindre depuis l’Internet public, sauf si vous faites passer le trafic par un chemin réseau compatible.

Azure Blob Storage | AutoSSL