Estoy intentando proporcionar servicios seguros en la intranet de mi hogar. Hasta ahora he usado certificados autofirmados con un dominio inventado example.foo, con un subdominio para mis sistemas separados (por ejemplo srv1.example.foo). Estos dominios están definidos en mi servidor DNS local.
Ahora compré el dominio example.com, pero no tengo planes de brindar ningún servicio público. También tengo un VPS con IP estáticas a las que apuntar example.com.
Espero crear un certificado letsencrypt comodín para *.example.comusarlo en mis sistemas de intranet. Para separar los sistemas locales de cualquier cosa pública, definiría un subdominio en mi DNS local, que no debería resolverse en servidores DNS públicos (por ejemplo *.local.example.com). Por lo tanto, los sistemas de intranet locales utilizan nombres como srv1.local.example.com.
¿Es factible esta configuración?
¿Puedo crear dicho certificado en mi VPS *.example.comy proteger los servicios de intranet con el certificado generado? ¿Mi servidor DNS local resuelve dominios como srv1.local.example.comIP privadas y no expone ninguna IP o dominio privado al público?
Respuesta1
¿Puedo crear dicho certificado en mi VPS para *.example.com y proteger los servicios de intranet con el certificado generado?
Sí, pero es una forma extraña de hacerlo. No facilita la automatización.
Ejecutaría certbot (o cualquier herramienta que uses) en elactualsistema que necesita el certificado, o algún servidor dentro de su red donde el sistema que lo necesita pueda obtenerlo.
Usarautenticación de desafío DNSpara validar el control sobre el dominio. Esto requiere un proveedor de DNS externo que tenga API, por ejemplo, Route53, Cloudflare, Azure o muchos otros.
No necesita ningún registro DNS público, excepto los registros de texto utilizados para validar la propiedad.
Respuesta2
No puede crear un certificado comodín *.example.comni utilizarlo para s1.sd.example.com. Así funcionan los certificados. Si desea crear un certificado comodín, s1.sd.example.comdebe ser para*.sd.example.com