Diretrizes de autoridade de certificação

 

Aplica-se a: Windows Server 2012 R2, Windows Server 2012

Uma AC (autoridade de certificação) é responsável por atestar a identidade de usuários, computadores e organizações. A AC autentica uma entidade e garante-a emitindo um certificado assinado digitalmente. A AC também pode gerenciar, revogar e renovar certificados.

Uma autoridade de certificação pode se referir ao seguinte:

  • Uma organização que garante a identidade de um usuário final

  • Um servidor usado pela organização para emitir e gerenciar certificados

Instalando o serviço de função Autoridade de Certificação do AD CS (Serviços de Certificados do Active Directory), você pode configurar seu Windows Server para atuar como uma AC.

Antes de instalar o serviço de função AC, você deve:

  1. Planejar uma PKI (infraestrutura de chave pública) apropriada para sua organização.

  2. Instalar e configurar um HSM (módulo de segurança de hardware) de acordo com as instruções do fornecedor de HSM, caso você esteja planejando usá-lo.

  3. Criar um CAPolicy.inf apropriado, caso queira modificar as configurações de instalação padrão.

Planejar para a PKI

Para assegurar que sua organização possa aproveitar totalmente a instalação do AD CS (Serviços de Certificados do Active Directory), você deve planejar a implantação da PKI adequadamente. Antes de instalar a AC, você deve determinar quantas ACs você instalará e em qual configuração. Criar um design de PKI apropriado pode ser demorado, mas é importante para o sucesso da PKI.

Para obter mais informações e recursos, consulte PKI Design Guidance (Diretrizes de design de PKI) no Microsoft TechNet.

Usar um HSM

O uso de um HSM (Módulo de Segurança de Hardware) pode aprimorar a segurança da AC e da PKI.

O HSM é um dispositivo de hardware dedicado gerenciado separadamente do sistema operacional. Esses módulos oferecem um repositório de hardware seguro para as chaves de AC, além de um processador criptográfico dedicado para acelerar as operações de assinatura e criptografia. O sistema operacional utiliza o HSM por meio de interfaces CryptoAPI e as funções do HSM como um dispositivo CSP (provedor de serviços de criptografia).

Normalmente, os HSMs são adaptadores PCI, mas também estão disponíveis como dispositivos baseados em rede, dispositivos seriais e dispositivos USB. Se uma organização planeja implementar duas ou mais ACs, você pode instalar um HSM individual baseado na rede e compartilhá-lo entre as várias ACs.

Para configurar uma AC usando um HSM, o HSM deve ser instalado e configurado antes da configuração de qualquer AC com as chaves que serão armazenadas no HSM.

Considerar um arquivo CAPolicy.inf

O arquivo CAPolicy.inf não é exigido para instalar o AD CS, mas pode ser usado para personalizar as configurações da AC. O arquivo CAPolicy.inf contém várias configurações usadas na instalação de uma AC ou na revisão do certificado de Autoridade de Certificação. O arquivo CAPolicy.inf deve ser criado e armazenado no diretório %systemroot% (tipicamente C:\Windows) para que seja usado.

As configurações incluídas no arquivo CAPolicy.inf dependem muito do tipo de implantação que você deseja criar. Por exemplo, uma AC raiz poderá ter um arquivo CAPolicy.inf semelhante a isto:

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

Já o arquivo CAPolicy.inf para uma empresa que está emitindo uma AC poderá ser semelhante a isto:

[Version]
Signature= "$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy]
OID = 1.1.1.1.1.1.1.1.1
URL = "https://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy]
OID = 2.2.2.2.2.2.2.2.2
URL = "https://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"
LoadDefaultTemplates=0

Dica

  1. Os OIDs (identificadores de objeto) mostrados no CAPolicy.inf de amostra são apenas exemplos. Cada organização deve obter seu próprio OID. Para obter mais informações sobre OIDs, consulte Obtaining a Root OID from an ISO Name Registration Authority (Obtendo um OID raiz de uma autoridade de registro de nome ISO).

  2. Para obter mais informações, consulte CAPolicy.inf Syntax (Sintaxe CAPolicy.inf).

Selecionar definições de configuração da AC

As seções a seguir descrevem as opções de configuração que você selecionará depois de instalar os arquivos binários de instalação da AC.

Selecionar tipo de instalação

As ACs corporativas são integradas ao AD DS (Serviços de Domínio Active Directory). Elas publicam certificados e CRLs (listas de certificados revogados) no AD DS. As ACs corporativas usam informações armazenadas no AD DS, inclusive contas de usuário e grupos de segurança, para aprovar ou negar as solicitações de certificado. As ACs corporativas usam modelos de certificado. Quando um certificado é emitido, a AC corporativa usa informações do modelo de certificado para gerar um certificado com os atributos apropriados para aquele tipo de certificado.

Se você quiser habilitar a aprovação automática de certificados e o registro automático de certificados de usuário, use ACs corporativas para emitir certificados. Esses recursos são disponibilizados apenas quando a infraestrutura de AC está integrada ao Active Directory. Além disso, apenas ACs corporativas podem emitir certificados que habilitem o logon do cartão inteligente, pois esse processo exige que os certificados do cartão inteligente sejam mapeados automaticamente para as contas de usuário do Active Directory.

Dica

Por padrão, você deve ser membro do grupo Administradores de Empresa e instalar e configurar uma AC corporativa. Se você quiser que um administrador de domínio com poucos privilégios instale e configure uma AC corporativa, consulte Instalação delegada para uma autoridade de certificação corporativa.

ACs autônomas não exigem o AD DS e não usam modelos de certificado. Se você usa ACs autônomas, todas as informações sobre o tipo de certificado solicitado devem ser incluídas na solicitação de certificado. Por padrão, todas as solicitações de certificado enviadas a ACs autônomas são mantidas em uma fila pendente até que sejam aprovadas por um administrador de AC. Você pode configurar ACs autônomas para emitir certificados automaticamente mediante solicitação, mas isso é menos seguro e, normalmente, não é recomendável porque as solicitações não são autenticadas.

Sob a perspectiva do desempenho, o uso de ACs autônomas com emissão automática permite emitir certificados a uma velocidade mais rápida em comparação à de ACs corporativas. No entanto, exceto se você estiver usando emissão automática, o uso de ACs autônomas para emitir grandes volumes de certificados normalmente gera um alto custo administrativo, pois um administrador deve revisar manualmente e, em seguida, aprovar ou negar cada solicitação de certificado. Por esse motivo, as ACs autônomas são mais eficientes com aplicativos de segurança de chave pública em extranets e na Internet, quando os usuários não têm contas de usuário e o volume de certificados a ser emitido e gerenciado é relativamente pequeno

Você deve usar ACs autônomas para emitir certificados quando está usando um serviço de diretório não pertencente à Microsoft ou quando o AD DS não está disponível. Você pode usar autoridades de certificação corporativas e autônomas na sua organização, conforme explicado na tabela a seguir.

Opção

AC corporativa

AC autônoma

Publica certificados no Active Directory e usa o Active Directory para validar solicitações de certificado.

Sim

Não

Colocar a AC offline.

Não recomendável

Sim

Configurar a AC para emitir certificados automaticamente.

Sim

Não recomendável

Permitir que administradores aprovem solicitações de certificado manualmente.

Sim

Sim

Permitir o uso de modelos de certificado.

Sim

Não

Autenticar solicitações no Active Directory.

Sim

Não

Escolher tipo de AC

ACs corporativas e autônomas podem ser configuradas como ACs raiz ou ACs subordinadas. As ACs subordinadas podem ainda ser configuradas como ACs intermediárias (também chamadas de AC de política) ou ACs emissoras

Designar uma AC raiz

Uma AC raiz é aquela que está no topo da hierarquia de certificação. Ela deve ser incondicionalmente confiável para os clientes da sua organização. Todas as cadeias de certificados terminam em uma AC raiz. Seja usando ACs corporativas ou autônomas, você deve designar uma AC raiz.

Como a AC raiz está no topo da hierarquia de certificação, o campo Entidade do certificado que é emitido por uma AC raiz tem o mesmo valor do campo Emissor do certificado. Da mesma forma, como a cadeia de certificados termina quando chega a uma AC autoassinada, todas as ACs autoassinadas são ACs raiz. A decisão de designar uma AC como AC raiz confiável pode ser tomada no nível corporativo ou localmente pelo administrador de TI individual.

Uma AC raiz serve como uma base sobre a qual você fundamenta seu modelo de confiança da autoridade de certificação. Ela garante que a chave pública da entidade corresponda às informações de identidade mostradas no campo de entidade dos certificados emitidos. ACs diferentes também podem verificar essa relação usando padrões diferentes. Portanto, é importante entender as políticas e os procedimentos da autoridade de certificação raiz antes de optar por confiar na autoridade para verificar as chaves públicas.

A AC raiz é a mais importante da sua hierarquia. Se a AC raiz estiver comprometida, todas as ACs da hierarquia e todos os certificados emitidos por ela serão considerados comprometidos. Você pode maximizar a segurança da AC raiz mantendo-a desconectada da rede e usando ACs subordinadas para emitir certificados a outras ACs subordinadas ou a usuários finais.

ACs subordinadas

As ACs que não são raiz são consideradas subordinadas. A primeira AC subordinada de uma hierarquia obtém seu Certificado de Autoridade de Certificação da AC raiz. Essa primeira AC subordinada pode usar essa chave para emitir certificados que verifiquem a integridade de outra AC subordinada. Essas ACs subordinadas superiores são conhecidas como ACs intermediárias. Uma AC intermediária é subordinada a uma AC raiz, mas serve como autoridade certificadora superior para uma ou mais ACs subordinadas.

A AC intermediária também é conhecida como AC de política, pois ela é normalmente usada para separar classes de certificados que podem ser distinguidas por políticas. Por exemplo, a separação de política abrange o nível de garantia que a AC oferece ou a localização geográfica da AC para distinguir diferentes populações de entidades finais. A AC de política pode estar online ou offline.

Aviso

Não é possível converter uma AC raiz em uma AC subordinada ou vice-versa.

Armazenar uma chave privada

A chave privada faz parte da identidade da AC e deve ser protegida para não ser comprometida. Muitas organizações protegem chaves privadas de AC usando um HSM. Se um HSM não for usado, a chave privada será armazenada no computador da AC. Para obter mais informações, consulte Hardware Security Module (HSM) (Módulo de Segurança de Hardware (HSM)) no Microsoft TechNet.

As ACs offline devem ser armazenadas em locais seguros e não conectados à rede. As ACs emissoras usam as próprias chaves privadas ao emitir certificados. Portanto, a chave privada deve estar acessível (online) enquanto a AC está em operação. Em todos os casos, a AC e sua chave privada devem ser protegidas fisicamente.

Localizar uma chave existente

Se já tiver uma chave privada existente que deseja usar durante a instalação, você poderá usar a tela Chave Existente para localizá-la. Você pode usar o botão Alterar para modificar o provedor criptográfico e, opcionalmente, a AC que deseja pesquisar para obter a chave existente.

Localizar um certificado existente

Se já tiver um certificado que contenha a chave privada da AC, você poderá usar a tela Certificado Existente para localizá-lo. Você pode usar o botão Importar para abrir a caixa de diálogo Importar Certificado Existente e, em seguida, localizar o arquivo PKCS #12 existente.

Selecionar opções criptográficas

A seleção de opções criptográficas para uma AC pode gerar implicações significativas de segurança, desempenho e compatibilidade para a AC. Embora as opções criptográficas padrão possam ser adequadas à maioria das ACs, a capacidade de implementar opções personalizadas pode ser útil a administradores e desenvolvedores de aplicativos com uma compreensão mais avançada de criptografia e a necessidade de obter flexibilidade. As opções criptográficas podem ser implementadas usando CSPs ou KSPs (provedores de armazenamento de chaves).

Importante

Ao usar um certificado RSA para uma AC, verifique se o comprimento da chave é de, pelo menos, 2.048 bits. Você não deve tentar usar um certificado RSA com menos de 1.024 bits para a AC. O serviço da AC (certsvc) não será iniciado se uma chave RSA inferior a 1.024 bits estiver instalada.

CSPs são componentes de hardware e software dos sistemas operacionais Windows que oferecem funções genéricas de criptografia. CSPs podem ser gravados para que forneçam vários algoritmos de assinatura e criptografia.

Os KSPs podem fornecer proteção de chave de alta segurança para computadores que executam uma versão de servidor mínima do Windows Server 2008 R2 e uma versão mínima de cliente do Windows Vista.

Importante

Ao selecionar o provedor, o algoritmo de hash e o comprimento da chave, considere com atenção as opções criptográficas às quais os aplicativos e dispositivos que você pretende usar dão suporte. Embora seja uma prática recomendada selecionar as opções de segurança mais fortes, nem todos os aplicativos e dispositivos dão suporte a elas.

Se os seus requisitos de suporte mudarem e você puder usar as opções de segurança mais fortes, como migrar para um KSP e um algoritmo de hash mais forte, consulte Migrando uma chave de autoridade de certificação de um CSP (provedor de serviços de criptografia) para um KSP (provedor de armazenamento de chaves).

Permitir a interação do administrador quando a chave privada é acessada pela AC é uma opção tipicamente usada com HSMs. Isso permite que o provedor criptográfico solicite ao usuário autenticação adicional quando a chave privada da AC for acessada. Essa opção pode ser usada para ajudar a impedir o uso não aprovado da AC e de sua chave privada ao exigir que o administrador insira uma senha antes de cada operação criptográfica.

Os provedores criptográficos internos dão suporte a tamanhos de chave e algoritmos de hash específicos, conforme descrito na tabela a seguir.

Provedor criptográfico

Comprimentos de chave

Algoritmo de hash

Microsoft Base Cryptographic Provider v1.0

  • 512

  • 1024

  • 2048

  • 4096

  • SHA1

  • MD2

  • MD4

  • MD5

Microsoft Base DSS Cryptographic Provider

  • 512

  • 1024

SHA1

Microsoft Base Smart Card Crypto Provider

  • 1024

  • 2048

  • 4096

  • SHA1

  • MD2

  • MD4

  • MD5

Microsoft Enhanced Cryptographic Provider v1.0

  • 512

  • 1024

  • 2048

  • 4096

  • SHA1

  • MD2

  • MD4

  • MD5

Microsoft Strong Cryptographic Provider

  • 512

  • 1024

  • 2048

  • 4096

  • SHA1

  • MD2

  • MD4

  • MD5

RSA#Microsoft Software Key Storage Provider

  • 512

  • 1024

  • 2048

  • 4096

  • SHA1

  • SHA256

  • SHA384

  • SHA512

  • MD2

  • MD4

  • MD5

DSA#Microsoft Software Key Storage Provider

  • 512

  • 1024

  • 2048

SHA1

ECDSA_P256#Microsoft Software Key Storage Provider

256

  • SHA1

  • SHA256

  • SHA384

  • SHA512

ECDSA_P384#Microsoft Software Key Storage Provider

384

  • SHA1

  • SHA256

  • SHA384

  • SHA512

ECDSA_P521#Microsoft Software Key Storage Provider

521

  • SHA1

  • SHA256

  • SHA384

  • SHA512

RSA#Microsoft Smart Card Key Storage Provider

  • 1024

  • 2048

  • 4096

  • SHA1

  • SHA256

  • SHA384

  • SHA512

  • MD2

  • MD4

  • MD5

ECDSA_P256#Microsoft Smart Card Key Storage Provider

256

  • SHA1

  • SHA256

  • SHA384

  • SHA512

ECDSA_P384#Microsoft Smart Card Key Storage Provider

384

  • SHA1

  • SHA256

  • SHA384

  • SHA512

ECDSA_P521#Microsoft Smart Card Key Storage Provider

521

  • SHA1

  • SHA256

  • SHA384

  • SHA512

Estabelecer um nome da Autoridade de Certificação

Antes de configurar as ACs de sua organização, você deve estabelecer uma convenção de denominação da Autoridade de Certificação.

Você pode criar um nome usando qualquer caractere Unicode, mas talvez você queira usar o conjunto de caracteres ANSI se precisar obter interoperabilidade. Por exemplo, certos tipos de roteadores não serão capazes de usar o Serviço de Registro de Dispositivo de Rede para registrar certificados se o nome da Autoridade de Certificação contiver caracteres especiais, como um sublinhado.

Importante

Se você usar caracteres não latinos (como cirílicos, arábicos ou chineses), o nome da Autoridade de Certificação deverá conter menos de 64 caracteres. Se você usar apenas caracteres não latinos, o nome da Autoridade de Certificação não poderá ultrapassar o comprimento de 37 caracteres.

No AD DS (Serviços de Domínio Active Directory), o nome que você especifica ao configurar um servidor como AC se torna o nome comum da AC, que é refletido em todos os certificados emitidos pela AC. Por esse motivo, é importante não usar o nome de domínio totalmente qualificado para o nome comum da AC. Dessa forma, usuários mal-intencionados que obtêm uma cópia de um certificado não podem identificar e usar o nome de domínio totalmente qualificado da AC para criar uma potencial vulnerabilidade de segurança.

Aviso

O nome da Autoridade de Certificação não deve ser idêntico ao nome do computador (nome NetBIOS ou DNS). Além disso, não é possível alterar o nome de um servidor depois que o AD CS (Serviços de Certificados do Active Directory) é instalado sem invalidar todos os certificados emitidos pela AC. Para obter considerações adicionais relacionadas a nomes da Autoridade de Certificação, consulte o artigo do wiki da TechNet: Considerations for Certification Authority (CA) Names (Considerações sobre nomes da AC (Autoridade de Certificação)).

Para alterar o nome do servidor depois que o AD CS é instalado, você deve desinstalar a AC, alterar o nome do servidor, reinstalar a AC usando as mesmas chaves e modificar o registro para usar as chaves e o banco de dados da AC existentes. Não será preciso reinstalar a AC ao renomear um domínio. No entanto, você deverá configurar novamente a AC para aceitar a alteração de nome.

Obter uma solicitação de certificado

Depois que uma AC raiz é instalada, muitas organizações instalam uma ou mais ACs subordinadas para implementar restrições de política na PKI e emitir certificados aos clientes finais. O uso de pelo menos uma AC subordinada pode ajudar a proteger a AC raiz da exposição desnecessária. Quando instala uma AC subordinada, você deve obter um certificado da AC pai.

Se a AC pai estiver online, você poderá usar a opção Enviar uma solicitação de certificado à AC pai e selecionar a AC pai pelo nome da Autoridade de Certificação ou do computador.

Se a AC pai estiver offline, você deverá usar a opção Salvar a solicitação de certificado em um arquivo no computador de destino. Esse procedimento será exclusivo da AC pai. No mínimo, a AC pai deve fornecer um arquivo que contenha o certificado recém-emitido da AC subordinada, preferencialmente o caminho de certificação completo.

Se você obtiver um Certificado de Autoridade de Certificação subordinada que não contenha o caminho de certificação completo, a nova AC subordinada que você instalar deverá ser capaz de criar uma cadeia de AC válida quando for iniciada. Siga este procedimento para criar um caminho de certificação válido:

  • Instale o certificado da AC pai no repositório de certificados Autoridades de Certificação Intermediárias do computador se a AC pai não for uma AC raiz.

  • Instale os certificados em qualquer outra AC intermediária da cadeia.

  • Instale o certificado da AC raiz no repositório Autoridades de Certificação Raiz Confiáveis.

Dica

Essas certificações devem ser instaladas no repositório de certificados antes da instalação do Certificado de Autoridade de Certificação na AC subordinada que você acabou de configurar.

Verificar o período de validade

A criptografia baseada em certificados usa a criptografia de chaves públicas para proteger e assinar os dados. Ao longo do tempo, os invasores poderiam obter dados que estavam protegidos pela chave pública e tentar obter a chave privada com base neles. Com tempo e recursos suficientes, essa chave privada poderia ser comprometida, transformando efetivamente todos os dados protegidos em não protegidos. Além disso, os nomes garantidos por um certificado podem precisar de alteração ao longo do tempo. Como o certificado é uma associação entre um nome e uma chave pública, quando um dos dois é alterado, o certificado deve ser renovado.

Todos os certificados têm um período de validade. Após o término do período de validade, o certificado não é mais considerado uma credencial aceitável ou utilizável.

As ACs não podem emitir certificados válidos após o próprio período de validade deles. Uma melhor prática é renovar o Certificado de Autoridade de Certificação quando metade do período de validade tiver expirado. Ao instalar uma AC, você deve planejar essa data e garantir que ela seja registrada como uma tarefa futura.

Escolher um banco de dados da autoridade de certificação

Como em muitos bancos de dados, o banco de dados da autoridade de certificação é um arquivo no disco rígido. Além desse arquivo, outros arquivos servem como logs de transações e recebem todas as modificações no banco de dados antes que as alterações sejam feitas. Como esses arquivos podem ser acessados frequente e simultaneamente, é melhor manter o banco de dados e os logs de transações em discos rígidos separados ou configurações de disco de alto desempenho, como volumes distribuídos.

O local do banco de dados de certificados e os arquivos de log são mantidos no seguinte local de Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

O Registro contém os seguintes valores:

  • DBDirectory

  • DBLogDirectory

  • DBSystemDirectory

  • DBTempDirectory

Dica

Você pode mover o banco de dados de certificados e os arquivos de log após a instalação. Para obter mais informações, consulte o artigo 283193 na Base de Dados de Conhecimento Microsoft.

Configurar a AC

Depois que uma AC raiz ou subordinada é instalada, você deve configurar as extensões AIA (acesso às informações da autoridade) e CPD (ponto de distribuição de CRL) antes que a AC emita qualquer certificado. A extensão AIA especifica onde encontrar certificados atualizados para a AC. A extensão CPD especifica onde encontrar CRLs atualizadas que foram assinadas pela AC. Essas extensões se aplicam a todos os certificados emitidos pela AC.

A configuração dessas extensões assegura que essas informações sejam incluídas em cada certificado que a AC emite para que sejam disponibilizadas a todos os clientes. Isso garante que os clientes da PKI enfrentem o menor número possível de falhas devido a cadeias de certificados não verificadas ou revogações de certificados, o que pode resultar em conexões de VPN malsucedidas, falhas de logon do cartão inteligente ou assinaturas de email não verificadas.

Como administrador da AC, você pode adicionar, remover ou modificar os pontos de distribuição de CRL e os locais de emissão de certificados CPD e AIA. A modificação da URL de um ponto de distribuição de CRL afeta apenas os certificados emitidos mais recentemente. Os certificados emitidos anteriormente continuarão a referenciar o local original. Por esse motivo, você deve estabelecer esses locais antes que sua AC distribua qualquer certificado.

Considere estas diretrizes ao configurar URLs de extensão CPD:

  • Evite publicar CRLs delta em ACs raiz offline. Como você não revoga muitos certificados em uma AC raiz offline, uma CRL delta provavelmente não é necessária.

  • Ajuste os locais de URL LDAP:/// e HTTP:// padrão na guia Extensões da guia Extensão de Propriedades da autoridade de certificação de acordo com suas necessidades.

  • Publique uma CRL em um local HTTP da extranet ou Internet para que os usuários e aplicativos externos possam executar a validação de certificados. Você pode publicar as URLs LDAP e HTTP dos locais de CPD para permitir que os clientes recuperem dados da CRL com HTTP e LDAP.

  • Lembre-se de que os clientes Windows sempre recuperam a lista de URLs em ordem sequencial até que uma CRL válida seja recuperada.

  • Use locais HTTP de CPD para fornecer locais de CRL acessíveis aos clientes que executam sistemas operacionais que não sejam o Windows.

Dica

Para obter mais informações sobre CRLs e CRLs delta, consulte Configurando a revogação de certificado.

O Windows PowerShell e o certutil dão suporte a números variáveis (precedidos por um sinal de porcentagem – %) para ajudar na publicação de locais de CPD e AIA. A guia Extensão de Propriedades da AC dá suporte a variáveis entre colchetes. A tabela a seguir iguala as variáveis entre as interfaces e descreve seus significados.

Variável

Nome da guia Extensões

Descrição

%1

<ServerDNSName>

O nome DNS de um computador da Autoridade de Certificação. Se conectado a um domínio DNS, será o nome de domínio totalmente qualificado. Caso contrário, será o nome do host do computador.

%2

<ServerShortName>

O nome NetBIOS do servidor da Autoridade de Certificação

%3

<CaName>

O nome da Autoridade de Certificação

%4

<CertificateName>

Isso permite que cada revisão adicional do certificado tenha um sufixo exclusivo.

%4

Não

Não usada

%6

<ConfigurationContainer>

O local do contêiner de configuração no AD DS (Serviços de Domínio Active Directory)

%7

<CATruncatedName>

O nome da Autoridade de Certificação truncado em 32 caracteres com um hash no final

%8

<CRLNameSuffix>

Isso insere um sufixo no nome do arquivo ao publicar uma CRL em um arquivo ou local de URL.

%9

<DeltaCRLAllowed>

Quando uma CRL delta é publicada, isso substitui a variável CRLNameSuffix por um sufixo separado para distinguir a CRL delta da CRL.

%10

<CDPObjectClass>

O identificador de classes do objeto dos pontos de distribuição da CRL, que é usado na publicação em uma URL LDAP.

%11

<CAObjectClass>

O identificador de objetos de classe da AC, que é usado na publicação em uma URL LDAP.

Publicar a extensão AIA

A extensão AIA diz aos computadores cliente onde eles podem localizar o certificado a ser verificado. Isso permite que o cliente confirme se o certificado pode ser confiável.

Você pode configurar a extensão AIA usando a interface da Autoridade de Certificação, o Windows PowerShell ou o comando certutil. A tabela a seguir descreve as opções que você pode usar com a extensão AIA ao utilizar esses métodos.

Nome da caixa de seleção da interface

Parâmetro do Windows PowerShell

Valor de certutil

Incluir na extensão AIA do certificado emitido

-AddToCertificateAia

2

Incluir na extensão do protocolo OCSP

-AddToCertificateOcsp

32

Os exemplos nesta seção para a publicação da extensão AIA representam o seguinte cenário:

  • O nome do domínio é corp.contoso.com.

  • Há um servidor Web denominado App1 no domínio.

  • App1 tem uma pasta compartilhada denominada PKI que concede as permissões de Leitura e Gravação da AC.

  • App1 tem www como DNS CNAME e um diretório virtual compartilhado denominado PKI.

  • O primeiro protocolo que os computadores cliente devem usar para as informações de AIA é HTTP.

  • O segundo protocolo que os computadores cliente devem usar para as informações de AIA é LDAP.

  • A AC configurada é uma AC emissora online.

  • OCSP não está em uso.

Usar a interface para publicar a extensão AIA

A interface usa os nomes de caixas de seleção e variáveis descritos nas tabelas anteriores. Você pode acessá-la por meio da interface da Autoridade de Certificação. No painel de conteúdo, clique com o botão direito do mouse na AC, clique em Propriedades e, depois, em Extensões. Em Selecionar extensão, clique em AIA (Acesso às Informações da Autoridade).

Propriedades AIA

Figura 1 Menu da extensão AIA

As configurações e os locais definidos na interface de usuário são os seguintes:

  • C:\Windows\system32\CertSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt

  • https://www.contoso.com/pki/\<ServerDNSName>_<CaName><CertificateName>.crt

    • Incluir na extensão AIA dos certificados emitidos
  • file://\\App1.corp.contoso.com\pki\<ServerDNSName>_<CaName><CertificateName>.crt

  • ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services,CN=Services,<ConfigurationContainer><CAObjectClass>

    • Incluir na extensão AIA dos certificados emitidos

Usar o Windows PowerShell para publicar a extensão AIA

Os seguintes comandos do Windows PowerShell podem ser usados para configurar a extensão AIA para o cenário dado:

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia https://www.contoso.com/pki/%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt
Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Dica

  • Se você usar o Windows PowerShell para adicionar caminhos AIA, os caminhos existentes permanecerão estabelecidos. O primeiro comando do Windows PowerShell no exemplo remove todos os caminhos existentes. Para obter mais informações sobre como remover caminhos AIA usando o Windows PowerShell, consulte Remove-CAAuthorityInformationAccess.

  • Não é possível adicionar um caminho local usando o cmdlet Add-CAAuthorityInformationAccess do Windows PowerShell. O Certificado de Autoridade de Certificação será automaticamente publicado no local padrão %systemroot%\system32\CertSrv\CertEnroll.

Usar certutil para publicar a extensão AIA

O seguinte comando certutil pode ser usado para configurar a extensão AIA para o cenário dado:

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:https://www.contoso.com/pki/%1_%3%4.crt\n1:file://\\App1.corp.contoso.com\pki\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Dica

  • Depois de alterar esses caminhos, lembre-se de reiniciar o CertSvc. Você pode reiniciá-lo executando o seguinte comando do Windows PowerShell: restart-service certsvc

  • Em um comando certutil, digite, entre aspas, todos os caminhos como uma única cadeia de caracteres contínua. Cada caminho é separado por um \n.

Publicar a extensão CPD

A extensão CPD diz aos computadores cliente onde eles podem localizar a CRL mais recente para que o cliente possa confirmar que determinado certificado não foi revogado.

Você pode configurar a extensão CPD usando a interface da Autoridade de Certificação, o Windows PowerShell ou o comando certutil. A tabela a seguir descreve as opções que você pode usar com a extensão CPD ao utilizar esses métodos.

Nome da caixa de seleção da interface

Parâmetro do Windows PowerShell

Valor de certutil

Publicar CRLs neste local

-PublishToServer

1

Incluir em todas as CRLs.

(Especifica onde publicar no Active Directory durante a publicação manual.)

-AddToCrlCdp

8

Incluir nas CRLs.

(Os clientes usam isso para encontrar os locais da CRL delta.)

-AddToFreshestCrl

4

Incluir na extensão CPD dos certificados emitidos.

-AddToCertificateCdp

2

Publicar CRLs delta neste local.

-PublishDeltaToServer

64

Incluir na extensão CDP das CRLs emitidas.

-AddToCrlIdp

128

Dica

A extensão IDP (ponto de distribuição de emissão) é usada por clientes que não são do Windows para verificar a revogação de certificados. A extensão IDP permite que CRLs particionadas sejam implantadas no uso de ACs de terceiros. As CRLs particionadas permitem que uma AC de terceiros publique CRLs apenas com tipos específicos de certificado em cada CRL. Por exemplo, você pode ter CRLs separadas para certificados finais versus Certificados da Autoridade de Certificação. Especificamente, as seguintes opções podem ser definidas no IDP:

  1. onlyContainUserCerts. Esta opção do IDP permite apenas os certificados que não apresentam os valores AC na extensão das restrições básicas. Se o certificado não contiver uma extensão das restrições básicas, ele não será tido como uma AC.

  2. onlyContainsCACerts. Essa opção do IDP permite apenas os certificados que contêm uma extensão das restrições básicas com uma AC definida para ser incluída na CRL.

Se estiver permitindo a publicação da CRL delta em um servidor Web do IIS (Serviços de Informações da Internet), você deverá modificar a configuração de IIS padrão definindo allowDoubleEscaping=true do elemento requestFiltering na seção system.web da configuração do IIS. Por exemplo, se você quiser permitir o espaçamento duplo para o diretório virtual da PKI do site padrão no IIS, execute o seguinte comando no servidor Web do IIS: appcmd set config "Default Web Site/pki" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true. Para obter mais informações, consulte AD CS: Web server should allow URI containing the “+” character to enable publishing of delta CRLs (AD CS: servidor Web deve permitir URI contendo o caractere "+" para habilitar a publicação de CRLs delta).

Os exemplos desta seção para a publicação da extensão CPD representam o seguinte cenário:

  • O nome do domínio é corp.contoso.com.

  • Há um servidor Web denominado App1 no domínio.

  • App1 tem uma pasta compartilhada denominada PKI que concede as permissões de Leitura e Gravação da AC.

  • App1 tem www como DNS CNAME e um diretório virtual compartilhado denominado PKI.

  • O primeiro protocolo que os computadores cliente devem usar para as informações de CPD é HTTP.

  • O segundo protocolo que os computadores cliente devem usar para as informações de CPD é LDAP.

  • A AC configurada é uma AC emissora online.

  • IDP não está um uso.

Usar a interface para publicar a extensão CPD

A interface usa os nomes de caixas de seleção e variáveis descritos nas tabelas anteriores. Você pode acessá-la por meio da interface da Autoridade de Certificação. No painel de conteúdo, clique com o botão direito do mouse na AC, clique em Propriedades e, depois, em Extensões. Em Selecionar extensão, clique em Pontos de Distribuição da Lista de Certificados Revogados.

Propriedades CPD

Figura 2 Menu da extensão CPD

As configurações e os locais definidos na interface são os seguintes:

  • C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

    • Publicar CRLs neste local

    • Publicar CRLs delta neste local

  • https://www.contoso.com/pki/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

    • Incluir nas CRLs. Os clientes usam isso para encontrar os locais da CRL delta.

    • Incluir na extensão CPD dos certificados emitidos

  • file://\\App1.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

    • Publicar CRLs neste local

    • Publicar CRLs Delta neste local

  • ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>

    • Incluir em todas as CRLs. Especifica onde publicar no Active Directory durante a publicação manual.

    • Incluir na extensão CPD dos certificados

Usar o Windows PowerShell para publicar a extensão CPD

Os seguintes comandos do Windows PowerShell são usados para configurar a extensão CPD para o cenário dado:

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri https://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl
Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer
Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp

Dica

Se você usar o Windows PowerShell para adicionar caminhos CPD, os caminhos existentes permanecerão estabelecidos. O primeiro comando do Windows PowerShell no exemplo remove todos os caminhos existentes. Para obter mais informações sobre como usar o Windows PowerShell para remover caminhos CPD, consulte Remove-CACrlDistributionPoint.

Usar certutil para publicar a extensão CPD

O seguinte comando certutil configura a extensão CPD para o cenário dado:

certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:https://www.contoso.com/pki/%3%8%9.crl\n65:file://\\App1.corp.contoso.com\pki\%3%8%9.crl\n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

Dica

  • Depois de alterar esses caminhos, lembre-se de reinicializar o serviço da Autoridade de Certificação. No Usando o Windows PowerShell, você pode reiniciar o CertSvc executando o seguinte comando: restart-service certsvc

  • Em um comando certutil, digite, entre aspas, todos os caminhos como uma única cadeia de caracteres contínua, separando cada caminho com \n.

Para publicar a CRL, você pode executar o comando certutil -crl na AC do Usando o Windows PowerShell ou de um prompt de comando executado como administrador. Para obter mais informações sobre a configuração e a publicação de CRL, consulte Configurando a revogação de certificado.

Verificar a configuração

Para verificar a configuração da Autoridade de Certificação, você pode executar os seguintes comandos no Windows PowerShell ou em uma janela do prompt de comando:

Comando

Descrição

Certutil -CAInfo

Mostra o status dos nomes, a localidade, os OIDs e as CRLs da AC.

Certutil -getreg

Exibe a configuração do Registro da Autoridade de Certificação.

Certutil -ADCA

Confirma a configuração das ACs corporativas.

Você pode usar a ferramenta Enterprise PKI View (PKIView.msc) para verificar suas configurações de publicação de AIA e CPD. Para obter mais informações, consulte Enterprise PKI.

Você também pode usar o serviço da função Respondente Online para verificar a revogação de certificados. Para mais informações sobre o Respondente Online, consulte Online Responder Installation, Configuration, and Troubleshooting Guide (Guia de instalação, configuração e solução de problemas do Respondente Online).

Conteúdo relacionado