Guia do certificado da versão EAP 1.01

Transcrição

1 Guia do certificado da versão EAP 1.01 Índice Introdução Pré-requisitos Requisitos Componentes Utilizados Convenções Certificados de servidor Campo de assunto Campo do expedidor Campo do Enhanced Key Usage Certificados CA raiz Campos do assunto e do expedidor Certificados de CA intermediários Campo de assunto Campo do expedidor Certificados de cliente Campo do expedidor Campo do Enhanced Key Usage Campo de assunto Campo de nome alternativo sujeito Certificados da máquina Assunto e campos SAN Campo do expedidor Apêndice A - Extensões de certificado comuns Apêndice B - Conversão do formato do certificado C do apêndice - Período da validade de certificado Informações Relacionadas Introdução Este documento esclarece alguma da confusão que acompanha os vários tipos, formatos, e exigências do certificado associadas com os vários formulários do Extensible Authentication Protocol (EAP). Os cinco tipos do certificado relacionaram-se ao EAP que este documento discute é server, CA raiz, CA intermediário, cliente, e máquina. Estes Certificados são encontrados em vários formatos e pode haver umas exigências de deferimento em relação a cada um deles baseou na implementação de EAP envolvida. Pré-requisitos Requisitos Não existem requisitos específicos para este documento. Componentes Utilizados Este documento não se restringe a versões de software e hardware específicas. Convenções Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos. Certificados de servidor O certificado de servidor é instalado no servidor Radius e seu propósito principal no EAP é criar o túnel cifrado do Transport Layer Security (TLS) que protege a informação da autenticação. Quando você usa o EAP-MSCHAPv2, o certificado de servidor toma em um papel secundário que seja identificar o servidor Radius como uma entidade confiável para a autenticação. Este papel secundário é realizado com o uso do campo do Enhanced Key Usage (EKU). O campo EKU identifica o certificado como um certificado de servidor válido e verifica que a CA raiz que emitiu o certificado é um root confiável CA. Isto exige a presença do certificado CA raiz. O Cisco Secure ACS exige que o certificado seja

2 Base64-encoded ou formato binário DER-codificado X.509 v3. Você pode criar este certificado com o qualquer um o uso de uma solicitação de assinatura de certificado (CSR) no ACS, que é submetido a CA. Ou, você pode igualmente cortar o certificado com o uso de um formulário da criação do certificado de CA da em-casa (como serviços certificados de Microsoft). É importante notar que, quando você puder criar o certificado de servidor com os tamanhos chaves maiores de 1024, nenhum chave maior de 1024 não trabalha com PEAP. O cliente pendura mesmo se a autenticação passa. Se você cria o certificado com o uso de um CSR, está criado com.cer, o.pem, ou o formato de.txt. Em raras ocasiões, é criado sem a extensão. Assegure-se de que seu certificado seja um arquivo de texto simples com uma extensão que você possa mudar como necessário (a ferramenta ACS usa a extensão de.cer ou do.pem). Adicionalmente, se você usa um CSR, a chave privada do certificado é criada no trajeto que você especifica como um arquivo separado que possa ou não possa ter uma extensão e que tenha uma senha associada com ele (a senha seja exigida para a instalação no ACS). Apesar da extensão, assegure-se de que seja um arquivo de texto simples com uma extensão que você possa mudar como necessário (a ferramenta ACS usa a extensão.pvk ou de.pem). Se nenhum trajeto é especificado para a chave privada, o ACS salvar a chave no diretório de C:\Program Files \CiscoSecure ACS vx.x \ CSAdmin \ logs e olha neste diretório se nenhum trajeto está especificado para o arquivo-chave privado quando você instala o certificado. Se o certificado é criado com o uso dos serviços certificados de Microsoft certificate o formulário da submissão, asseguram-se de que você marque as chaves como exportable de modo que você possa instalar o certificado no ACS. A criação de um certificado simplifica desse modo o processo de instalação significativamente. Você pode diretamente instalá-la na loja apropriada de Windows da interface da WEB dos serviços certificados e então instalá-la no ACS do armazenamento com o uso do CN como a referência. Um certificado instalado na loja de computador local pode igualmente ser exportado do armazenamento de Windows e ser instalado em um outro computador facilmente. Quando este tipo de certificado é exportado, as chaves precisam de ser marcadas como exportable e de ser dadas uma senha. O certificado aparece então no formato do.pfx que inclui a chave privada e o certificado de servidor. Quando instalado corretamente na loja do certificado de Windows, o certificado de servidor precisa de aparecer nos Certificados (computador local) > pessoal > dobrador dos Certificados como visto neste exemplo de janela. Os certificados auto-assinados são Certificados que você cria sem uma raiz ou o envolvimento intermediário de CA. Têm o mesmo valor nos campos do assunto e do expedidor como um certificado CA raiz. A maioria de certificados auto-assinados usam o formato X.509 v1. Consequentemente, não trabalham com ACS. Contudo, até à data da versão 3.3, o ACS tem a capacidade para criar seus próprios certificados auto-assinados que você pode usar para o EAP-TLS e o PEAP. Não use um tamanho chave maior de 1024 para a compatibilidade com PEAP e EAP-TLS. Se você usa um certificado auto-assinado, o certificado igualmente atua na capacidade do certificado CA raiz e deve ser instalado nos Certificados (computador local) > dobrador das Autoridades de certificação de raiz confiável > dos Certificados do cliente quando você usa o suplicante EAP do Microsoft. Instala automaticamente na loja dos Certificados do root confiável no server. Contudo, deve-se ainda confiar no certificate trust list na instalação do certificado ACS. Veja a seção dos certificados CA raiz para mais informação. Porque os certificados auto-assinados estão usados como o certificado CA raiz para a validação do certificado de servidor quando você usar o suplicante EAP do Microsoft, e porque o período de validade não pode ser aumentado do padrão de um ano, Cisco recomenda que você os usa somente para o EAP como uma medição temporária até que você puder usar CA tradicional. Campo de assunto O campo de assunto identifica o certificado. O valor do CN é usado para determinar emitido para colocar no tab geral do certificado e povoado com a informação que você incorpora no campo de assunto do certificado diálogo CSR ACS '' ou com a informação do campo de nome em serviços certificados de Microsoft. O valor do CN é usado para dizer a ACS que certificado precisa de usar da loja do certificado da máquina local se a opção para instalar o certificado do armazenamento é usada.

3 Campo do expedidor O campo do expedidor identifica CA que corta o certificado. Use este valor a fim determinar o valor do emitido pelo campo no tab geral do certificado. É povoado com o nome de CA. Campo do Enhanced Key Usage O campo do Enhanced Key Usage identifica a finalidade pretendida do certificado e precisa-a de ser alistada como a autenticação de servidor. Este campo é imperativo quando você usa o suplicante do Microsoft para o PEAP e o EAP-TLS. Quando você usa serviços certificados de Microsoft, este está configurado em CA autônomo com a seleção do certificado de autenticação de servidor da gota-para baixo pretendida da finalidade e na empresa CA com a seleção do servidor de Web da gota-para baixo do molde de certificado. Se você pede um certificado com o

4 uso de um CSR com serviços certificados de Microsoft, você não tem a opção para especificar a finalidade pretendida com CA autônomo. Consequentemente, o campo EKU é ausente. Com a empresa CA, você tem a gota-para baixo pretendida da finalidade. Alguns CA não criam Certificados com um campo EKU assim que são inúteis quando você usa o suplicante EAP do Microsoft. Certificados CA raiz A uma finalidade do certificado CA raiz é identificar o certificado de servidor (e o certificado de CA intermediário se aplicável) como um certificado confiável ao ACS e ao suplicante do EAP-MSCHAPv2 de Windows. Deve ser ficada situada na loja das Autoridades de certificação de raiz confiável em Windows no servidor ACS e, no caso do EAP-MSCHAPv2, no computador de cliente. A maioria de certificados CA raiz da terceira parte são instalados com Windows e há pouco esforço envolvido com o este. Se os serviços certificados de Microsoft são usados e o servidor certificado está na mesma máquina que o ACS, a seguir o certificado CA raiz está instalado automaticamente. Se o certificado CA raiz não é encontrado na loja das Autoridades de certificação de raiz confiável em Windows, a seguir deve ser adquirido de seu CA e ser instalado. Quando instalado corretamente na loja do certificado de Windows, o certificado CA raiz precisa de aparecer nos Certificados (computador local) > dobrador das Autoridades de certificação de raiz confiável > dos Certificados como visto neste exemplo de janela. Campos do assunto e do expedidor Os campos do assunto e do expedidor identificam CA e precisam-no de ser exatamente os mesmos. Use estes campos para povoar emitido a e emitido por campos no tab geral do certificado. São povoados com o nome da CA raiz.

5 Certificados de CA intermediários Os certificados de CA intermediários são os Certificados que você se usa para identificar CA que é subordinado a uma CA raiz. Alguns certificados de servidor (os Certificados wireless de Verisign) são criados com o uso de CA intermediário. Se um certificado de servidor que esteja cortado por um intermediário CA é usado, o certificado de CA intermediário deve ser instalado na área intermediária das autoridades de certificação da loja de máquina local no servidor ACS. Também, se o suplicante EAP do Microsoft é usado no cliente, o certificado CA raiz da CA raiz que criou o certificado de CA intermediário deve igualmente estar na loja apropriada no servidor ACS e no cliente de modo que a corrente da confiança possa ser estabelecida. O certificado CA raiz e o certificado de CA intermediário devem ser marcados como confiado no ACS e no cliente. A maioria de certificados de CA intermediários não são instalados com Windows assim que você necessidade mais provável de adquiri-los do vendedor. Quando instalado corretamente na loja do certificado de Windows, o certificado de CA intermediário aparece nos Certificados (computador local) > dobrador intermediário das autoridades de certificação > dos Certificados como visto neste exemplo de janela. Campo de assunto O campo de assunto identifica CA intermediário. Este valor é usado para determinar emitido para colocar no tab geral do certificado.

6 Campo do expedidor O campo do expedidor identifica CA que corta o certificado. Use este valor a fim determinar o valor do emitido pelo campo no tab geral do certificado. É povoado com o nome de CA. Certificados de cliente Os certificados de cliente são usados para identificar positivamente o usuário no EAP-TLS. Não têm nenhum papel em construir o túnel TLS e não são usados para a criptografia. A identificação positiva é realizada por um de três significa:

7 Comparação do CN (ou o nome) Compara o CN no certificado com o username no banco de dados. Mais informação neste tipo da comparação é incluída na descrição do campo de assunto do certificado. Comparação de SAN Compara o SAN no certificado com o username no banco de dados. Isto é apoiado somente até à data de ACS 3.2. Mais informação neste tipo da comparação é incluída na descrição do campo de nome alternativo sujeito do certificado. Comparação binária Compara o certificado com uma cópia binária do certificado armazenado no banco de dados (somente o AD e o LDAP podem fazer este). Se você usa a comparação binária do certificado, você deve armazenar o certificado de usuário em um formato binário. Também, para o LDAP genérico e o diretório ativo, o atributo que armazena o certificado deve ser o usercertificate nomeado atributo do padrão LDAP. O que método de comparação é usado, a informação no campo apropriado (CN ou SAN) deve combinar o nome que seu banco de dados usa para a autenticação. O AD usa o nome de netbios para a autenticação em modo misturado e o UPN no modo nativo. Esta seção discute a geração do certificado de cliente com o uso de serviços certificados de Microsoft. O EAP-TLS exige um certificado de cliente original para que cada usuário seja autenticado. O certificado deve ser instalado em cada computador para cada usuário. Quando instalado corretamente, o certificado é ficado situado nos Certificados - usuário atual > pessoal > dobrador dos Certificados como visto neste exemplo de janela. Campo do expedidor O campo do expedidor identifica CA que corta o certificado. Use este valor a fim determinar o valor do emitido pelo campo no tab geral do certificado. Isto é povoado com o nome de CA. Campo do Enhanced Key Usage

8 O campo do Enhanced Key Usage identifica a finalidade pretendida do certificado e precisa-a de conter a authenticação do cliente. Este campo é imperativo quando você usa o suplicante do Microsoft para o PEAP e o EAP-TLS. Quando você usa serviços certificados de Microsoft, este está configurado em CA autônomo quando você seleciona o certificado de autenticação de cliente da gota-para baixo pretendida da finalidade e na empresa CA quando você seleciona o usuário da gota-para baixo do molde de certificado. Se você pede um certificado com o uso de um CSR com serviços certificados de Microsoft, você não tem a opção para especificar a finalidade pretendida com CA autônomo. Consequentemente, o campo EKU é ausente. Com a empresa CA, você tem a gota-para baixo pretendida da finalidade. Alguns CA não criam Certificados com um campo EKU. São inúteis quando você usa o suplicante EAP do Microsoft. Campo de assunto Este campo é usado na comparação do CN. O primeiro CN alistado é comparado contra o banco de dados para encontrar um fósforo. Se um fósforo é encontrado, a autenticação sucede. Se você usa CA autônomo, o CN está povoado com o que quer que você põe no campo de nome no formulário da submissão do certificado. Se você usa a empresa CA, o CN está povoado automaticamente com o nome da conta como catalogado no console de usuários e de computadores de diretório ativo (este não combina necessariamente o UPN ou o nome de netbios).

9 Campo de nome alternativo sujeito O campo de nome alternativo sujeito é usado na comparação de SAN. O SAN alistado é comparado contra o banco de dados para encontrar um fósforo. Se um fósforo é encontrado, a autenticação sucede. Se você usa a empresa CA, o SAN está povoado automaticamente com do nome de logon do diretório ativo (UPN). CA autônomo não inclui um campo SAN assim que você não pode usar a comparação de SAN. Certificados da máquina Os certificados da máquina estão usados no EAP-TLS para identificar positivamente o computador quando você usa a autenticação da máquina. Você pode somente alcançar estes Certificados quando você configura sua empresa CA de Microsoft para a inscrição automática do certificado e se junta ao computador ao domínio. O certificado é criado automaticamente quando você usa as credenciais do diretório ativo do computador e as instala na loja de computador local. Os computadores que são já membros do domínio antes que você configure a inscrição automática recebem um certificado a próxima vez que Windows reinicie. O certificado da máquina é instalado nos Certificados (computador local) > pessoal > dobrador dos Certificados dos Certificados (computador local) MMC pressão-apenas em certificados de servidor como. Você não pode instalar estes Certificados em nenhuma outra máquina desde que você não pode exportar a chave privada. Assunto e campos SAN O assunto e os campos SAN identificam o computador. O valor é povoado pelo nome totalmente qualificado do computador e usado a fim determinar emitido para colocar no tab geral do certificado e é o mesmo para o assunto e os campos SAN.

10 Campo do expedidor O campo do expedidor identifica CA que corta o certificado. Use este valor a fim determinar o valor do emitido pelo campo no tab geral do certificado. É povoado com o nome de CA. Apêndice A - Extensões de certificado comuns.csr Esta não é realmente um certificado mas um pouco uma solicitação de assinatura de certificado. É um arquivo de texto simples com este formato:.pvk Esta extensão denota uma chave privada embora a extensão não garante que o índice é realmente uma chave privada. A necessidade satisfeita de ser texto simples com este formato:

11 .cer Esta é uma extensão genérica que denote um certificado. O server, a CA raiz, e os certificados de CA intermediários podem estar neste formato. É geralmente um arquivo de texto simples com uma extensão que você possa mudar enquanto você precisa e pode ser DER ou formato de Base64. Você pode importar este formato na loja do certificado de Windows..pem Esta extensão representa o Privacy Enhanced Mail. Esta extensão é de uso geral com UNIX, Linux, BSD, e assim por diante. É usada geralmente para certificados de servidor e chaves privadas, e é geralmente um arquivo de texto simples com uma extensão que você possa mudar enquanto você precisa do.pem a.cer de modo que você possa o importar à loja do certificado de Windows. O índice interno de.cer e de arquivos do.pem olha geralmente como esta saída:.pfx Esta extensão representa a troca de informação pessoal. Este formato é um método que você pode se usar para empacotar Certificados em um arquivo único. Por exemplo, você pode empacotar um certificado de servidor e seus chave privada e certificado CA raiz associados em um arquivo e facilmente importar o arquivo na loja apropriada do certificado de Windows. É a mais de uso geral para o server e os certificados de cliente. Infelizmente, se um certificado CA raiz é incluído, o certificado CA raiz é instalado sempre na loja atual do usuário em vez da loja de computador local mesmo se a loja de computador local é especificada para a instalação..p12 Este formato geralmente é considerado somente com um certificado de cliente. Você pode importar este formato na loja do certificado de Windows..p7b Este é um outro formato que armazene certificados múltiplos em um arquivo. Você pode importar este formato na loja do certificado de Windows. Apêndice B - Conversão do formato do certificado Na maioria dos casos, a conversão do certificado ocorre quando você muda a extensão (por exemplo, do.pem a.cer) desde que os Certificados estão geralmente no formato em texto simples. Às vezes, um certificado não está no formato do texto simples e você deve convertê-lo com o uso de uma ferramenta tal como o OpenSSL. Por exemplo, a solution engine ACS não pode instalar Certificados no formato do.pfx. Consequentemente, você deve converter o certificado e a chave privada em um formato útil. Esta é a sintaxe de comando básico para o OpenSSL: openssl pkcs12 -in c:\certs \test.pfx -out c:\certs \test.pem Você é alertado para a senha da importação e a frase de acesso PEM. Estas senhas precisam de ser as mesmas e são a senha da chave privada que é especificada quando o.pfx é exportado. A saída é um único arquivo do.pem que inclua todos os Certificados e chaves privadas no.pfx. Este arquivo pode ser referido no ACS como o certificado e o arquivo-chave privado e instalam sem problemas. C do apêndice - Período da validade de certificado Um certificado é somente útil durante seu período de validade. O período de validade para um certificado CA raiz é determinado quando a CA raiz é estabelecida e pode variar. O período de validade para um certificado de CA intermediário é determinado quando CA é estabelecido e não pode exceder o período de validade da CA raiz a que é subordinado. O período de validade para o server, o cliente, e os certificados da máquina são ajustados automaticamente a um ano com serviços certificados de Microsoft. Isto pode somente ser mudado quando você corta o registro de Windows conforme o artigo da base de conhecimento microsoft e não pode exceder o período de validade da CA raiz. O período de validade dos certificados auto-assinados que o ACS gera é sempre um ano e não pode ser mudado nas versões atual. Informações Relacionadas Solicitações de Comentários (RFCs) Notas Técnicas de Troubleshooting

12 Cisco Systems Inc. Todos os direitos reservados. Data da Geração do PDF: 19 Setembro