Sectigo Certificate as a Service (CaaS)

O protocolo ACME automatiza a comunicação relativa ao ciclo de vida de certificados entre uma Autoridade Certificadora (AC) — como a Sectigo — e os servidores web, sistemas de e-mail, dispositivos de usuário e demais pontos em que a organização utiliza certificados de infraestrutura de chaves públicas (PKI).

O protocolo envolve dois componentes:

Cliente ACME: Executado no servidor ou dispositivo que requer proteção por certificado. Responsável por solicitar as ações de emissão, renovação ou revogação.

Servidor ACME: Executado na Autoridade Certificadora. Responsável por responder às solicitações e executar as ações, uma vez autorizado o cliente.

A instalação e o uso de um cliente ACME exigem permissões suficientes para instalar e executar o cliente, acesso ao servidor web ou DNS e, em alguns casos, a possibilidade de reiniciar serviços.

Se esses pré-requisitos não puderem ser atendidos, então o CaaS (e qualquer CA via ACME) não será suportado nesse ambiente.

Atenção! A instalação do ACME no servidor é responsabilidade do cliente, por ser uma ferramenta de terceiros.

CERTIFY THE WEB: https://docs.certifytheweb.com/docs/intro/

CERTBOT: https://eff-certbot.readthedocs.io/en/stable/

CERT-MANAGER: https://cert-manager.io/docs/configuration/acme/

ACME-SH: https://github.com/acmesh-official/acme.sh

LEGO: https://go-acme.github.io/lego/

WIN-ACME: https://www.win-acme.com/manual/getting-started

DEHYDRATED: https://dehydrated.io/

POSH-ACME: https://poshac.me/docs/latest/

Entre em contato com nossa equipe para habilitar o CaaS e receber os dados necessários para configuração (incluindo credenciais EAB/ACME, quando aplicável) e orientações do processo.

O CaaS é comercializado como assinatura anual ou multianual (2 e 3 anos). O benefício do modelo CaaS não aumenta significativamente o custo anual equivalente de um certificado tradicional, e agrega previsibilidade e automação.

Após o início da assinatura (quando o primeiro FQDN é incluído), qualquer FQDN adicionado posteriormente é debitado do saldo proporcionalmente ao tempo restante até o fim da assinatura.

Exemplo prático (valores ilustrativos X e Y):

• Você adquire uma assinatura CaaS de 1 ano e adiciona um saldo inicial de R$ X .
• Configuramos a conta CaaS e enviamos as credenciais ACME ( EAB / MAC Key + Key ID/MAC ID ) para integração no seu ambiente.
• Ao solicitar o primeiro certificado — por exemplo, um CaaS Single Domain DV para www.dominio1.com.br — é debitado o valor integral do FQDN ( R$ Y ), pois ele marca o início da assinatura.
• Esse certificado pode ser reemitido automaticamente (ex.: a cada 90 dias) ou sob demanda, sem nova cobrança , até o término da vigência da assinatura.
• Algum tempo depois, você solicita um wildcard ( *.dominio1.com.br ), cujo valor cheio seria R$ Y .
• Como a assinatura já está em andamento, o débito do wildcard ocorre apenas pelo valor proporcional ao período restante (ex.: debitando somente os meses restantes até o fim do ano contratado).

Em resumo: o consumo ocorre quando um novo FQDN (ou wildcard) é incluído na assinatura — e não pela quantidade de emissões/reemissões realizadas.

Depende da forma como a assinatura for feita:

• Se *.empresa.com (wildcard) for adicionado à assinatura e depois empresa.com , será cobrado apenas o custo do wildcard. O www.empresa.com fica coberto pelo wildcard.
• Se empresa.com for adicionado à assinatura e depois www.empresa.com , será cobrado apenas o custo de um FQDN.

Mesmo com poucos certificados, o processo manual (copiar/colar CSR, executar validações e acompanhar vencimentos) gera esforço recorrente e risco de erro humano — especialmente com prazos de validade cada vez menores.

O CaaS oferece automação e previsibilidade, e a decisão normalmente depende do custo da assinatura versus o tempo/risco operacional que você deseja eliminar.

Os certificados SSL/TLS de 47 dias devem se tornar o novo padrão em 2029 .

A medida aprovada reduz gradualmente a validade máxima dos certificados de 398 dias para 47 dias em fases, com as seguintes datas de aplicação:

• 15 de março de 2026 : validade máxima reduzida para 200 dias
• 15 de março de 2027 : reduzida para 100 dias
• 15 de março de 2029 : aplicação final da validade máxima de 47 dias

Em geral, CAs privadas e certificados internos ficam fora do escopo dessas mudanças. Entretanto, alguns operadores de trust store (como a Apple) historicamente limitaram certificados TLS privados a 825 dias.

O ballot atual do CA/Browser Forum não cobre certificados privados. Como referência, o CaaS se aplica a certificados SSL/TLS publicamente confiáveis .

Os processos atuais de provisão de certificados permanecem inalterados. Quando prazos menores forem exigidos, isso será aplicado nos sistemas, da mesma forma que ocorreu na transição de certificados de 3 anos para 2 anos e depois 1 ano.

A organização precisa ser pré-validada e vinculada ao(s) domínio(s) corretos antes da emissão do certificado.

Uma vez validada, a solicitação de certificado OV resultará na emissão do certificado contendo os dados organizacionais pré-validados, para o(s) domínio(s) solicitado(s), após a conclusão da validação de domínio (DCV).

Isso permite emitir uma quantidade ilimitada de certificados OV com os dados da organização pré-validada durante o período de assinatura.

Sim. Os certificados TLS emitidos via CaaS podem incluir domínios wildcard.

O ACME oferece diferentes métodos de validação de domínio. A Sectigo suporta:

• DNS via dns-01
• HTTP via http-01

O protocolo ACME não suporta validação por e-mail, pois não é automatizável.

A comunicação entre o cliente ACME e o servidor ACME segue o protocolo ACME documentado na RFC 8555:

https://datatracker.ietf.org/doc/html/rfc8555