Em
um de nossos artigos anteriores, falamos sobre a importância da autenticação de dois fatores nos portais corporativos da empresa. Na última vez, demonstramos como configurar a autenticação segura no servidor web IIS.
Nos comentários, fomos solicitados a escrever instruções para os servidores Web mais comuns para Linux - nginx e Apache.
Você perguntou - nós escrevemos.
O que você precisa para começar?
- Qualquer distribuição Linux moderna. Fiz uma configuração de teste no MX Linux 18.2_x64. Certamente não é uma distribuição de servidores, mas dificilmente existem diferenças para o Debian. Para outras distribuições, os caminhos para as bibliotecas / configurações podem variar um pouco.
- Token. Continuamos a usar o modelo PKI Rutoken EDS , ideal para desempenho de alta velocidade em aplicativos corporativos.
- Para trabalhar com o token no Linux, você precisa instalar os seguintes pacotes:
libccid libpcsclite1 pcscd pcsc-tools opensc
Escrita de certificado
Nos artigos anteriores, contávamos com o fato de que certificados de servidor e cliente seriam emitidos usando o Microsoft CA. Mas como estamos configurando tudo no Linux, ao mesmo tempo falaremos sobre uma maneira alternativa de emitir esses certificados - sem sair do Linux.
Usaremos o XCA como uma CA (
https://hohnstaedt.de/xca/ ), disponível em qualquer distribuição moderna do Linux. Todas as ações que executaremos no XCA também podem ser executadas no modo de linha de comando, usando os utilitários OpenSSL e pkcs11-tool, mas por uma questão de simplicidade e clareza, não iremos dar a eles neste artigo.
Introdução
- Instalar:
$ apt-get install xca
- E execute:
$ xca
- Criamos nosso banco de dados para CA - /root/CA.xdb
Recomendamos que você armazene o banco de dados da Autoridade de Certificação em uma pasta à qual somente o administrador tenha acesso. Isso é importante para proteger as chaves privadas dos certificados raiz, que são usadas para assinar todos os outros certificados.
Criar chaves e certificado CA raiz
A infraestrutura de chave pública (PKI) é baseada em um sistema hierárquico. O ponto central desse sistema é a autoridade de certificação raiz ou a CA raiz. Seu certificado deve ser criado primeiro.
- Criamos a chave privada RSA-2048 para a CA. Para fazer isso, na guia Chaves Privadas , clique em Nova Chave e selecione o tipo apropriado.
- Defina um nome para o novo par de chaves. Eu chamei isso - CA Key.
- Escrevemos o próprio certificado CA, usando o par de chaves criado. Para fazer isso, vá para a guia Certificados e clique em Novo certificado .
- Certifique-se de escolher o SHA-256 , porque o uso do SHA-1 não pode mais ser considerado seguro.
- Como modelo, certifique-se de selecionar CA [padrão]. Não se esqueça de clicar em Aplicar tudo , caso contrário, o modelo não se aplica.
- Na guia Assunto , selecione nosso par de chaves. Lá você pode preencher todos os principais campos do certificado.
Criar chaves e certificado do servidor https
- Da mesma forma, criamos a chave privada RSA-2048 para o servidor, eu a chamei - Chave do Servidor.
- Ao criar o certificado, selecionamos que o certificado do servidor deve ser assinado no certificado da CA.
- Não esqueça de escolher o SHA-256 .
- Como modelo, selecione [padrão] HTTPS_server . Clique em Aplicar tudo .
- Em seguida, na guia Assunto , selecione nossa chave e preencha os campos obrigatórios.

Criamos chaves e o certificado para o usuário
- A chave privada do usuário será armazenada em nosso token. Para trabalhar com ele, você precisa instalar a biblioteca PKCS # 11 em nosso site. Para distribuições populares, distribuímos pacotes prontos aqui - https://www.rutoken.ru/support/download/pkcs/ . Também temos montagens para arm64, armv7el, armv7hf, e2k, mipso32el, que podem ser obtidas em nosso SDK - https://www.rutoken.ru/developers/sdk/ . Além de assemblies para linux, também existem assemblies para macOS, freebsd e android.
- Adicione o novo provedor PKCS # 11 ao XCA. Para fazer isso, vá para o menu Opções na guia Provedor PKCS # 11 .
- Clique em Incluir e selecione o caminho para a biblioteca PKCS # 11. No meu caso, é \ usr \ lib \ librtpkcs11ecp.so.
- Precisamos de um token formatado Rutoken EDS PKI. Faça o download do utilitário rtAdmin - https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
- Realizamos
$ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u <PIN- >
- Como o tipo de chave que selecionamos - a tecla RSA-2048 no PKI Rutoken EDS. Chamei essa chave de chave de cliente.
- Digite o código PIN. E estamos aguardando a conclusão da geração de hardware do par de chaves
- Criamos o certificado para o usuário por analogia com o certificado do servidor. Desta vez, selecione o modelo HTTPS_client [padrão] e não se esqueça de clicar em Aplicar tudo .
- Na guia Assunto , insira as informações do usuário. Respondemos afirmativamente à solicitação para salvar o certificado para o token.
Como resultado, na guia
Certificados no XCA, você deve obter algo parecido com isto.
Esse conjunto mínimo de chaves e certificados é suficiente para começar a configurar os servidores diretamente.
Para configurar, precisamos exportar o certificado da CA, o certificado do servidor e a chave privada do servidor.
Para fazer isso, selecione a entrada desejada na guia apropriada no XCA e clique em
Exportar .
Nginx
Como instalar e executar um servidor nginx, não vou escrever - há artigos suficientes na Internet sobre esse assunto, sem mencionar a documentação oficial. Vamos começar a configurar a autenticação HTTPS e de token de dois fatores.
Adicione as seguintes linhas à seção do servidor em nginx.conf:
server { listen 443 ssl; ssl_verify_depth 1; ssl_certificate /etc/nginx/Server.crt; ssl_certificate_key /etc/nginx/ServerKey.pem; ssl_client_certificate /etc/nginx/CA.crt; ssl_verify_client on; }
Uma descrição detalhada de todos os parâmetros relacionados à configuração do SSL no nginx pode ser encontrada aqui -
https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificateDescreverei apenas brevemente aqueles que eu mesmo perguntei:
- ssl_verify_client - indica que a cadeia confiável de certificados precisa ser verificada.
- ssl_verify_depth - Determina a profundidade da pesquisa de certificado raiz confiável na cadeia. Como nosso certificado de cliente é imediatamente assinado no certificado raiz, a profundidade é definida como 1. Se o certificado de usuário for assinado em uma CA intermediária, 2 deverão ser especificados neste parâmetro e assim por diante.
- ssl_client_certificate - especifica o caminho para o certificado raiz confiável, usado para verificar a confiança no certificado do usuário.
- ssl_certificate / ssl_certificate_key - indica o caminho para o certificado / chave privada do servidor.
Não esqueça de executar o nginx -t para verificar se não há erros de digitação na configuração e se todos os arquivos são necessários e assim por diante.
E na verdade tudo! Como você pode ver, a configuração é muito simples.
Verificando o trabalho no Firefox
Como estamos fazendo tudo completamente no Linux, assumiremos que nossos usuários também trabalham no Linux (se tiverem Windows,
consulte as instruções para configurar navegadores no artigo anterior .
- Iniciamos o Firefox.
- Vamos tentar fazer login sem um token no início. Temos a seguinte imagem:
- Vá para about: preferências # privacidade e vá para Dispositivos de Segurança ...
- Clique em Carregar para adicionar o novo driver de dispositivo PKCS # 11 e especifique o caminho para o nosso librtpkcs11ecp.so.
- Para verificar se o certificado está visível, você pode ir para o Gerenciador de Certificados . Você é solicitado a fornecer um código PIN. Após a entrada correta, você pode verificar se, na guia Seus Certificados, nosso certificado com um token apareceu.
- Agora vamos com o token. O Firefox sugere a escolha de um certificado que será selecionado no servidor. Escolha nosso certificado.
- LUCRO!
A configuração é feita uma vez e, como você pode ver na janela de solicitação de certificado, podemos salvar nossa opção. Depois disso, cada vez que você entra no portal, precisamos apenas inserir um token e inserir o código PIN do usuário que foi definido durante a formatação. Após essa autenticação, o servidor já sabe qual usuário efetuou login e não é mais possível fazer janelas adicionais para verificação, mas deixa o usuário entrar imediatamente em sua conta pessoal.
Apache
Como no nginx, ninguém deve ter problemas para instalar o apache. Se você não sabe como instalar este servidor web, basta usar a documentação oficial.
E estamos começando a configurar nossa autenticação HTTPS e dois fatores:
- Primeiro você precisa ativar o mod_ssl:
$ a2enmod ssl
- E ative as configurações padrão do site HTTPS:
$ a2ensite default-ssl
- Agora edite o arquivo de configuração: /etc/apache2/sites-enabled/default-ssl.conf:
SSLEngine on SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/sites-enabled/Server.crt SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt SSLVerifyClient require SSLVerifyDepth 10
Como você pode ver, os nomes dos parâmetros quase coincidem com os nomes dos parâmetros no nginx, portanto não os explicarei. Novamente, qualquer pessoa interessada nos detalhes - bem-vindo à documentação.
Agora reinicie nosso servidor:
$ service apache2 reload $ service apache2 restart
Como você pode ver, configure a autenticação de dois fatores em qualquer servidor da Web, no Windows e no Linux, no máximo em uma hora. E a configuração dos navegadores leva cerca de 5 minutos. Muitas pessoas pensam que configurar e trabalhar com autenticação de dois fatores é difícil e incompreensível. Espero que nosso artigo seja pelo menos um pouco, mas desmascarando esse mito.