Azure Blob Storage

Overview

AutoSSL can automatically upload SSL certificate files to an Azure Blob Storage container. Each certificate is archived under a versioned archive path and also updated under a latest/ path for easy discovery by downstream consumers (e.g., Nginx, Caddy, or custom scripts that pull certificates from Blob Storage).

For instructions on how to manage and run this deployment, please refer to the Deployment Management section.

Configuration Parameters

When you add or edit this deployment target in the AutoSSL console, you will need to configure the following parameters:

How it Works

When AutoSSL deploys a certificate to a blob container (e.g., storage account mystorageaccount, container ssl-certs, prefix certs/example.com/), it performs the following steps:

1. Certificate Preparation:

   • Splits the full certificate chain into individual PEM files: cert.pem (leaf certificate), privkey.pem (private key, PKCS#8 encoded), chain.pem (intermediate chain), and fullchain.pem (full chain).
   • Generates a README.md file with certificate metadata and a link to https://autossl.dev for traceability.
   • Parses the certificate notBefore date and SHA1 fingerprint to generate an archive directory name (format: YYYY-MM-DD_<first 8 chars of SHA1>).

2. File Upload:

   • Uploads certificate files (four PEM files and README.md) to two paths in the container:
     • Archive path — certs/example.com/2026-05-30_e5f6a7b8/cert.pem (and privkey.pem, chain.pem, fullchain.pem, README.md). This path is unique per certificate issuance and is never overwritten.
     • Latest path — certs/example.com/latest/cert.pem (and privkey.pem, chain.pem, fullchain.pem, README.md). This path always reflects the most recently uploaded certificate.

Example Container Structure

After multiple certificate renewals, your container structure will look like this:

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

Private Key Format

privkey.pem is encoded in PKCS#8 format (-----BEGIN PRIVATE KEY-----). This format is widely supported by modern web servers and tools (Nginx, Caddy, Traefik, OpenSSL 1.1+, etc.).

If your environment requires PKCS#1 format (e.g. -----BEGIN RSA PRIVATE KEY----- for RSA keys), convert it locally before use:

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

Access Key Requirement

Required Permissions

The service principal must have permission to create and overwrite blobs in the target container. Assign the following data plane RBAC role at the storage account or container scope:

• Storage Blob Data Contributor (recommended)

Assign the RBAC Role

Granting the role at the container scope follows the principle of least privilege:

1. In the Azure Portal, open your Storage Account → Containers → select the target container.
2. Go to Access control (IAM) → Add role assignment.
3. On the Role tab, select Storage Blob Data Contributor.
4. On the Members tab:
   • Set Assign access to to User, group, or service principal.
   • Click Select members.
   • Search by your app registration display name (e.g., AutoSSL) or Client ID.
   • Select the result whose type is Application or Service principal — not a user account.
5. Review and assign.

For more information, refer to the Azure Blob Storage access control documentation.

Configure Storage Account Firewall

AutoSSL connects to Blob Storage over the public internet. If the storage account restricts network access, requests are blocked even when RBAC is configured correctly.

1. Open your Storage Account → Networking → Firewalls and virtual networks.
2. Choose one of the following:
   • Enabled from all networks — simplest for initial setup and testing.
   • Enabled from selected networks — add AutoSSL's outbound IP address(es) under Address range.
3. Save the changes and retry the deployment.