☰

Gerar e renovar vamos criptografar o certificado

tag-icon • tag-icon nginx lets-encrypt
Gerar e renovar vamos criptografar o certificado

Meu domínio é (exemplo): mydomain.eu e está sincronizado com meu IP dinâmico com np-ip.
Internamente, tenho uma porta de escuta de servidor web 80/443 e recebi um novo certificado curinga do Let's Encrypt com certbot e implantar com registro DNS (txt).

Acho que é o suficiente, mas não…
Preciso de um certificado para outro servidor (cname mydomain.eu : cloud.mydomain.eu e mail.mydomain.eu) e configurei o cname no painel do meu provedor.

Também configurei um servidor em nuvem com Nextcloud e quero obter um certificado para este servidor. Recebo um erro porque o certbot quer portas 80 e 443, mas meu Ncserver escuta nas portas 81 e 1443. No futuro, eu criaria um web mail interno, que escuta também outra porta

Configuração interna

Example:
WEBSERVER # www.mydomain.eu - nginx - ip xxx.xxx.xxx.50 --> port 80/443
NEXTCLOUD # cloud.mydomain.eu - apache - ip xxx.xxx.xxx.51 -> port 81/1443
MAIL # mail.cloud.mydomain.eu - nginx/apache - ip xxx.xxx.xxx.52 -> port 82/2443

Configuração do servidor Web Nginx:

ssl_certificate /etc/letsencrypt/live/mydomain.eu/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.eu/privkey.pem;

server {
listen 80;
listen [::]:80;
server_name *.mydomain.eu;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name *.mydomain.eu;
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}

server {
listen 80;
listen [::]:80;
server_name cloud.mydomain.eu;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name cloud.mydomain.eu;

location / {
proxy_pass http://xxx.xxx.xxx.51:1443;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}

Qual é a melhor prática para obter certificados para cada servidor (ou um certificado curinga)? Seria bom ativar o cron para renovar certificados sem implantar um txtregistro a cada três meses

Responder1

caso todos os domínios estejam no mesmo host, você pode simplesmente usar o mesmo arquivo na outra configuração (você mencionou que o certificado curinga está disponível) ...

Depende de você ter um curinga (re)usado em mais serviços ou certificados extras por subdomínio. De qualquer forma, caso você tenha um certificado curinga e esteja planejado renová-lo automaticamente, você precisará de qualquer maneira da verificação do token DNS (registro TXT) e uma vez que o domínio for validado usando DNS você não precisa nem executar o servidor para obter o certificado ... Então no caso do certificado "por domínio", você pode usar a verificação de DNS do domínio para que portas não padrão não sejam problema.

De qualquer forma, no caso de certificado curinga, não é mais fácil ter tudo nas portas padrão 80/443? Hoje em dia não há problema com SNI (compartilhar as portas e diferenciar com base no conteúdo da solicitação). Nesse caso, você pode ter um proxy reverso (por exemplo, haproxy) lidando com certificados curinga e passando o tráfego para backends (nginx, apache httpd,...)

--- editar - 19 de janeiro de 2020: 22:40 CET ---

Caso o seu provedor de DNS não ofereça atualização de DNS "fácil", você pode delegar o "subdomínio" necessário ao seu sistema e executar o servidor DNS local mais ou menos apenas para o caso dessas atualizações dinâmicas - registros TXT ...

Vamos assumir o domínioexemplo.come seu nó local com fqdn atualizadoexemplo-local.com.noip.comapontando para o seu sistema. No sistema do registrador você pode fazer registro estático:

_acme-challenge.example.com. 3600 IN NS local-example.com.noip.com.

Dessa forma, você pode facilmente delegar o token DNS do domínio example.com para o seu sistema local. Lá você pode executar o servidor DNS local (por exemplo, bind) com domínio configurado_acme-challenge.example.comonde você pode atualizar localmente o registro TXT. Observe que neste domínio não é válido registro A nem AAAA, portanto apenas SOA, NS e atualizações dinâmicas pelo menos para TXT ;-).

informação relacionada