Habilita HTTPS en tus servidores

Chris Palmer
Chris Palmer

En esta página, se proporcionan instrucciones para configurar HTTPS en tus servidores, en los que se incluyen los siguientes pasos:

  • Crear un par de claves públicas/privadas de RSA de 2,048 bits
  • Generar una solicitud de firma de certificado (CSR) que incorpore tu clave pública
  • Compartir tu CSR con tu autoridad certificadora (AC) para recibir un certificado final o una cadena de certificados
  • Instala el certificado final en un lugar al que no se pueda acceder a través de la Web, como /etc/ssl (Linux y Unix), o en cualquier lugar donde lo requiera IIS (Windows).

Genera claves y solicitudes de firma de certificados

En esta sección, se usa el programa de línea de comandos OpenSSL, que se incluye en la mayoría de los sistemas de Linux, BSD y Mac OS X para generar claves privadas y públicas, y una CSR.

Genera un par de claves públicas/privadas

Para comenzar, genera un par de claves RSA de 2,048 bits. Una clave más corta puede dañarse con ataques de conjetura de fuerza bruta, y las claves más largas usan recursos innecesarios.

Usa el siguiente comando para generar un par de claves RSA:

openssl genrsa -out www.example.com.key 2048

Esto arroja el siguiente resultado:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Cómo generar una solicitud de firma de certificado

En este paso, incorporas tu clave pública y la información sobre tu organización y tu sitio web en una solicitud de firma de certificado o CSR. El comando openssl te solicita los metadatos necesarios.

Ejecuta el siguiente comando:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

El resultado es lo siguiente:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Para garantizar la validez de la CSR, ejecuta este comando:

openssl req -text -in www.example.com.csr -noout

La respuesta debería verse de la siguiente manera:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Envía la CSR a una autoridad certificadora

Las diferentes autoridades certificadoras (CA) requieren que les envíes tus CSR de diferentes maneras. Estos pueden incluir utilizar un formulario en su sitio web o enviar la CSR por correo electrónico. Algunas AC, o sus revendedores, pueden incluso automatizar el proceso de forma parcial o total, incluida, en algunos casos, la generación de pares de claves y de CSR.

Envía la CSR a tu CA y sigue las instrucciones para recibir el certificado final o la cadena de certificados.

Las AC cobran diferentes cantidades de dinero por el servicio de comprobación de tu clave pública.

También existen opciones para asignar tu clave a más de un nombre de DNS, incluidos varios nombres distintos (p.ej., todas las instancias de example.com, www.example.com, example.net y www.example.net) o nombres de "comodín", como *.example.com.

Copia los certificados en todos tus servidores de frontend en un lugar al que no se pueda acceder desde la Web, como /etc/ssl (Linux y Unix), o donde sea que IIS (Windows) los requiera.

Habilita HTTPS en tus servidores

Habilitar HTTPS en tus servidores es un paso fundamental para proporcionar seguridad en tus páginas web.

  • Usa la herramienta Configuración del servidor de Mozilla para configurar tu servidor para que sea compatible con HTTPS.
  • Prueba periódicamente tu sitio con la prueba del servidor SSL de Qualys y asegúrate de obtener una calificación A o A+, como mínimo.

En este punto, debes tomar una decisión crucial sobre las operaciones. Elige una de las siguientes opciones:

  • Dedica una dirección IP distinta para cada nombre de host del que entrega contenido tu servidor web.
  • Usar el hosting virtual basado en nombres

Si usaste direcciones IP distintas para cada nombre de host, puedes admitir HTTP y HTTPS para todos los clientes. Sin embargo, la mayoría de los operadores de sitios usan hosting virtual basado en nombres para conservar direcciones IP y porque, en general, es más conveniente.

Si aún no tienes el servicio HTTPS disponible en tus servidores, habilítalo ahora (sin redireccionar HTTP a HTTPS. Consulta Redirecciona de HTTP a HTTPS para obtener más información). Configura tu servidor web para usar los certificados que compraste e instalaste. El generador de configuración de Mozilla puede resultarte útil.

Si tienes muchos nombres de host o subdominios, cada uno debe usar el certificado correcto.

Ahora, y periódicamente durante todo el ciclo de vida de tu sitio, verifica la configuración de HTTPS con la Prueba del servidor SSL de Qualys. Tu sitio debería obtener una puntuación de A o A+. Considera como error todo lo que genere una calificación inferior y mantén la precaución, ya que siempre se desarrollan nuevos ataques contra los algoritmos y los protocolos.

Hacer que las URLs dentro del sitio sean relativas

Ahora que tu sitio se ofrece tanto en HTTP como en HTTPS, debe funcionar de la forma más fluida posible, independientemente del protocolo. Un factor importante es usar URLs relativas para vínculos dentro del sitio.

Asegúrate de que las URLs dentro del sitio y las URLs externas no dependan de un protocolo específico. Usa rutas de acceso relativas o omite el protocolo como en //example.com/something.js.

Entregar una página que contiene recursos HTTP mediante HTTPS puede causar problemas. Cuando un navegador encuentra una página que podría usar recursos no seguros, advierte a los usuarios que la página no es del todo segura y algunos navegadores se niegan a cargar o ejecutar los recursos HTTP, lo que daña la página. Sin embargo, puedes incluir recursos HTTPS en una página HTTP de forma segura. Para obtener más información sobre cómo solucionar estos problemas, consulta Cómo corregir el contenido mixto.

Seguir los vínculos basados en HTTP a otras páginas de tu sitio también puede cambiar la experiencia del usuario de HTTPS a HTTP. Para solucionar este problema, haz que tus URLs dentro del sitio sean lo más relativas posible. Para ello, hazlas relativas de protocolo (sin un protocolo, que comienzan con //example.com) o relativas de host (a partir de solo la ruta de acceso, como /jquery.js).

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
Usa URLs relativas dentro del sitio.
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
También puedes usar URLs relativas de protocolo dentro del sitio.
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Usa URLs HTTPS para vínculos a otros sitios siempre que sea posible.

Actualiza los vínculos con un guion y no de forma manual para evitar cometer errores. Si el contenido de tu sitio está en una base de datos, prueba tu secuencia de comandos en una copia de desarrollo de la base de datos. Si el contenido de tu sitio solo contiene archivos simples, prueba tu secuencia de comandos en una copia de desarrollo de los archivos. Envía los cambios a producción solo después de que estos aprueben el control de calidad, como de costumbre. Puedes usar la secuencia de comandos de Bram van Damme o algo similar para detectar contenido mixto en tu sitio.

Cuando vincules otros sitios (en lugar de incluir recursos de ellos), no cambies el protocolo. No puedes controlar cómo funcionan esos sitios.

Para que la migración de sitios grandes se realice sin problemas, te recomendamos las URL relativas de protocolo. Si aún no estás seguro de si puedes implementar HTTPS por completo, forzar a tu sitio a usar HTTPS para todos los subrecursos puede tener consecuencias negativas. Es probable que haya un período en el que HTTPS sea nuevo y extraño para ti, y el sitio HTTP aún debe funcionar tan bien como siempre. Con el tiempo, completarás la migración y bloquearás el uso de HTTPS (consulta las dos secciones siguientes).

Si tu sitio depende de secuencias de comandos, imágenes o algún otro recurso que entrega un tercero, como CDN o jquery.com, tienes dos opciones:

  • Usa URLs relativas de protocolo para estos recursos. Si el tercero no entrega HTTPS, pídele que lo haga. La mayoría ya lo hace, incluido jquery.com.
  • Entrega los recursos desde un servidor que controles, en el que se ofrezcan tanto HTTP como HTTPS. De todos modos, esta suele ser una buena idea porque tienes más control sobre la apariencia, el rendimiento y la seguridad de tu sitio, y no necesitas confiar en un tercero para mantenerlo seguro.

Redirecciona de HTTP a HTTPS

Para indicarles a los motores de búsqueda que usen HTTPS para acceder a tu sitio, incluye un vínculo canónico al principio de cada página con etiquetas <link rel="canonical" href="https://…"/>.

Activa la Seguridad de transporte estricta y cookies de seguridad

En este punto, ya tienes todo listo para "bloquear" el uso de HTTPS:

  • Usa HTTP con Seguridad de Transporte Estricta (HSTS) para evitar el costo del redireccionamiento 301.
  • Siempre configura la marca Secure en las cookies.

Primero, usa la Seguridad de transporte estricta para indicarles a los clientes que siempre deben conectarse a tu servidor mediante HTTPS, incluso si siguen una referencia http://. Esto elimina los ataques como SSL Stripping y evita el costo de ida y vuelta del 301 redirect que habilitamos en Redirecciona de HTTP a HTTPS.

Para activar HSTS, configura el encabezado Strict-Transport-Security. En la página de HSTS de OWASP, encontrarás vínculos a instrucciones para varios tipos de software de servidores.

La mayoría de los servidores web ofrecen una capacidad similar para agregar encabezados personalizados.

También es importante asegurarse de que los clientes nunca envíen cookies (por ejemplo, para autenticación o preferencias del sitio) a través de HTTP. Por ejemplo, si la cookie de autenticación de un usuario se expusiera en texto sin formato, se destruirá la garantía de seguridad para toda la sesión, incluso si hiciste bien todo lo demás.

A fin de evitar esto, cambia la app web para establecer siempre la marca Secure en las cookies que establece. En esta página de OWASP, se explica cómo configurar la marca Secure en varios frameworks de apps. Cada framework de app tiene una forma de establecer la marca.

La mayoría de los servidores web ofrecen una función de redireccionamiento simple. Usa 301 (Moved Permanently) para indicar a los motores de búsqueda y a los navegadores que la versión HTTPS es canónica y redirecciona a los usuarios a la versión HTTPS de tu sitio desde HTTP.

Clasificación de búsqueda

Google usa HTTPS como indicador de calidad de búsqueda positiva. Google también publica una guía sobre cómo transferir, mover o migrar tu sitio y, al mismo tiempo, mantener su clasificación de búsqueda. Bing también publica lineamientos para webmasters.

Rendimiento

Cuando las capas de contenido y aplicación están bien ajustadas (consulta los libros de Steve Souders para obtener consejos), las inquietudes restantes sobre el rendimiento de TLS son, en general, pequeñas en relación con el costo general de la aplicación. Además, puedes reducir y amortizar esos costos. Si deseas obtener asesoramiento sobre la optimización de TLS, consulta High Performance Browser Networking de Ilya Grigorik, además de la Guía de soluciones de OpenSSL y Bulletproof SSL And TLS de Ivan Ristic.

En algunos casos, TLS puede mejorar el rendimiento, principalmente como resultado de la posibilidad de usar HTTP/2. Para obtener más información, consulta la charla de Chris Palmer sobre el rendimiento de HTTPS y HTTP/2 en la Cumbre de desarrolladores de Chrome de 2014.

Encabezados de referencia

Cuando los usuarios siguen vínculos desde tu sitio HTTPS a otros sitios HTTP, los usuarios-agentes no envían el encabezado de referencia. Si esto representa un problema, hay varias formas de solucionarlo:

  • Se deben migrar los otros sitios a HTTPS. Si los sitios de referencia completan la sección Habilita HTTPS en tus servidores de esta guía, puedes cambiar los vínculos de tu sitio al de ellos, de http:// a https://, o usar vínculos relativos de protocolo.
  • Para solucionar varios problemas relacionados con los encabezados de referencia, usa el nuevo estándar de la política de referencias.

Ingresos publicitarios

Los operadores que monetizan su sitio mediante anuncios desean asegurarse de que la migración a HTTPS no reduzca las impresiones de anuncios. Sin embargo, debido a problemas de seguridad de contenido mixto, un <iframe> de HTTP no funciona en una página HTTPS. Hasta que los anunciantes publiquen a través de HTTPS, los operadores de sitios no podrán migrar a HTTPS sin perder ingresos publicitarios. Sin embargo, hasta que los operadores de sitios migren a HTTPS, los anunciantes tendrán poca motivación para publicar HTTPS.

Puedes comenzar el proceso de solucionar este problema si usas anunciantes que ofrecen servicios de anuncios a través de HTTPS y pides a los anunciantes que no ofrecen HTTPS para que, al menos, la elijan como opción. Es posible que debas postergar la tarea de completar el artículo Haz las URLs dentro del sitio relativas hasta que una cantidad suficiente de anunciantes interoperen de forma correcta.