Eu gostaria de implementar um site interno para nossa empresa, com autenticação de certificado usada sempre que possível. Eu corri para (e tentei) vários exemplos onde um cria seu próprio auto-assinado CA para tudo, mas isso não é o que eu quero.
Por motivos de segurança, não quero desenvolvê-lo com nosso certificado real de site curinga - quanto menos servidores tiverem o arquivo de chave privada, melhor. O que eu gostaria de fazer é isto:
a) Use uma CA auto-assinada e assine o certificado SSL usado para HTTPS e adicione-o ao meu armazenamento de certificados do sistema. Para os fins desta aventura, esta seria a primeira CA, ou ca-1 .
b) Use a CA que emitiu nossos certificados S / MIME para autenticação (eles são o tipo correto!) Os certificados para esse fim (autenticação do cliente) seriam emitidos pela segunda autoridade de certificação, ou ca-2 .
Eventualmente, após o término do desenvolvimento, planejo substituir o site e o certificado ca-1 por a) pelos do nosso provedor de certificado SSL para conveniência e segurança do usuário final, mas para fins de desenvolvimento da autenticação do usuário, gostaria de usar meu certificado real, porque somente a chave pública será armazenada em servidores de desenvolvimento - e, do ponto de vista do desenvolvimento, é mais útil trabalhar com a coisa real.
Do ponto de vista da possibilidade de escolher CAs separadas para SSL / TLS e autenticação, eu também estaria interessado em descobrir como fazer isso funcionar. (Isso é apenas uma boa curiosidade à moda antiga.)
Minha configuração de HTTPd ( /etc/httpd/conf.d/site.conf ) parece um pouco com isto:
<VirtualHost *:443>
ServerName site
DocumentRoot /srv/site/www
SSLEngine On
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLHonorCipherOrder On
SSLCertificateFile /etc/pki/tls/certs/site-1.crt
SSLCertificateKeyFile /etc/pki/tls/private/site-1.key
SSLCertificateChainFile /etc/pki/tls/certs/ca-1.crt
SSLCACertificateFile /etc/pki/tls/certs/ca-2.crt
</VirtualHost>
<Directory /srv/site/www>
Require all granted
</Directory>
<Directory /srv/site/www/secret>
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars
SSLVerifyClient require
Require all granted
</Directory>
<VirtualHost *:80>
ServerName site
RewriteEngine On
RewriteRule ^(/.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>
Eu também estou ciente de que é necessário usar um restorecon -RvF /srv para o SELinux (e eu fiz isso.)
A idéia é ter uma página inicial aberta, para que os gráficos possam ser mostrados até mesmo para usuários não autenticados (junto com um lembrete útil para instalar um certificado no computador antes de tentar novamente, em vez de simplesmente mostrar uma página 403 Forbidden . ) O conteúdo no diretório /secret dentro da raiz do documento, no entanto, deve ser mostrado apenas para usuários autenticados. Uma pequena quantidade de PHP na página do spash detectaria a disponibilidade de conteúdo em / secret e redirecionaria o usuário automaticamente.
O plano é fazer com que o HTTPd autentique apenas usuários que tenham um certificado assinado por nossa CA (que seria ca-2.crt neste exemplo) e o aplicativo Web teria que verificar se a organização (O) no certificado é nosso, claro. Após esse ponto, assim que o aplicativo estiver satisfeito sobre a CA e o O (organização), o CN (nome comum) no certificado do usuário, compartilhado por seu navegador, será usado para autenticá-los, possivelmente usando a UO (unidade organizacional ) para segregar direitos de acordo com o departamento.
Como muitas ideias, esta parecia uma boa - à primeira vista, de qualquer maneira. Na prática, no entanto, não funcionou da forma pretendida: meu navegador simplesmente me mostra um erro 403 Forbidden , aparentemente nada em /var/log/httpd aludindo sobre o motivo. O conteúdo fora de /secret , claro, funciona bem.
Os site-1.crt e site-1.key pertencem a ca-1.crt . ca-2.crt seria a CA que assinou a chave privada abrigada no meu smartcard (que meu sistema operacional hospedeiro conhece: já o usei para assinar e criptografar e-mails, fazer login em servidores via SSH, etc., então eu tenho certeza que funciona.)
Eu também estaria preparado para aceitar ter que adicionar as chaves públicas de todos os usuários a uma lista, com a qual o HTTPd se autenticaria. Não é tão conveniente, mas certamente seguro (e também permitiria acesso mais refinado, em vez de simplesmente permitir que toda a empresa - ou um departamento inteiro - acessasse o recurso.)
Qualquer ajuda nesta aventura seria muito apreciada.