Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Certificados digitais

Saiba mais sobre os certificados digitais e descubra como configurar certificados digitais.

Um certificado digital é um meio eletrônico para verificar sua identidade por meio de um terceiro confiável, conhecido como CA. Alternativamente, você pode usar um certificado autoassinado para atestar sua identidade.

O processamento manual de certificados inclui a geração de uma solicitação PKCS10, submissão ao CA, recuperação do certificado assinado e carregamento manual do certificado no dispositivo da Juniper Networks. Com base no seu ambiente de implantação, você pode usar o SCEP ou o CMPv2 para a inscrição on-line de certificados.

Para usar um certificado digital para autenticar sua identidade ao estabelecer uma conexão VPN segura, faça o seguinte:

  • Obtenha um certificado de CA do qual pretende obter um certificado local e depois carregue o certificado de CA no dispositivo. O certificado ca pode conter um CRL para identificar certificados inválidos.

  • Obtenha um certificado local da CA cujo certificado de CA você já carregou anteriormente e, em seguida, carregue o certificado local no dispositivo. O certificado local estabelece a identidade do dispositivo da Juniper Networks com cada conexão de túnel.

Gere certificados digitais manualmente: visão geral da configuração

Para obter certificados digitais manualmente:

  1. Gere um keypair no dispositivo. Veja certificados digitais auto-assinados.

  2. Crie um perfil ou perfis de CA que contenham informações específicas para um CA. Veja exemplo: configure um perfil de CA.

  3. Gere o CSR para o certificado local e envie-o para o servidor CA. Veja exemplo: Gere manualmente um CSR para o certificado local e envie-o para o servidor CA.

  4. Carregue o certificado no dispositivo. Veja exemplo: Carregue CA e certificados locais manualmente.

  5. Configure o reencamamento automático. Veja exemplo: usar o SCEP para renovar automaticamente um certificado local.

  6. Se necessário, carregue o CRL do certificado no dispositivo. Veja exemplo: carregue manualmente um CRL no dispositivo.

  7. Se necessário, configure o perfil ca com locais de CRL. Veja exemplo: configure um perfil de autoridade de certificado com locais de CRL.

Certificados digitais no Junos OS

Para redes pequenas, o uso de chaves pré-compartilhadas em uma configuração IPsec é muitas vezes suficiente. No entanto, à medida que uma rede cresce, você pode achar desafiador adicionar novas chaves pré-compartilhadas no roteador local e todos os pares IPsec novos e existentes. A implementação do certificado digital ajuda você a escalar a rede IPsec.

Uma implementação de certificado digital usa o PKI, que exige que você gere um papel-chave que consiste em uma chave pública e uma chave privada. As chaves são criadas com um gerador de números aleatórios e são usadas para criptografar e descriptografar dados. Em redes que não usam certificados digitais, um dispositivo habilitado para IPsec criptografa dados com a chave privada e os pares IPsec descriptografam os dados com a chave pública.

Com certificados digitais, você e seus pares IPsec solicitam um CA para enviar um certificado de CA que contenha a chave pública da CA. Em seguida, você solicita à CA para inscrever um certificado digital local que contenha sua chave pública e algumas informações adicionais. Quando a CA processa sua solicitação, ela assina seu certificado local com a chave privada da CA. Em seguida, você instala o certificado ca e o certificado local em seu roteador local e carrega o certificado ca nos dispositivos remotos antes que você possa estabelecer túneis IPsec com seus pares.

Quando você solicita um relacionamento de peering com um peer IPSec, o peer recebe uma cópia do seu certificado local. Como o peer já tem o certificado ca carregado, ele pode usar a chave pública da CA contida no certificado ca para descriptografar seu certificado local que foi assinado pela chave privada do CA. Como resultado, o peer agora tem uma cópia da sua chave pública. O peer criptografa dados com sua chave pública antes de enviar para você. Quando o roteador local recebe os dados, ele descriptografa os dados com a sua chave privada.

No Junos OS, você deve implementar as seguintes etapas para poder usar inicialmente certificados digitais:

  • Configure um perfil de CA para solicitar ca e certificados digitais locais — o perfil contém o nome e URL da AUTORIDADE DE CA ou registro (RA), bem como algumas configurações de temporizante de nova tentativa.

  • Configure o suporte à lista de revogação de certificados — uma lista de revogação de certificados (CRL) contém uma lista de certificados cancelados antes da data de validade. Quando um peer participante usa um CRL, o CA adquire o CRL emitido mais recentemente e verifica a assinatura e a validade do certificado digital de um peer. Você pode solicitar e carregar CRLs manualmente, configurar um servidor LDAP para lidar com o processamento de CRL automaticamente ou desativar o processamento de CRL que é habilitado por padrão.

  • Solicite um certificado digital da CA — a solicitação pode ser feita on-line ou manualmente. As solicitações de certificados digitais de CA on-line usam o formato protocolo de inscrição de certificados simples (SCEP). Se você solicitar o certificado ca manualmente, você também deve carregar o certificado manualmente.

  • Gere um par de chaves privadas/públicas — a chave pública está incluída no certificado digital local e a chave privada é usada para descriptografar dados recebidos de pares.

  • Gere e inscreva um certificado digital local — o certificado local pode ser processado on-line usando SCEP ou gerado manualmente no formato Public-Key Cryptography Standards nº 10 (PKCS-10). Se você criar a solicitação de certificado local manualmente, você também deve carregar o certificado manualmente.

  • Aplique o certificado digital em uma configuração de IPSec — Para ativar um certificado digital local, você configura a proposta do IKE de usar certificados digitais em vez de chaves pré-compartilhadas, consultar o certificado local na política de IKE e identificar o CA no conjunto de serviços.

Opcionalmente, você pode fazer o seguinte:

  • Configure o certificado digital para reenrollar automaticamente — a partir do Junos OS Release 8.5, você pode configurar o reenrollamento automático para certificados digitais.

  • Monitore eventos de certificados digitais e exclua certificados e solicitações — Você pode emitir comandos de modo operacional para monitorar túneis IPSec estabelecidos usando certificados digitais e excluir certificados ou solicitações.

Gere um certificado de CA raiz

Para definir um certificado autoassinado na CLI, você deve fornecer os seguintes detalhes:

  • Identificador de certificado (gerado na etapa anterior)

  • FQDN para o certificado

  • Endereço de e-mail da entidade que possui o certificado

  • Nome comum e a organização envolvida

Gere um certificado de CA raiz usando o Junos OS CLI:

  1. A partir do modo operacional, gere um keypair PKI público e privado para um certificado digital local.

    Aqui, você pode selecionar uma das seguintes combinações:

    • 1024 bits (apenas RSA/DSA)

    • 2048 bits (apenas RSA/DSA)

    • 256 bits (apenas ECDSA)

    • 384 bits (apenas ECDSA)

    • 4096 bits (somente RSA/DSA)

    • 521 bits (apenas ECDSA)

    Exemplo:

    Ou
  2. Defina um certificado auto-assinado.

    Exemplo:

    Ao configurar a opção add-ca-constraint , certifique-se de que o certificado possa ser usado para assinar outros certificados.

  3. A partir do modo de configuração, aplique o certificado carregado como root-ca no perfil de proxy SSL.

    Exemplo:

  4. Importe o CA raiz como um CA confiável para navegadores de clientes. O certificado de CA raiz é necessário para que os navegadores clientes confiem nos certificados assinados pelo firewall.

Gere certificados SSL autoassinar manualmente

Para gerar manualmente um certificado SSL auto-assinado em dispositivos da Juniper Networks:

  1. Estabeleça conectividade básica.
  2. Se você tiver acesso de login raiz, você pode gerar manualmente o certificado autoassinado usando os seguintes comandos:

    Ao gerar o certificado, você deve especificar o assunto, o endereço de e-mail e o nome de domínio ou o endereço IP.

  3. Para verificar se o certificado foi gerado e carregado corretamente, entre no comando operacional e especifique local-certificate sob o show security pki local-certificate gerenciamento da Web de HTTPS.

Certificados de exportação para um local especificado

Quando um certificado auto-assinado é gerado usando um comando PKI, o certificado recém-gerado é armazenado em um local predefinido (var/db/certs/comum/local).

Use o comando a seguir para exportar o certificado para um local específico (dentro do dispositivo). Você pode especificar o ID do certificado, nome de arquivo e tipo de formato de arquivo (DER/PEM):

Configure um certificado de CA raiz

Um CA pode emitir vários certificados na forma de uma estrutura de árvore. Um certificado raiz é o certificado mais alto da árvore, sendo a chave privada usada para sign outros certificados. Todos os certificados imediatamente abaixo do certificado raiz herdam a assinatura ou confiabilidade do certificado raiz. Isso é um pouco como a notarizing de uma identidade.

Para configurar um certificado de CA raiz:

  1. Obtenha um certificado de CA raiz (importando ou importando um)

    • Você pode gerar um certificado de CA raiz usando o Junos OS CLI.

    • Obtenha um certificado de um CA externo (não abordado neste tópico).

  2. Aplique o CA raiz em um perfil de proxy SSL.

Implementação da cadeia de certificados

O proxy de encaminhamento SSL oferece suporte à implementação da cadeia de certificados. Vamos discutir os conceitos da cadeia de certificados e como configurá-los em um firewall.

  • Autoridade de certificado (CA)— a CA é um terceiro confiável responsável por validar as identidades de entidades (como sites, endereços de e-mail, ou empresas ou pessoas individuais) e emite um certificado digital vinculando chaves criptográficas. Se sua organização possui um servidor CA, você se tornará seu próprio CA e usará um certificado autoassinado.

  • Certificado raiz — um certificado Root é um certificado emitido por um CA confiável. O certificado raiz é o certificado mais alto da árvore, sendo a chave privada usada para assinar outros certificados. Todos os certificados imediatamente abaixo do certificado raiz herdam a assinatura ou confiabilidade do certificado raiz. Esses certificados são usados para estabelecer conexão entre dois endpoints.

  • Certificado de CA intermediário — um certificado de CA intermediário é um certificado subordinado assinado pela raiz confiável especificamente para validar um certificado EE.

  • Cadeia de certificados — Uma cadeia de certificados é a lista ordenada de certificados que contém o certificado SSL, certificado intermediário e certificado raiz. Alguns CAs não assinam com seu certificado raiz, mas sim usam um certificado intermediário. Um CA intermediário pode assinar certificados em nome do certificado de CA raiz. O CA raiz assina o certificado intermediário, formando uma cadeia de confiança.

    O certificado intermediário deve ser instalado no mesmo servidor que o certificado SSL para que os dispositivos de conexão, como navegadores, aplicativos e dispositivos móveis possam confiar no certificado.

Quando você inicia uma conexão, o dispositivo de conexão verifica se o certificado é autêntico e é emitido por um CA confiável que está incorporado na loja confiável do navegador.

Se o certificado SSL não for de um CA confiável, então o dispositivo de conexão continua a verificar se o certificado SSL é emitido por um CA intermediário e este CA intermediário é assinado por um CA raiz. A verificação continua até que o dispositivo encontre o CA raiz. Se o dispositivo encontrar um CA raiz, uma conexão segura será estabelecida. Se o dispositivo não encontrar um CA raiz, a conexão será perdida e seu navegador da Web exibir uma mensagem de erro sobre um certificado inválido ou um certificado não confiável.

Suporte para a cadeia de certificados para iniciação de SSL

No modo proxy SSL, o servidor envia a cadeia de certificados completa, incluindo o certificado intermediário, ao cliente para a validação da cadeia de certificados.

No modo não proxy, durante a fase de iniciação do SSL, o cliente envia apenas o certificado de cliente para o servidor, se solicitado. Em seguida, o servidor importa a lista de CAs confiáveis para autenticar o certificado do cliente.

Durante a iniciação da SSL, os dispositivos geram cadeia de certificados e o enviam junto com o certificado de cliente para o servidor. A cadeia de certificados durante a fase de iniciação da SSL permite que o servidor valide a cadeia de certificados sem precisar importar CAs intermediários da cadeia.

O exemplo a seguir mostra como instalar a cadeia de certificados para permitir que os navegadores confiem em seu certificado.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar esse recurso.

Visão geral

Neste exemplo, você tem um domínio, exemplo.domain-1, e deseja comprar um certificado da XYZ-Authority para o seu domínio. No entanto, a XYZ-Authority não é um CA raiz e o navegador visitante confia apenas no certificado root-CA. Em outras palavras, seu certificado não está diretamente incorporado em seu navegador e, portanto, não é explicitamente confiável.

Neste caso, a confiança é estabelecida da seguinte maneira usando a cadeia de certificados (de certificados intermediários).

Topologia

Vamos tentar visualizar essa cadeia através da Figura 1. Essa figura mostra uma cadeia completa de certificados, desde o certificado de CA raiz até o certificado de usuário final. A cadeia termina com o certificado do usuário final.

Figura 1: Caminho de certificação do proprietário do certificado até o CA Certificate chain in PKI showing hierarchy: End User Certificate, Intermediate CAs 1-3, leading to Root Certificate Authority. raiz
Tabela 1: Detalhes da cadeia de certificados

Utilizador

Certificado de uso

Assinado por

Tipo

exemplo.domain-1

Certificado de usuário final

XYZ-Authority

Certificado de usuário final - aquele que você compra no CA

XYZ-Authority

Certificado 1

CA-1 intermediário

Certificado intermediário

CA-1 intermediário

Certificado 2

CA-2 intermediário

Certificado intermediário

CA-2 intermediário

Certificado-3

CA-3 intermediário

Certificado intermediário

CA-3 intermediário

Certificado-4

autoridade de exemplo raiz. Este é um CA raiz.

Certificado Root - aquele cujo certificado está diretamente incorporado em seu navegador, no qual o dispositivo pode, portanto, confiar explicitamente

Ao instalar seu certificado de usuário final para o exemplo do servidor.domain-1, você deve juntar todos os certificados intermediários e instalá-los junto com seu certificado de usuário final. A cadeia de certificados inclui todos os certificados que partem do Certificado 1 ao certificado Root-CA. Como o navegador da Web confia no CA raiz, ele também confia implicitamente em todos os certificados intermediários. Se a cadeia de certificados SSL for inválida ou quebrada, seu certificado não será confiável por alguns dispositivos.

Todos os certificados devem estar no formato PEM.

Quando você importa o arquivo de certificado concatenado para o dispositivo, o CA fornece um pacote de certificados encadeados que devem ser adicionados ao certificado de servidor assinado. O certificado do servidor deve aparecer antes dos certificados encadeados no arquivo combinado.

Certificado SSL: visão geral da configuração

Para configurar a cadeia de certificados SSL:

  • Compre um certificado SSL de um CA que inclua um certificado de assinatura e uma respectiva chave.

  • Configure um grupo de perfil de CA confiável.

  • Carregue o certificado de assinatura e a chave em seu dispositivo.

  • Carregue os CAs intermediários e raiz na memória PKI. Este arquivo de certificado contém todos os certificados de CA exigidos, um após o outro, no formato PEM.

  • Crie um perfil de CA confiável para o certificado ca intermediário ou raiz.

  • Configure seu dispositivo para usar o certificado de assinatura recebido do CA configurando e aplicando o perfil de proxy SSL a uma política de segurança. O proxy de encaminhamento SSL armazena essas informações da cadeia de certificados (nome do perfil do certificado CA) no respectivo perfil SSL. Como parte da implementação de políticas de segurança, são usados perfis SSL com as informações da cadeia de certificados e certificados de CA.

O processamento da cadeia de certificados inclui os seguintes processos:

  • O administrador carrega a cadeia de certificados e o certificado local (certificado de assinatura) no cache de certificados PKI.

  • A segurança de rede (nsd) envia uma solicitação ao PKI para fornecer as informações da cadeia de certificados para um certificado de assinatura configurado no perfil de proxy SSL.

Este exemplo pressupõe que você já tenha comprado um certificado SSL de um CA.

Configure a cadeia de certificados no dispositivo

Procedimento passo a passo Pls verifique o modelo de configuração do exemplo e posição/reescrita os títulos de acordo

Para configurar a cadeia de certificados:

  • Carregue o certificado local na memória PKI.

    A mensagem a seguir é exibida:

    Observe que o ID do certificado será usado na root-ca seção no perfil de proxy SSL.

  • Carregue o certificado de CA intermediário ou raiz na memória PKI.

    O perfil da CA inclui as informações do certificado usadas para autenticação. Ele inclui a chave pública que o proxy SSL usa ao gerar um novo certificado.

    Você pode anexar este certificado como uma cadeia de certificados.

  • Conecte o grupo de perfil ca ao perfil de proxy SSL. Você pode anexar o CA confiável um de cada vez ou carregar tudo em uma ação.

  • Aplique o certificado de assinatura como root-ca no perfil de proxy SSL.

  • Crie uma política de segurança e especifique os critérios de correspondência para a política. Como critérios de correspondência, especifique o tráfego para o qual você deseja habilitar o proxy SSL. Este exemplo pressupõe que você já criou zonas de segurança com base nos requisitos.

    O proxy de encaminhamento SSL armazena essas informações da cadeia de certificados (nome do perfil do certificado CA) em seu respectivo perfil SSL. Como parte da implementação de políticas de segurança, são usados perfis SSL com as informações da cadeia de certificados e certificados de CA.

    Você pode visualizar a cadeia de certificados no navegador de conexão,ou seja, no cliente.

Configuração de certificados digitais

Visão geral dos certificados digitais

Um certificado digital fornece uma maneira de autenticar usuários por meio de um terceiro confiável chamado CA. A CA valida a identidade de um titular de certificado e "assina" o certificado para atestar que ele não foi forjado ou alterado.

Um certificado inclui as seguintes informações:

  • A DN do proprietário. Uma DN é um identificador único e consiste em um nome totalmente qualificado, incluindo o nome comum (CN) do proprietário, a organização do proprietário e outras informações distintas.

  • A chave pública do dono.

  • A data em que o certificado foi emitido.

  • A data em que o certificado expira.

  • A DN da CA em emissão.

  • A assinatura digital da CA em emissão.

As informações adicionais em um certificado permitem que os destinatários decidam se aceitam o certificado. O destinatário pode determinar se o certificado ainda é válido com base na data de validade. O destinatário pode verificar se a CA é confiável pelo site com base na CA de emissão.

Com um certificado, um CA pega a chave pública do proprietário, assina a chave pública com sua própria chave privada e devolve isso ao proprietário como certificado. O destinatário pode extrair o certificado (contendo a assinatura do CA) com a chave pública do proprietário. Ao usar a chave pública da CA e a assinatura da CA no certificado extraído, o destinatário pode validar a assinatura do CA e o proprietário do certificado.

Ao usar certificados digitais, você primeiro envia uma solicitação para obter um certificado do seu CA. Em seguida, você configura certificados digitais e uma política de IKE de certificado digital. Por fim, você obtém um certificado assinado digitalmente por um CA.

Nota:

Os certificados sem um nome de assunto alternativo não são apropriados para serviços IPsec.

Obtenção de um certificado de um CA para um ES PIC

Os CAs gerenciam solicitações de certificados e emitem certificados aos dispositivos de rede IPsec participantes. Ao criar uma solicitação de certificado, você precisa fornecer as informações sobre o proprietário do certificado. As informações necessárias e seu formato variam entre CA.

Os certificados usam nomes no formato X.500, um DAP que fornece acesso lido e atualizado. O nome inteiro é chamado de DN. Consiste em um conjunto de componentes, que muitas vezes inclui uma CN (nome comum), uma organização (O), uma unidade de organização (OU), um país (C), uma localidade (L) e assim por diante.

Nota:

Para o registro dinâmico de certificados digitais, o Junos OS oferece suporte apenas ao SCEP.

Solicite um certificado digital da CA

Especifique uma URL para o servidor SCEP e o nome da CA cujo certificado você deseja: mycompany.com. O nome do arquivo que armazena o resultado é nome de arquivo 1. A saída "Certificado de CA recebido:" fornece a assinatura do certificado, o que permite verificar (offline) se o certificado é genuíno.

Nota:

Inicialmente, cada roteador é inicialmente inscrito manualmente com um CA.

Gere um keypair privado e público para certificados digitais para um ES PIC

Para gerar uma chave privada e pública, emita o seguinte comando:

name especifica o nome de arquivo em que o dispositivo armazena as chaves públicas e privadas.

key-size podem ser 512, 1024, 1596 ou 2048 bytes. O tamanho padrão da chave é 1024 bytes.

type pode ser rsa ou dsa. O padrão é RSA.

Nota:

Quando você usa o SCEP, o Junos OS só oferece suporte ao RSA.

O exemplo a seguir mostra como gerar um keypair privado e público:

Solicitando um certificado digital de CA

Solicite um certificado digital da CA

Você pode solicitar um certificado digital da CA on-line ou manualmente. Para solicitar um certificado digital on-line de um CA ou ra usando SCEP, emita o request security pki ca-certificate enroll ca-profile ca-profile-name comando.

Se você tiver obtido o certificado digital da CA manualmente por e-mail ou outro mecanismo de OOB, deverá carregá-lo manualmente. Para instalar manualmente um certificado em seu roteador, emita o request security pki ca-certificate load ca-profile profile_name filename /path/filename.cert comando.

Gerar um keypair público-privado

Um keypair é um elemento crítico da implementação de um certificado digital. A chave pública está incluída no certificado digital local e a chave privada é usada para descriptografar dados recebidos de pares. Para gerar um keypair privado-público, emita o request security pki generate-key-pair certificate-id certificate-id-name comando.

Gerar e inscrever um certificado digital local

Você pode gerar e inscrever um certificado digital local on-line ou manualmente. Para gerar e inscrever um certificado local on-line usando o SCEP, emita o request security pki local-certificate enroll comando. Para gerar uma solicitação de certificado local manualmente no formato PKCS-10, emita o request security pki generate-certificate-request comando.

Se você criar a solicitação de certificado local manualmente, você também deve carregar o certificado manualmente. Para instalar manualmente um certificado em seu roteador, emita o request security pki local-certificate load comando.

Aplicar certificado digital local a uma configuração IPsec

Para ativar um certificado digital local, configure a proposta do IKE de usar certificados digitais em vez de chaves pré-compartilhadas, consulte o certificado local na política de IKE e identifique o CA ou RA no conjunto de serviços. Para habilitar a proposta de IKE para certificados digitais, inclua a rsa-signatures declaração no nível de [edit services ipsec-vpn ike proposal proposal-name authentication-method] hierarquia. Para fazer referência ao certificado local na política de IKE, inclua a local-certificate declaração no nível de [edit services ipsec-vpn ike policy policy-name] hierarquia. Para identificar o CA ou RA no conjunto de serviços, inclua a trusted-ca declaração no nível de [edit services service-set service-set-name ipsec-vpn-options] hierarquia.

Configure o reencaminhamento automático de certificados digitais

Você pode configurar o reenrollamento automático para certificados digitais. Esse recurso não é habilitado por padrão. Para configurar o reenrollamento automático para certificados digitais, inclua a auto-re-enrollment declaração no nível de hierarquia [editar pki de segurança]:

Configure certificados digitais para um ES PIC

Os Certificados digitais fornecem uma maneira de autenticar usuários por meio de um terceiro confiável chamado CA. A CA valida a identidade de um titular de certificado e "assina" o certificado para atestar que ele não foi forjado ou alterado.

Para definir a configuração de certificado digital para uma interface de serviço de criptografia, inclua as seguintes declarações nos [edit security certificates] níveis de hierarquia e [edit security ike] hierarquia:

As tarefas para configurar certificados digitais para ES PICs são:

Configure as propriedades de CA para um ES PIC

Para configurar um CA e suas propriedades para um PIC ES, inclua as seguintes declarações no nível hierárquico [edit security certificates] :

ca-profile-name é o nome do perfil da CA.

Execute as seguintes tarefas para configurar as propriedades da CA:

Especifique o nome ca

Se você estiver se inscrevendo em um CA usando o SCEP, você precisa especificar o nome ca (identidade ca) que é usado na solicitação de certificado, além da URL para o servidor SCEP.

Para especificar o nome da identidade ca, inclua a ca-name declaração no nível de [edit security certificates certification-authority ca-profile-name] hierarquia:

ca-identity especifica a identidade ca para usar na solicitação do certificado. Normalmente é o nome de domínio da CA.

Configure o CRL

Um CRL contém uma lista de certificados digitais que foram cancelados antes da data de validade. Quando um peer participante usa um certificado digital, ele verifica a assinatura e a validade do certificado. Ele também adquire o CRL emitido mais recentemente e verifica se o número de série do certificado não está nesse CRL.

Para configurar o CRL, inclua a crl declaração e especifique o arquivo do qual ler o CRL no nível de [edit security certificates certification-authority ca-profile-name] hierarquia:

Configure o tipo de codificação que seu CA oferece suporte

Por padrão, a codificação é definida como binária. A codificação especifica o formato de arquivo usado para as declarações e local-key-pair declaraçõeslocal-certificate. Por padrão, o formato DER binário está habilitado. PEM é um formato codificado base ASCII 64. Verifique com seu CA para determinar quais formatos de arquivo ele suporta.

Para configurar o formato de arquivo que seu CA oferece suporte, inclua a encoding declaração e especifique um formato binário ou PEM no nível de [edit security certificates certification-authority ca-profile-name] hierarquia:

Especifique uma URL de inscrição

Você especifica o local da CA onde seu roteador ou switch envia solicitações de inscrição de certificados baseadas em SCEP. Para especificar a localização do CA nomeando a URL ca, inclua a enrollment-url declaração no nível de [edit security certificates certification-authority ca-profile-name] hierarquia:

url-name é a localização da CA. O formato é http://ca-name, onde ca-name está o nome de DNS de host ca ou endereço IP.

Especifique um arquivo para ler o certificado digital

Para especificar o arquivo do qual o dispositivo lê o certificado digital, inclua a file declaração e especifique o nome de arquivo do [edit security certificates certification-authority ca-profile-name] certificado no nível de hierarquia:

Especifique uma URL LDAP

Se seu CA armazena seu CRL atual em seu servidor LDAP, você pode verificar opcionalmente sua lista de CA CRL antes de usar um certificado digital. Se o certificado digital aparecer no CA CRL, seu roteador ou switch não poderá usá-lo. Para acessar seu CA CRL, inclua a ldap-url declaração no [edit security certificates certification-authority ca-profile-name] nível hierárquico:

url-name é o nome do servidor CA LDAP. O formato é ldap://server-name, onde server-name está o nome de DNS de host ca ou endereço IP.

Configure o tamanho do cache

Por padrão, o tamanho do cache é de 2 MB. Para configurar o tamanho total do cache para certificados digitais, inclua a cache-size declaração no nível de [edit security certificates] hierarquia:

bytes é o tamanho do cache para certificados digitais. A faixa pode ser de 64 a 4.294.967.295 bytes.

Nota:

Recomendamos que você limite o tamanho do seu cache a 4 MB.

Configure o cache negativo

O cache negativo armazena resultados negativos e reduz o tempo de resposta para respostas negativas. Ele também reduz o número de mensagens que são enviadas para o servidor remoto. Manter um estado de cache negativo permite que o sistema devolva rapidamente uma condição de falha quando uma tentativa de busca é revarinada. Sem um estado de cache negativo, uma nova tentativa exigiria a falta de resposta do servidor remoto, embora o sistema já saiba que o servidor remoto não está respondendo.

Por padrão, o cache negativo é de 20 segundos. Para configurar o cache negativo, inclua a cache-timeout-negative declaração no nível de [edit security certificates] hierarquia:

seconds é o tempo para o qual um certificado de CA ou roteador com falha está presente no cache negativo. Ao procurar certificados com uma identidade ca correspondente (nome de domínio para certificados ou nome de domínio ca e serial para CRLs), o cache negativo é pesquisado primeiro. Se uma entrada for encontrada no cache negativo, a pesquisa falhará imediatamente.

Nota:

Configurar um grande valor de cache negativo pode torná-lo suscetível a um ataque DoS.

Configure o número de retries de inscrição

Por padrão, o número de retries de inscrição é definido para 0, um número infinito de retries. Para especificar quantas vezes um roteador ou switch será re-enviado uma solicitação de certificado, inclua a enrollment-retry declaração no [edit security certificates] nível de hierarquia:

attempts é o número de retries de inscrição (de 0 a 100).

Configure o número máximo de certificados peer

Por padrão, o número máximo de certificados de peer a serem armazenados em cache é 1024. Para configurar o número máximo de certificados de peer a serem armazenados em cache, inclua a maximum-certificates declaração no nível de declaração da [edit security certificates] hierarquia:

number é o número máximo de certificados de peer a serem armazenados em cache. A faixa é de 64 a 4.294.967.295 certificados de peer.

Configure o comprimento do caminho para a hierarquia de certificados

Os CAs podem emitir certificados para outros CAs. Isso cria uma hierarquia de certificação semelhante a uma árvore. O CA mais confiável da hierarquia é chamado de âncora de confiança. Às vezes, a âncora de confiança é o CA raiz, que geralmente é assinado por si mesmo. Na hierarquia, cada certificado é assinado pela CA imediatamente acima dele. Uma exceção é o certificado CA raiz, que normalmente é assinado pela própria CA raiz. Em geral, uma cadeia de vários certificados pode ser necessária, compreendendo um certificado do proprietário de chave pública (a entidade final) assinado por um CA, e certificados zero ou mais adicionais de CAs assinados por outros CAs. Essas cadeias, chamadas de caminhos de certificação, são necessárias porque um usuário de chave pública só é inicializado com um número limitado de chaves públicas garantidas da CA.

O comprimento do caminho refere-se a um caminho de certificados de um certificado para outro, com base na relação de um CA e seus "filhos". Ao configurar a path-length declaração, você especifica a profundidade máxima da hierarquia para validar um certificado do certificado de CA raiz confiável ao certificado em questão. Para obter mais informações sobre a hierarquia de certificados, consulte o perfil do certificado de infraestrutura de chaves públicas (CRL) RFC 3280, Internet X.509.

Por padrão, o comprimento máximo do caminho do certificado é definido para 15. A âncora raiz é 1.

Para configurar o comprimento do caminho, inclua a path-length declaração no nível de [edit security certificates] hierarquia:

certificate-path-length é o número máximo de certificados para o comprimento do caminho do certificado. A faixa é de 2 a 15 certificados.