Segurança e VPN : Remote Authentication Dial-In User Service (RADIUS)

Guia do certificado da versão EAP 1.01

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


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 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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-1.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-2.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-3.gif

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 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.

eap-v101-cert-guide-4.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-5.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-6.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-7.gif

Campo de assunto

O campo de assunto identifica CA intermediário. Este valor é usado para determinar emitido para colocar no tab geral do certificado.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-8.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-9.gif

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:

  • 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.

eap-v101-cert-guide-10.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-11.gif

Campo do Enhanced Key Usage

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-12.gif

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).

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-13.gif

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 o @domain 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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-14.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-15.gif

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.

http://www.cisco.com/c/dam/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/64062-eap-v101-cert-guide-16.gif

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:

eap-v101-cert-guide-17.gif

.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:

eap-v101-cert-guide-18.gif

.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:

eap-v101-cert-guide-19.gif

.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 OpenSSLleavingcisco.com . 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 254632leavingcisco.com 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.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 64062