ssl - name - https certificate

Certificado SSL firmado de terceros para localhost o 127.0.0.1? (5)

Sin divulgar demasiada información, necesito configurar un sistema de servidor web que esté destinado a ser utilizado por los usuarios finales en todo Internet.

el caso de uso es tal que:

los usuarios finales (generalmente) en sus hogares detrás de sus firewalls locales cuando se conectan al sistema.
El sistema consiste en un servidor remoto alojado por nosotros, estrictamente sobre https (usando SSL)
El mecanismo de autorización requiere la autocreación de cuentas de usuario en el servidor remoto que, luego de la creación exitosa de la cuenta, requerirá que se descargue e instale un software en la computadora de los usuarios finales. Este software contiene, entre otras cosas, un servidor web local.
Este servidor web "local" solo debe permitir conexiones https al navegador del usuario.

Dado que el software distribuido será un servidor web único en la máquina de cada uno de los usuarios, no estoy seguro de cómo, incluso si es posible, obtener un certificado SSL FIRMADO POR TERCEROS que no cause errores de confiabilidad cuando el usuario se conecte a él. a través del navegador web. Por supuesto, puede usar certificados SSL autofirmados, pero la idea es evitar las advertencias del navegador para que los usuarios finales "confíen" implícitamente en los datos provenientes de su propia aplicación que ejecuta su servidor web a través de SSL.

es posible?

localhost

Nunca se emitirá un certificado https adecuado para localhost. Está estrictamente prohibido . Porque reasons .

En breve:

Los dispositivos desconfigurados realmente existen , en estado natural, que esperan las búsquedas antes de resolver localhost desde /etc/hosts
Si un enrutador define localhost.foo.local , puede hacer que localhost resuelva incorrectamente (es probable que haya visto antes esta clase de error)

Puede crear un certificado raíz y luego crear un certificado denominado "autofirmado", firmado por la raíz que creó. Seguirás recibiendo la fea pantalla de advertencia, pero funcionará.

Ver https://coolaj86.com/articles/how-to-create-a-csr-for-https-tls-ssl-rsa-pems/

localhost.daplie.me (también apunta a 127.0.0.1)

En lugar de cert de localhost real, hago lo que sugiere Eugene: crear un registro de 127.0.0.1 en un dominio público.

Los certificados HTTPS para localhost.daplie.me (así como otros certs para pruebas, como localhost.foo.daplie.me , localhost.bar.daplie.me ) están disponibles en Daplie''s git, si a otros les gustaría usa esto como una solución parcial:

https://git.daplie.com/Daplie/localhost.daplie.me-certificates

daplie.me está en la Lista de sufijos públicos y localhost.daplie.me también se envía para su inclusión .

Esto significa que las cookies, localStorage, etc. están protegidos de ser compartidos con el padre ( daplie.me ) y sus hermanos ( xyz.daplie.me ).

Apunte su localhost.MY-SLD.MY-TLD a 127.0.0.1

Adquiera un *.localhost.example.com y emita cada instalación en un xyz.localhost.example.com secreto (e xyz.localhost.example.com en la lista de sufijos públicos para evitar ataques en example.com)
Utilice una aplicación habilitada con Greenlock para generar dichos certificados sobre la marcha (a través de https://letsencrypt.org ) directamente en el cliente (o páselos al cliente)

Si no se incluye en el PSL, tenga en cuenta que:

sesiones, localstorage, indexeddb, etc. son compartidos por dominio
cambiar el puerto no cambia su compartición

Sea su propio certificado de raíz

Actualización : con cosas como greenlock que usan ACME / Let''s Encrypt, esto ya no es particularmente relevante.

Esta es probablemente una muy mala idea porque no queremos que los usuarios se acostumbren a instalar CA raíz de cualquier otra forma (y sabemos cómo resultó eso para Lenovo ), pero para las máquinas corporativas / clonadas puede ser una opción razonable de bajo presupuesto.

Como está en el servidor local, puede indicarle a su navegador que confíe en el certificado que desee.

Cree un certificado autofirmado para localhost e indique a su navegador que confíe en él.

La solución "Señale su servidor local.MY-SLD.MY-TLD a 127.0.0.1" proporcionada por la proporcionada por CoolAJ86 funciona bien, y verá una explicación más detallada aquí:
Cómo PLEX está haciendo https para todos sus usuarios

PD: Simplemente no sé qué tan sostenible es esto, porque a alguien con un escenario similar la CA le revocó la clave como si la llave estuviera en peligro.

Probablemente nos pueda hacer llegar esta oferta de GlobalSign (otras CA ofrecen servicios comparables). En resumen, la oferta le permite tener un certificado de CA (e inscribir certificados de usuario final para localhost / whatever) que será firmado por el certificado de GlobalSign. Sin embargo, el costo puede ser significativo (creo que lo determinan caso por caso).

Tenía este mismo requisito. Entonces, la razón por la que tiene que usar SSL es porque casi todos los navegadores barfs si usa https e intentan conectarse a un recurso http incluso si el recurso http está en el servidor local, lo cual es una tontería para mí.

Debido a JS SOP nuestro servidor web localhost sirve un archivo js y luego el JS dentro de la aplicación web puede hacer llamadas a este servidor web localhost.

Así que hicimos que local.example.com apuntara a 127.0.0.1 y realmente compramos un certificado SSL para este nombre de host. Luego enviamos la clave privada dentro de este servidor web que se instala en la computadora del usuario. Sí, estamos locos.

Todo esto realmente funciona bastante bien. Hemos estado funcionando así con unos cientos de usuarios durante aproximadamente 6 meses.

El único problema que a veces nos encontramos es que esto no funciona bien cuando un usuario está utilizando un servidor proxy. Las solicitudes se envían al servidor proxy e intenta conectarse a 127.0.0.1 en el servidor proxy, lo que obviamente no funciona. La solución alternativa es agregar una exclusión a la configuración del servidor proxy para que pase por alto el servidor proxy para solicitudes a local.example.com

Otro escenario donde se volverá un poco complicado es cuando los usuarios intentan usar Citrix o Servicios de Terminal Server. Debe asegurarse de que el servidor web para cada usuario se ejecuta en un puerto diferente y luego informar al servidor web remoto el número de puerto para que las páginas generadas en el servidor tengan el número de puerto correcto. Afortunadamente no nos hemos encontrado con esto todavía. También parece que cada vez más personas utilizan máquinas virtuales en lugar de Citrix.

¿Alguna vez encontraste una mejor manera?