Diferentes versiones de SSL / TLS en subdominios usando un certificado comodín

3

Actualmente estoy en el proceso de implementar un sistema de pago seguro. Quiero que este sistema sea compatible con PCI y tenga implementada la versión más alta de TLS.

El sistema actual tiene varios subdominios que utilizan un certificado comodín, los usuarios que acceden al sitio operan navegadores antiguos, lo que significa que tenemos una versión un poco más antigua de TLS.

¿Es posible tener un nuevo subdominio checkout usando el certificado comodín e implementar una versión diferente de TLS en este nuevo subdominio checkout (residirá en un entorno separado) también)?

Si es posible, ¿es esa la mejor opción y la más segura, o se recomienda separarla completamente con su propio certificado?

    
pregunta Oliver Cooke 23.03.2017 - 10:19
fuente

2 respuestas

3

Eso es absolutamente posible.

Tanto para Apache como para nginx, puede definir las opciones de TLS por host virtual.

Tomando nginx como ejemplo, cada bloque como el siguiente (tomado de generador de configuración TLS de Mozilla puede especificar sus propias opciones y preferencias de TLS:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    resolver <IP DNS resolver>;

    ....
}

Puede usar cualquier certificado (con suerte válido) dentro del bloque, incluida la reutilización de un certificado entre subdominios. La configuración de TLS es distinta de los detalles del certificado y la clave utilizada.

Sin embargo, aunque puede hacer esto, puede tener sentido considerar, al menos, el uso de certificados diferentes, le permitiría revocar certificados para diferentes partes de su sitio en caso de compromiso.

Usando el certificado comodín, si esa clave está comprometida, todo el sitio estará desconectado hasta que pueda obtener un nuevo certificado. Si tiene certificados de dominio, y posiblemente un comodín como alternativa, puede estar en mejores condiciones para lidiar con esa situación sin afectar necesariamente todo su servicio.

    
respondido por el iwaseatenbyagrue 23.03.2017 - 10:33
fuente
2

Además de la respuesta de @iwaseatenbyagrue, aunque la mayoría de las versiones de SSL / TLS no deberían representar un riesgo para su subdominio extra seguro , si admite SSL 2 en cualquier lugar, entonces pondremos en riesgo cualquier conexión que utilice el mismo certificado , sin importar la versión de SSL / TLS que se use para ello.

De hecho, debido a que los navegadores modernos prohíben los certificados SHA-1, no hay (por lo que sé) ningún navegador que pueda conectarse a cualquier sitio web que esté protegido con un certificado SSL de confianza pública y que no sea compatible con menos TLS 1.0, por lo que no hay una sola razón para usar el obsoleto y inseguro SSL 3 tampoco.

    
respondido por el user2428118 09.05.2017 - 09:56
fuente

Lea otras preguntas en las etiquetas