Trabalhei em escritórios onde, na rede local, você simplesmente digitava algo https://someserviceem um navegador da web e era levado até lá. (A menos que eu me lembre errado. Nesse caso, por favor, me avise.)
Parecia o tipo de coisa que seria um projeto interessante, desafiador e educativo para minha casa. Sei que não preciso fazer isso, mas quero muito saber como funciona.
Recentemente, instalei o OpenWrt em um Raspberry Pi e o estou usando como roteador. Ele gerencia, entre outras coisas, meu DNS local. Gostaria também que esse servidor OpenWrt fosse minha autoridade certificadora.
Segui este tutorial (depois de experimentar vários tutoriais). E agora tenho os seguintes arquivos, alguns no servidor web da minha rede local, com o nome site, e outros com o nome routerda própria autoridade certificadora, no roteador:
- A chave privada do site:
site.key - A solicitação de assinatura do certificado para o site:
site.csr - O certificado assinado para o site:
site.crt - O armazenamento de chaves privadas para a autoridade de certificação:
router.key - E um certificado raiz:
router.pem
E alguns outros que foram usados para criar os arquivos acima.
Mas o que eu gostaria de saber é: o servidor nginx na máquina cliente do site está configurado para usar o certificado que produzi para ele; como posso fazer com que esse certificado verifique com o roteador se (pelo menos de acordo com o roteador) o site é real? Adicionei o certificado raiz a /etc/ssl/certs, com o link de hash correspondente. De acordo com o teste no tutorial , o certificado está presente no roteador.
Em nenhum tutorial encontrei nada sobre um computador em uma rede solicitando a outro que verifique se os dados são confiáveis. Novamente, a ideia é informar ao roteador que esses dados específicos são confiáveis, o que deve ser suficiente para qualquer pessoa que esteja por trás do roteador.
Se isso for possível, qual etapa estou esquecendo? Se não for possível, por favor, me avise.
Certificados não tornam um site "real". Mesmo que você use
https://someserviceem vez dohttp://, ainda é o DNS – e não os certificados – que faz osomeservicenome existir.Mais comumente, isso é obtido publicando uma opção DHCP com seu nome de domínio DNS interno (opção 15 para um único sufixo e/ou opção 119 para múltiplos), de modo que quando o navegador for instruído a se conectar
someservice, ele realmente faça uma pesquisa de DNSsomeservice.example.comnos bastidores.Após o estabelecimento da conexão TCP, o HTTPS (TLS) usa o certificado para verificar se o servidor acessado está autorizado a atuar sob esse nome. Quando sua CA emite um certificado para o nome de assunto "someservice", é isso que autoriza o detentor do certificado (bem, da chave privada) a atuar sob esse nome.
Não há necessariamente nenhuma "verificação com o roteador" nesta fase – o roteador só foi envolvido na emissão do certificado, mas os nomes para os quais o certificado é válido já estão incorporados no próprio certificado (alterá-los exigiria a emissão de um novo certificado), e as assinaturas até a CA raiz são verificadas independentemente pelo navegador ou cliente TLS.
Tecnicamente, o cliente (navegador) pode entrar em contato com o roteador para verificar se o certificado não foi revogado, mas sua CA interna provavelmente não tem isso configurado, então é seguro dizer que não há nenhum "check-in" acontecendo.
Para esclarecer, a autoridade certificadora não é tarefa de um roteador – é uma função completamente separada que, no seu caso, por acaso é executada na mesma máquina. Normalmente, a CA estaria hospedada em um local bem mais protegido.
Isso não é suportado. Na verdade, se fosse possível, basicamente anularia o propósito do TLS e dos certificados: eles existem em parte para proteger contra a rede; portanto, se os hosts confiassem cegamente na rede à qual estão conectados, seria trivial anular o TLS, tornando-o inútil.
(Pelo mesmo motivo, o nome que os navegadores esperam encontrar nos certificados é estritamente o que foi especificado na URL e não é afetado pela sufixação automática das opções de DHCP mencionadas anteriormente.)
As únicas situações semelhantes, como o Active Directory em redes corporativas implantando uma CA em todas as máquinas, já têm uma relação de confiança preexistente: o ato manual de "associar" uma máquina ao domínio (o nome do domínio é inserido manualmente, não detectado automaticamente) significa inscrever-se para configuração e gerenciamento centralizados daquele domínio, de modo que as autoridades de certificação internas são frequentemente publicadas como parte disso.
Os links de hash em /etc/ssl/certs são específicos do OpenSSL. Você deve sempre seguir as instruções da própria distribuição, por exemplo, adicionando-as
/usr/local/share/ca-certificatespara Debian/Ubuntu, para que as ferramentas possam copiar o certificado raiz para /etc/ssl/certs e para quaisquer outros locais onde o software possa procurar (por exemplo, as ferramentas podem gerar novamente o pacote único "cert.pem" para GnuTLS).Ele só é relevante quando o próprio roteador está agindo como cliente TLS.