¿Podemos usar múltiples certificados SSL para una sola instancia con múltiples inicios de sesión de usuario [cerrado]

En primer lugar, tu pregunta no está clara.

¿Desea configurar varios certificados SSL para el mismo dominio? Eso no tiene sentido. Pero puede comprar certificados múltiples para el mismo dominio de proveedores como GoDaddy o NameCheap.

Supongamos, si su dominio es mail-archive.example.com . Podrías otorgar acceso a través de HTTP y HTTPS. Los clientes podrían acceder al sitio de ambas maneras, https://mail-archive.example.com & http://mail-archive.example.com con sus respectivas credenciales.

En Nginx, su configuración debería ser algo como:

    server {

            listen 80;
            listen [::]:80;

            server_name mail-archive.example.com;
            root /var/www/html/mail-archive/public;
            index index.php index.html index.htm;

}

    server {

        listen 443 http2;
        listen [::]:443 http2;

        server_name mail-archive.example.com;

        ssl on;
        ssl_certificate    /etc/ssl/mail-archive.example.pem; (or bundle.crt)
        ssl_certificate_key    /etc/ssl/mail-archive.example.key;

        root /var/www/html/mail-archive/public;
        index index.php index.html index.htm;

    }

Pase el dominio HTTPS para los clientes que desean acceder al sitio a través de una conexión segura y un dominio HTTP para aquellos que no lo desean.

Tenga en cuenta que las versiones más recientes de Google Chrome emiten una advertencia si los datos se envían a través de una conexión no segura.

En primer lugar, solo forzar a todos sus clientes a usar HTTPS puede ser la mejor solución. Las copias de seguridad de los correos electrónicos son confidenciales, por lo que enviarlas a través de una conexión no cifrada no es necesariamente deseable, incluso si están cifradas y especialmente si no lo están. Si bien es una buena opción para los administradores elegir, podría reducir la seguridad incluso para los administradores que decidieron usar HTTPS si no se hace con cuidado.

En segundo lugar, aunque podría permitir tanto HTTP como HTTPS como lo describe Praneeth Karnena, le impediría usar importantes funciones de seguridad como HSTS. Personalmente usaría subdominios si tuviera que hacerlo. Así que tendría secure.example.com y insecure.example.com . Por lo tanto, los administradores que no quieren usar HTTPS no pueden disminuir la seguridad de aquellos que lo hacen. Tendría que modificar ligeramente la forma en la aplicación, de modo que reconociera qué subdominio se usó e incluyera o no los encabezados HSTS, dependiendo de eso. También puede negarse a iniciar sesión en los administradores que optaron por la versión segura en la versión insegura del sitio.