Estou tentando fornecer serviços seguros na minha intranet doméstica. Até agora usei certificados autoassinados com um domínio inventado example.foo, com um subdomínio para meus sistemas separados (por exemplo srv1.example.foo, ). Esses domínios são definidos no meu servidor DNS local.
Agora comprei o domínio example.com, mas não tenho planos de fornecer nenhum serviço público. Também tenho um VPS com IPs estáticos para apontar example.com.
Espero criar um certificado letsencrypt curinga para *.example.comusar em meus sistemas de intranet. Para separar os sistemas locais de qualquer coisa pública, eu definiria um subdomínio no meu DNS local, que não deveria ser resolvido em servidores DNS públicos (por exemplo, *.local.example.com). Assim, os sistemas de intranet locais usam nomes como srv1.local.example.com.
Essa configuração é viável?
Posso criar esse certificado em meu VPS *.example.come proteger serviços de intranet com o certificado gerado. Meu servidor DNS local resolve domínios como srv1.local.example.comIPs privados e não expõe nenhum IP ou domínio privado ao público?
Responder1
Posso criar esse certificado em meu VPS para *.example.com e proteger serviços de intranet com o certificado gerado.
Sim, mas é uma maneira estranha de fazer isso. Isso não torna a automação fácil.
Eu executaria o certbot (ou qualquer ferramenta que você use) norealsistema que precisa do certificado ou algum servidor dentro da sua rede onde o sistema que precisa dele possa obtê-lo.
Usarautenticação de desafio de DNSpara validar o controle sobre o domínio. Isso requer um provedor de DNS externo que tenha API, por exemplo, Route53, Cloudflare, Azure ou vários outros.
Você não precisa de nenhum registro DNS público, exceto os registros txt usados para validar a propriedade.
Responder2
Você não pode criar um certificado curinga *.example.come usá-lo para s1.sd.example.com. É assim que os certificados funcionam. Se você deseja criar um certificado curinga para s1.sd.example.comele, deve ser para*.sd.example.com