Configurar autenticação mútua

A autenticação mútua estabelece confiança por meio da troca de certificados SSL (Secure Sockets Layer).

Durante o handshake de SSL, o servidor apresenta seu certificado ao cliente. Posteriormente, dependendo da configuração do servidor, ele pode solicitar um certificado do cliente. O servidor e o cliente executam procedimentos de validação de certificado para garantir a autenticidade e a integridade dos certificados apresentados.

Após uma validação bem-sucedida, se trocam confirmações antes de iniciar a conexão HTTPS.

Os administradores fazem o trabalho preliminar de configurar o armazenamento de chaves do cliente e gerar certificados antes que as solicitações de certificação sejam atendidas.

Aviso:

Este recurso permite a autenticação mútua somente em conexões https de saída.

Criação do armazenamento de chaves

No momento|, a instância oferece suporte ao carregamento de um arquivo de armazenamento de chaves Java, que contém uma chave privada e um par de certificados públicos. O certificado público inclui a cadeia completa, inclusive o certificado raiz.

Para configurar o armazenamento de chaves do cliente:

• Você precisa de um certificado assinado por uma autoridade de certificação (CA) de confiança.
• Seu provedor de endpoint de API pode ajudar você a gerar o armazenamento de chaves.

Se você precisar gerar o armazenamento de chaves, o processo envolverá várias etapas usando comandos de interface de linha de comando para gerar um novo arquivo de armazenamento de chaves, criar uma solicitação de assinatura de certificado (CSR) e importar certificados assinados. Antes de importar o certificado primário para o seu domínio, é necessário importar primeiro quaisquer certificados raiz ou intermediários. Veja uma instrução detalhada:

1. Gere um armazenamento de chaves Java e um par de chaves.

   keytool -genkey -alias mydomain -keyalg RSA -keystore my.keystore

2. Gere um CSR para um armazenamento de chaves Java existente.

   keytool -certreq -alias mydomain -keystore my.keystore -file mydomain.csr

3. Envie o CSR para a autoridade de assinatura do CA assinar e retornar os arquivos de certificado, o que inclui certificados intermediários e raiz junto com o certificado assinado.
4. Importe um certificado CA de autoridade de certificação raiz ou intermediária para um armazenamento de chaves Java existente.

   keytool -import -trustcacerts -alias root -file Thawte.crt -keystore my.keystore

   Nota:

   Você pode agrupar todos os certificados em um arquivo e importar. Esta é a opção preferencial. Se você fizer isso, poderá ignorar a etapa 5

   keytool -import -alias mydomain -file merged.crt -keystore my.keystore

5. Importe um certificado primário assinado para um armazenamento de chaves Java existente.

   keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore my.keystore

Configuração do armazenamento de chaves

Agora que o armazenamento de chaves foi criado, ele pode ser carregado para a tabela Certificados. Em Definição do Sistema > Certificados página, clique em Novo e defina os seguintes campos:

• Insira um Nome de certificado.
• Armazene o armazenamento de chaves como Ativo.
• Defina Tipo = Java Key Store.
• Forneça uma senha de armazenamento de chaves. Esta é a senha usada para criar o armazenamento de chaves.

Clique em Enviar para criar a entrada de armazenamento de chaves Java.

Figura 1. Armazenamento de chave

Especificação de um certificado de servidor confiável

Durante uma conexão SSL de saída (que é uma chamada de serviço Web HTTPS), é possível especificar um certificado fornecido pelo provedor de serviços para garantir a validade do provedor de serviços durante a conexão SSL. Por exemplo, um navegador que tenta se conectar a um serviço seguro com identificação por um certificado.

Ao carregar o certificado de servidor confiável, ServiceNow garante que o serviço ao qual ele está se conectando é válido e seguro.

Crie uma nova entrada de certificado com o tipo de "Certificado de armazenamento confiável" e anexe um certificado formatado DER ou copie e cole seu formato PEM no campo Certificado PEM.

Perfil de Protocolo

Figura 2. Troca de certificados

• Quando um cliente solicita o certificado do servidor para autenticação, uma solicitação de assinatura de certificado (CSR) é gerada.
• Para responder a um CSR, o servidor gera duas chaves criptográficas exclusivas: uma pública, usada para criptografar mensagens para o servidor e outra privada, usada para descriptografar mensagens. Ambas as chaves são mantidas no armazenamento de chaves.
• As chaves são usadas para descriptografar as mensagens seguras do cliente para que possam ser lidas pelo servidor. Qualquer conexão de saída a resultar em HTTPS verifica a certificação ao validar o armazenamento de chaves oferecendo sua certificação pública e usa os certificados de armazenamento de confiança para, por sua vez, verificar a confiança mútua.
• Para concluir o link seguro entre o cliente e o servidor, o servidor combina o certificado à chave privada correspondente. Uma vez que somente o servidor tem acesso à chave privada, ele pode descriptografar os dados do cliente.

Este é um exemplo de um comando que registra o MYHTTPS com a fábrica de soquetes com.glide.certificates.DBKeyStoreSocketFactory na porta 443. A fábrica de armazenamento de chaves do banco de dados é usada durante o processo de troca de SSL para oferecer um certificado de cliente para autenticação mútua.

glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory"
glide.httpclient.protocol.myhttps.port = "443"

A configuração acima afeta qualquer URL myhttps://host.domain.com/target de saída para uso da fábrica de soquete personalizada e troca de certificados durante o SSL.

Nota:

Substituir a fábrica de soquetes do protocolo HTTPS padrão afeta todas as conexões HTTPS de saída. Em geral, isso não é desejável.

O servidor responde com o envio de um certificado. Este é um certificado aceito pelo cliente? Em caso afirmativo, uma mensagem será enviada ao servidor, que aceita o certificado, e um canal seguro será iniciado. Se a certificação não for aceita, poderá significar que a autoridade raiz é necessária para a certificação.