Administradores que chegam ao AD Certificate Services no Windows Server 2019 frequentemente esbarram em um obstáculo: “Como assinar um CSR gerado manualmente, sem modelo, usando a própria Enterprise CA?” A frustração aumenta quando o assistente — ou o certreq — insiste em anexar um Certificate Template e ainda substitui parâmetros do pedido, impedindo cenários como combinar Key Agreement + Key Encipherment com uma única chave ECC/ECDH. A boa notícia é que o problema tem explicação (e caminho de solução) clara, que exploraremos neste artigo completo.
Entendendo a lógica de templates no AD CS
No universo Microsoft, uma Enterprise CA depende de objetos Certificate Template armazenados no Active Directory. Esses objetos funcionam como “receitas” de emissão, definindo:
- Compatibilidade de versão (Windows XP, 2008, 2016…)
- Tipo de chave e tamanho
- Extensões: Key Usage, Extended Key Usage, políticas e restrições de nome
- Opções de inscrição (manual, automática, sujeita a aprovação etc.)
- Permissões de segurança (quem pode solicitar, renovar ou ler chaves privadas em HSM)
Quando um CSR chega à CA, o Policy Module verifica de qual template ele “herdou” as configurações. Se houver conflito — por exemplo, o template exige RSA 2048 e o CSR traz ECC P‑384 — a instância de CA substitui o campo problemático ou recusa a emissão. Essa é a causa do “apagão” que o iniciante vê quando tenta impor parâmetros customizados.
Por que a CA não aceita “template = none”?
Em Enterprise mode, o design da Microsoft prioriza governança e automação. Apenas Standalone CAs (ou soluções externas como OpenSSL) aceitam CSRs arbitrários. A Enterprise CA só opera via template por questões de:
- Conformidade regulatória (auditoria simplificada)
- Autoinscrição para estações e usuários de domínio
- Gerenciamento central (“um template para governar todos”)
Limitações criptográficas: ECDH ≠ Key Encipherment
Outro ponto de discórdia é a combinação Key Agreement + Key Encipherment em uma mesma chave ECC. No motor de criptografia da Microsoft, ECDH é destinado estritamente a acordo de chaves (Key Agreement); já a função de cifrar chaves simétricas (Key Encipherment) é associada a algoritmos como RSA ou ECIES. Na prática:
| Algoritmo | Uso Principal | Key Usage compatível |
|---|---|---|
| ECDH (ECC) | Troca de segredo compartilhado | Key Agreement |
| ECDSA (ECC) | Assinatura digital | Digital Signature, Non‑Repudiation |
| RSA | Assinatura e criptografia de chave | Key Encipherment, Data Encipherment, Digital Signature |
Na tentativa de empurrar dois Key Usages incompatíveis para o mesmo par de chaves ECC, o motor simplesmente descarta um deles ou emite erro. Portanto, mesmo que você crie um template personalizado, ainda não conseguirá estampar Key Encipherment na linha de Key Usage se o pedido for ECDH.
Estratégia recomendada: criar um template sob medida
Se o objetivo for operar dentro da Enterprise CA, a abordagem oficial é:
- Abra Certtmpl.msc em um controlador de domínio.
- Copie um template semelhante (User, Workstation Authentication, Computer…) e atribua um nome distinto, como “ECC‑ECDH‑Agreement”.
- Na aba General, defina versões de compatibilidade (Windows Server 2016 ou superior para suportar ECC P‑384).
- Na aba Cryptography, escolha Key Storage Provider = Microsoft Software KSP ou o KSP do HSM, selecione Curve P‑384 (ou P‑256/P‑521 conforme política).
- Na aba Extensions, edite Key Usage deixando apenas Key Agreement; marque Make the key exportable se necessário.
- Configure Security para conceder Enroll ou Autoenroll aos grupos/usuários corretos.
- Salve, depois abra Certification Authority > Certificate Templates, clique direito > New > Certificate Template to Issue e publique seu novo template.
- Por fim, reemita o CSR usando
certreq –submit –attrib "CertificateTemplate: ECC-ECDH-Agreement"ou inscreva diretamente via MMC.
Embora pareça burocrático, essa rota garante que sua PKI permaneça consistente e auditável. E, claro, você evita que a CA “pise” nos parâmetros, pois agora o template já fala a mesma língua do CSR.
Quando (e como) usar uma Standalone CA
Há cenários legítimos — laboratórios, dispositivos IoT fora de domínio, integrações com sistemas legados — em que cada CSR é uma história diferente. Se a flexibilidade é crítica, considere:
- Instalar uma Standalone Root CA em vez de Enterprise, ou converter (desativar, reinstalar, importar chave privada e base de dados).
- Manter a Standalone offline (melhor prática para Roots) e delegar a emissão diária a uma SubCA Enterprise com templates estritos.
- Usar
certreq –policye arquivos CAPolicy.inf/Policy.inf para validar requisitos mínimos (p. ex., curva permitida, tamanho de chave RSA, tempos de validade). - Optar por ferramentas como OpenSSL ou CFSSL caso a infra‑estrutura Microsoft imponha barreiras impossíveis.
A tabela a seguir resume as diferenças:
| Característica | Enterprise CA | Standalone CA |
|---|---|---|
| Integração AD | Automática (autoenroll, pesquisa CRL/AIA via LDAP) | Nenhuma |
| Necessidade de Template | Obrigatório | Opcional |
| Governança / Auditoria | Nativa | Requer processos externos |
| Complexidade de instância | Alta (dependências de Schema, Cert Templates, GPOs) | Baixa |
| Casos de uso ideais | Domínio corporativo | PKI offline, laboratórios, dispositivos heterogêneos |
Estratégias para quem precisa de Key Encipherment
Digamos que a sua aplicação exige cifrar segredos (Key Encipherment) e você quer permanecer em ECC por questões de performance ou política pós‑quântica. Você tem três alternativas realistas:
- Separar funções: use dois certificados — um ECC/ECDH para acordo de chaves, outro RSA 2048+ para Key Encipherment. Aplicações TLS modernas lidam bem com cadeias múltiplas ou SNI.
- Migrar para ECIES (ou híbridos X25519+ChaCha20‑Poly1305): porém, o stack Microsoft ainda não oferece suporte nativo em certificados X.509.
- Persistir em RSA até que a Microsoft implemente Key Encipherment para ECIES ou similar. Não há vergonha em usar um algoritmo veterano que continua eficaz.
Boas práticas adicionais
- Verifique o CSR antes de submeter:
certutil –dump pedido.csr. - Audite templates:
certutil –templatelista GUID, V‑number e permissões de cada um. - Use NotBefore/NotAfter realistas: evitar certificados de 10 anos em produção.
- Configure seus caminhos de distribuição: CRL (<HTTP>) e AIA (“.crt” do emissor) publicados em URLs acessíveis.
- Proteja a CA Root — idealmente desligada, atrás de cofres físicos, com HSM FIPS 140‑2 Nível 3.
FAQ rápido
Posso simplesmente editar o CSR manualmente para apontar para o template?
Não. O campo CertificateTemplate existe no Certificate Extension do tipo 1.3.6.1.4.1.311.21.7, mas acrescentá‑lo a mão não dribla as demais checagens do Policy Module.
E se eu usar Subordinate CA em modo Standalone e publicar certificados no AD?
Funciona, mas você perde a autoinscrição. Ainda assim, graças ao atributo crossCertDistPoints, máquinas Windows podem localizar cadeias híbridas (standalone→enterprise) desde que as CRLs estejam acessíveis.
Quero ECDSA + Key Encipherment, é permitido?
ECDSA é algoritmo de assinatura. Mesmo dilema: Key Encipherment não se aplica. Combine ECDSA (assinatura) com RSA (cifra) ou use TLS com curvas de acordo de chave separadas.
Resumo
Em uma Enterprise CA do Windows Server 2019, não é possível emitir certificados sem template nem combinar Key Agreement e Key Encipherment em um único certificado ECC/ECDH. Se a flexibilidade total for indispensável, migre (ou crie em paralelo) uma Standalone CA. Caso contrário, a estratégia oficial consiste em:
- Copiar um template existente
- Ajustar curva, Key Usage e permissões
- Publicar o novo template
- Submeter o CSR apontando explicitamente para esse template
Assim você mantém a conformidade da PKI, atende aos requisitos de negócio e evita surpresas indesejadas na emissão de certificados.