Azure Blob Storage
Como implantar automaticamente certificados SSL em um contêiner do Azure Blob Storage.
Visão geral
O AutoSSL pode enviar automaticamente arquivos de certificado SSL para um contêiner do Azure Blob Storage. Cada certificado fica arquivado em um caminho versionado e também é atualizado em um caminho latest/, para quem consome os arquivos (por exemplo, Nginx, Caddy ou scripts que baixam certificados do Blob Storage) encontrar a versão atual com facilidade.
Para gerenciar e executar esta implantação, consulte Gerenciamento de implantações.
Parâmetros de configuração
Ao adicionar ou editar este alvo no console do AutoSSL, configure os parâmetros abaixo:
| Parâmetro | Descrição | Exemplo |
|---|---|---|
| Nome da conta de armazenamento | O nome da conta de armazenamento do Azure que hospeda o contêiner de blobs. | mystorageaccount |
| Nome do contêiner | O nome do contêiner de blobs para o qual os arquivos de certificado serão enviados. | ssl-certs |
| Prefixo do nome do blob | (Opcional) Prefixo para organizar os arquivos de certificado no contêiner. Se informado, os arquivos ficam sob esse prefixo. A barra final é opcional. | certs/example.com/ |
Como funciona
Quando o AutoSSL implanta um certificado em um contêiner de blobs (por exemplo, conta de armazenamento mystorageaccount, contêiner ssl-certs, prefixo certs/example.com/), ele faz o seguinte:
-
Preparação do certificado:
- Separa a cadeia completa em arquivos PEM individuais:
cert.pem(certificado folha),privkey.pem(chave privada, codificada em PKCS#8),chain.pem(cadeia intermediária) efullchain.pem(cadeia completa). - Gera um arquivo
README.mdcom metadados do certificado e um link para https://autossl.dev, para rastreabilidade. - Lê a data
notBeforee a impressão digital SHA1 do certificado para montar o nome do diretório de arquivo (formato:YYYY-MM-DD_<first 8 chars of SHA1>).
- Separa a cadeia completa em arquivos PEM individuais:
-
Envio dos arquivos:
- Envia os arquivos de certificado (quatro arquivos PEM e o README.md) para dois caminhos no contêiner:
- Caminho de arquivo —
certs/example.com/2026-05-30_e5f6a7b8/cert.pem(eprivkey.pem,chain.pem,fullchain.pem,README.md). Esse caminho é único para cada emissão e nunca é sobrescrito. - Caminho latest —
certs/example.com/latest/cert.pem(eprivkey.pem,chain.pem,fullchain.pem,README.md). Esse caminho sempre aponta para o certificado enviado por último.
- Caminho de arquivo —
- Envia os arquivos de certificado (quatro arquivos PEM e o README.md) para dois caminhos no contêiner:
O caminho latest/ permite que os serviços seguintes busquem sempre o
certificado atual em um nome de blob fixo. Os certificados anteriores
continuam disponíveis nos diretórios versionados.
Exemplo de estrutura do contêiner
Depois de várias renovações, a estrutura do contêiner fica assim:
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.mdFormato da chave privada
privkey.pem usa o formato PKCS#8 (-----BEGIN PRIVATE KEY-----). Servidores e ferramentas modernos aceitam esse formato (Nginx, Caddy, Traefik, OpenSSL 1.1+ e outros).
Se o ambiente exigir PKCS#1 (por exemplo, -----BEGIN RSA PRIVATE KEY----- para chaves RSA), converta localmente antes de usar:
openssl rsa -in privkey.pem -out privkey-pkcs1.pemRequisitos da chave de acesso
Para usar o Azure Blob Storage, este provedor exige uma entidade de serviço do Azure.
Permissões necessárias
A entidade de serviço precisa ter permissão para criar e substituir blobs no contêiner de destino. Atribua o seguinte papel RBAC do plano de dados no escopo da conta de armazenamento ou do contêiner:
- Storage Blob Data Contributor (recomendado)
Papéis do plano de controle, como Storage Account Contributor, não
concedem permissão para enviar blobs. Se a implantação falhar com This request is not authorized to perform this operation, confira a atribuição do papel RBAC
e as configurações de firewall da conta de armazenamento abaixo.
Atribuir o papel RBAC
Conceder o papel no escopo do contêiner segue o princípio do menor privilégio:
- No portal do Azure, abra Storage Account → Containers → selecione o contêiner de destino.
- Vá em Access control (IAM) → Add role assignment.
- Na guia Role, selecione Storage Blob Data Contributor.
- Na guia Members:
- Defina Assign access to como User, group, or service principal.
- Clique em Select members.
- Pesquise pelo display name do registro do aplicativo (por exemplo,
AutoSSL) ou pelo Client ID. - Selecione o resultado cujo tipo é Application ou Service principal, e não uma conta de usuário.
- Revise e atribua.
Se o aplicativo não aparecer na busca, abra Microsoft Entra ID → Enterprise applications, defina Application type como All applications e confirme que a entidade de serviço existe. Entidades recém-criadas podem levar alguns minutos para aparecer na busca do IAM.
Para mais informações, consulte a documentação de controle de acesso do Azure Blob Storage.
Configurar o firewall da conta de armazenamento
O AutoSSL se conecta ao Blob Storage pela internet pública. Se a conta de armazenamento restringir o acesso à rede, as solicitações são bloqueadas mesmo quando o RBAC está correto.
- Abra Storage Account → Networking → Firewalls and virtual networks.
- Escolha uma das opções:
- Enabled from all networks: a opção mais simples para a configuração inicial e para testes.
- Enabled from selected networks: adicione os endereços IP de saída do AutoSSL em Address range.
- Salve as alterações e tente a implantação de novo.
Se a conta de armazenamento só for acessível por uma rede virtual ou por um ponto de extremidade privado, o AutoSSL não consegue alcançá-la pela internet pública, a menos que você encaminhe o tráfego por um caminho de rede compatível.