Como posso obter um certificado Let's Encrypt para um servidor não público?

Eu tenho um servidor Apache privado, acessível apenas a partir da minha LAN na porta 443, com um certificado StartSSL.

Desde que o Firefox 51 foi lançado, não consigo mais me conectar a ele, pois o certificado raiz StartSSL foi removido do armazenamento confiável .

Eu considerei migrar para o Let's Encrypt, mas isso parece exigir um servidor HTTP voltado para o público. É possível usar o Let's Encrypt na minha situação?

Prefiro evitar pagar por um certificado SSL, se possível.

ssl-certificate lets-encrypt

— Calimo
fonte

Respostas:

Se você controlar o DNS para o domínio, poderá usar o método de desafio dns-01 para provar a propriedade criando um registro TXT.

Isso pode ser feito manualmente ou automatizado. Acho que até o cliente oficial do certbot agora suporta dns-01.

Um rápido Google me mostra vários tutoriais usando vários scripts e clientes, para não repetir todos eles aqui. Este automatiza especificamente os certificados da intranet.

— Martijn Heemels
fonte

Tem certeza de que realmente funciona na intranet? E se eu simplesmente sobrescrever /etc/resolv.conf do host no qual o certbot é executado?

— peterh - Restabelece Monica 31/01

@ Peterh Sim, ele funciona na intranet conforme a documentação.

— BE77Y 31/01

@ Peterh Não sei ao certo o que você está tentando substituindo resolv.conf. O registro TXT precisa ser criado no DNS público, pois os servidores de validação Let's Encrypt, não o cliente certbot, precisam poder resolver o registro. Se tudo acontecesse localmente, a validação não valeria muito. O servidor para o qual o certificado é emitido pode ser completamente privado.

— Martijn Heemels 21/03/19

@MartijnHeemels Bem, agora não consigo mais entender meu comentário antigo. Eu crio certificados de intranet com letsencrypt, enganando seus DNSs de uma maneira, mostrando um terceiro servidor, com ip público , para todas as solicitações * .intranet.mydomain - mas é apenas para os servidores DNS de saída do letsencrypt . Eu obtive os IPs deles através do tcpdump-ing do tráfego DNS de entrada. O Bind9 possui as chamadas "visualizações" para isso. Portanto, esse terceiro servidor pode obter arquivos * .intranet.mydomain com uma configuração apache complicada ajustada para isso. Depois disso, as chaves podem ser espelhadas na intranet com scripts rsync.

— peterh - Restabelece Monica

@MartijnHeemels Estou fazendo isso porque, na época, havia problemas para automatizar a autorização baseada em zona do letsencrypt. Talvez agora funcione, mas sinceramente não estou muito satisfeito com o letsencrypt em geral (bem ... com os problemas de sua automatização, é claro que estou muito feliz que ele exista) e não quero fazê-lo funcionar novamente , o que eu já fiz bem. (Eu acho que todos nós sabemos a atitude dos chefes sobre "torná-lo melhor" tarefas como esta.)

— peterh - Reintegrar Monica

O cliente certbot tem capacidade para executar um desafio de DNS manual. A resposta (atualmente a segunda mais popular) encontrada nesta pergunta Como usar a validação de desafio do Let's Encrypt DNS? tem todos os detalhes, e eu apenas testei como funcionando.

Basicamente, você executa este comando e segue as instruções:

certbot -d site.your.dom.ain --manual --preferred-challenges dns certonly

— vick
fonte

Você mencionou que está usando o Apache, no entanto, se você não estiver vinculado a ele, existe um caminho muito fácil possível usando o Caddyserver .

Lá você só precisa definir um Caddyfilecom o seguinte conteúdo:

example.com
tls {
    dns cloudflare
}

Mencione o provedor DNS que você está usando na configuração e configure as chaves da API que você é através de variáveis de ambiente. Desenhe na lista de fornecedores suportados nos documentos .

É tudo o que é necessário. A saída no primeiro início será algo como:

Activating privacy features... 2019/10/21 13:36:48 [INFO][cache:0xc0001c8190] Started certificate maintenance routine
[INFO][cache:0xc000092730] Started certificate maintenance routine
2019/10/21 13:24:49 [INFO][example.com] Obtain certificate
2019/10/21 13:24:49 [INFO] [example.com] acme: Obtaining bundled SAN certificate
2019/10/21 13:24:50 [INFO] [example.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/876706285
2019/10/21 13:24:50 [INFO] [example.com] acme: Could not find solver for: tls-alpn-01
2019/10/21 13:24:50 [INFO] [example.com] acme: Could not find solver for: http-01
2019/10/21 13:24:50 [INFO] [example.com] acme: use dns-01 solver
2019/10/21 13:24:50 [INFO] [example.com] acme: Preparing to solve DNS-01
2019/10/21 13:24:50 [INFO] cloudflare: new record for example.com, ID XXX
2019/10/21 13:24:50 [INFO] [example.com] acme: Trying to solve DNS-01
2019/10/21 13:24:50 [INFO] [example.com] acme: Checking DNS record propagation using [127.0.0.11:53]
2019/10/21 13:24:50 [INFO] Wait for propagation [timeout: 2m0s, interval: 2s]
2019/10/21 13:24:50 [INFO] [example.com] acme: Waiting for DNS record propagation.
2019/10/21 13:24:52 [INFO] [example.com] acme: Waiting for DNS record propagation.
2019/10/21 13:24:55 [INFO] [example.com] The server validated our request
2019/10/21 13:24:55 [INFO] [example.com] acme: Cleaning DNS-01 challenge
2019/10/21 13:24:55 [INFO] [example.com] acme: Validations succeeded; requesting certificates
2019/10/21 13:24:56 [INFO] [example.com] Server responded with a certificate.
done.

Serving HTTPS on port 443
https://example.com

2019/10/21 13:36:48 [INFO] Serving https://example.com

Serving HTTP on port 80
http://example.com

2019/10/21 13:36:48 [INFO] Serving http://example.com

— Gregor Müllegger
fonte