☰

Certificado SSL para conexão ao servidor doméstico através do socat

tag-icon • tag-icon ssl raspberry-pi ipv6 letsencrypt nextcloud
Certificado SSL para conexão ao servidor doméstico através do socat

Estou executando o Nextcloud em um Raspberry Pi em casa. Ele atualiza seu endereço IPv6 em um nome de host no provedor DynDNS spDYN.de. No entanto, como meu provedor oferece apenas conexões IPv6 (usando DS-Lite para IPv4), só posso acessar diretamente o nome do host de outras conexões IPv6 e preciso usar um postmapper IPv4-IPv6 para conectar-me a ele a partir de redes IPv4.

Isso não é grande coisa, pois meu site está hospedado em um servidor que possui conexões IPv6 e IPv4, então usei socat de acordo comeste tutorialpara configurar um portmapper no servidor que hospeda meu site, roteando uma porta específica do domínio do meu site para a porta 443 no nome de host DNS dinâmico. Isso funciona perfeitamente, mas cria um problema com os certificados SSL:

No RasPi, usei o certbot para criar um certificado "Vamos criptografar" para o nome de host DNS dinâmico, que funciona perfeitamente e a conexão é mostrada como segura. Além disso, no meu servidor web, criei um certificado semelhante para o domínio que estou usando para o portmapper, que por si só funciona. Porém, quando acesso o domínio com a porta encaminhada específica para acessar o RasPi, o navegador continua mostrando a URL que contém meu domínio, mas recebe o certificado do RasPi que foi emitido para o nome de host DNS dinâmico. Como consequência, é claro, a verificação de segurança falha porque o certificado é emitido para o domínio “errado”. Já tentei emitir um certificado no meu RasPi para o meu domínio, mas ele não informa que sou "não autorizado".

Como posso resolver esse problema? Onde devo configurar que tipo de certificado?

Responder1

Para evitar erros de certificado, você precisa que o pi envie um certificado que corresponda ao domínio usado.Existem duas abordagens para isso:

  1. Use um certificado para ambos os domínios, instalado no servidor pi e principal. Não importa qual domínio o cliente usou em sua consulta, o certificado corresponderá.
  2. Escolha um certificado que o cliente espera e envie-o.

A opção 1 é uma prática mais fácil e comum. Veja o certificado do google.com! Tanto o pi quanto o servidor principal terão o mesmo certificado (para ambos os domínios) instalado. Para obter esse certificado do Let's Encrypt, você precisará do servidor principal para executar também um site para o domínio dinâmico do pi e usarumComando certbot para verificar o controle de ambos os domínios de uma só vez. O site do servidor principal para o nome dyndns não precisa hospedar o conteúdo do pi - ele está lá apenas para que o Let's Encrypt possa verificar se você tem o controle desse site (você pode até desativá-lo entre as renovações).

Exemplo de comando Certbot para isso (executado no servidor web principal):

letsencrypt certonly --webroot --csr request.csr -w /http/pisite/www -d mypi.spdyn.de -w /http/mainwebsite/www -d maindomain.de

Onde request.csrusa um dos domínios como CN e possui ambos os domínios no campo SANs, /http/pisite/wwwrefere-se a um diretório local que você criaria para outro site no servidor atual vinculado ao nome dinâmico do pi e /http/mainwebsite/wwwé o diretório existente do seu site principal.

A opção 2 é mais envolvente, mas produz um resultado mais 'limpo': o cliente obtém um certificado que corresponde ao domínio digitado. No raspberry pi, execute o nginx com o módulo stream (ou equivalente) que, quando uma conexão TLS é aberta: examina o campo SNI (sem aceitar a conexão TLS), e com base no domínio nele incluído, escolhe qual upstream encaminhar o ligação a. Isso permite que você escolha como deseja lidar com as solicitações feitas no domínio principal na porta externa encaminhadas para o Raspberry Pi. Você pode enviá-los para o servidor web principal como se tivessem sido feitos na porta correta, você pode enviá-los para alguma outra porta no pi (ou seja, Nextcloud, ou qualquer outra), você pode encerrá-los com a mesma instância nginx e mostre a página que desejar ou simplesmente feche a conexão. A escolha é sua.

Aqui está um exemplo de configuração para este método:

stream/sni-switch.conf

# Listen on 443, and on new connection:
#   if the SNI is mapped herein, handle it on this Nginx
#   else, forward the whole session to 192.168.1.80:443 (TCP passthrough, no decryption)

upstream mainwebserver {
    server 192.168.1.80:443;
}

upstream local_https {
    server 127.0.0.1:1443;
}

map $ssl_preread_server_name $name {
    default mainwebserver;

    pisite.spdyn.de     local_https;
}

server {
    listen 443;

    ssl_preread on;
    proxy_pass $name;
}

E emnginx.conf

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

stream {
    include /etc/nginx/stream/sni-switch.conf;
}

...

Para fazer isso com o Apache, consulteesse. Um exemplo de configuração que pode ser assim:

<VirtualHost *:*>
    ProxyPreserveHost On
    ProxyPass        "/" "http://192.168.1.80/"
    ProxyPassReverse "/" "http://192.168.1.80/"
    ServerName maindomain.de
</VirtualHost>

informação relacionada