Cómo habilitar HTTPS en tus servidores

Chris Paler
Chris Palmer

Pasos que se describen en este artículo

  1. Crea un par de clave pública/privada de RSA de 2,048 bits.
  2. Genera una solicitud de firma de certificado (CSR) que incorpore tu clave pública.
  3. Comparte tu CSR con tu autoridad certificadora (AC) para recibir un certificado final o una cadena de certificados.
  4. Instala el certificado final en un lugar al que no se pueda acceder desde 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 con la mayoría de los sistemas de Linux, BSD y Mac OS X para generar claves privadas o públicas y una CSR.

Genera un par de claves públicas/privadas

Comencemos por generar un par de claves RSA de 2,048 bits. Las claves más pequeñas, como las de 1,024 bits, no son lo suficientemente resistentes a los ataques externos por fuerza bruta. Las claves más grandes, como las de 4,096 bits, son exageradas. Con el tiempo, el tamaño de las claves aumenta a medida que el procesamiento por computadora se vuelve más económico. Actualmente, el punto óptimo es 2,048.

El comando para generar el par de claves RSA es el siguiente:

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 de forma interactiva 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 ser similar a la siguiente:

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 métodos diferentes para enviarles tus CSR. Los métodos pueden incluir usar un formulario en su sitio web, enviar la CSR por correo electrónico o algo más. 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 “comodín”, como *.example.com.

Por ejemplo, una AC actualmente ofrece los siguientes precios:

  • Estándar: USD 16 por año; válido para example.com y www.example.com
  • Comodín: USD 150 por año; válido para example.com y *.example.com

Según estos precios, los certificados comodín son económicos si tienes más de 9 subdominios; de lo contrario, solo puedes comprar uno o más certificados con un solo nombre. (Si tienes más de cinco subdominios, por ejemplo, es posible que un certificado comodín te resulte más conveniente cuando habilites HTTPS en tus servidores).

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.

  • Utiliza la herramienta Configuración del servidor de Mozilla para configurar tu servidor y permitir que sea compatible con HTTPS.
  • Prueba periódicamente tu sitio con la práctica herramienta SSL Server Test de Qualys y asegúrate de obtener un puntaje 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 has usado direcciones IP distintas para cada nombre de host, puedes admitir con facilidad 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. El problema con IE en Windows XP y Android anteriores a 2.3 es que no entienden la indicación de nombre del servidor (SNI), que es fundamental para el hosting virtual basado en nombres HTTPS.

En el futuro, y esperamos que sea un futuro cercano, los clientes que no admitan SNI serán reemplazados por software moderno. Supervisa la cadena de usuario-agente en tus registros de solicitudes para saber cuándo se migró suficiente cantidad de usuarios al software moderno. (Puedes decidir cuál es tu umbral; tal vez inferior al 5% o inferior al 1%).

Si aún no tienes el servicio HTTPS disponible en tus servidores, habilítalo ahora (sin redireccionar HTTP a HTTPS; consulta a continuación). Configura tu servidor web para usar los certificados que compraste e instalaste. El generador de configuraciones de Mozilla puede resultarte útil.

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

Ahora, y durante el tiempo que dure tu sitio, verifica la configuración de HTTPS con la práctica herramienta SSL Server Test de Qualys. Tu sitio debe obtener una puntuación de A o A+. Considera como error todo lo que genere una calificación inferior. (Una A de hoy será la B de mañana, porque los ataques contra los algoritmos y los protocolos mejoran constantemente).

Hacer que las URLs dentro del sitio sean relativas

Ahora que tu sitio se entrega 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 externas sean independientes del protocolo. Es decir, asegúrate de usar rutas de acceso relativas o de omitir el protocolo, como //example.com/something.js.

Surge un problema cuando entregas una página a través de HTTPS que incluye recursos HTTP, conocidos como contenido mixto. Los navegadores advierten a los usuarios que se perdió la potencia total de HTTPS. De hecho, en el caso del contenido mixto activo (secuencia de comandos, complementos, CSS o iframes), a menudo, los navegadores simplemente no cargarán ni ejecutarán el contenido, lo que generará una página rota. Recuerda que es totalmente correcto incluir recursos HTTPS en una página HTTP.

Además, si incluyes vínculos a otras páginas en tu sitio, los usuarios podrían cambiar de HTTPS a HTTP.

Estos problemas ocurren cuando tus páginas incluyen URLs completamente calificadas dentro del sitio que usan el esquema http://.

Qué no debes hacer
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Evita utilizar URLs dentro del sitio completamente calificadas.

En otras palabras, haz que las URLs dentro del sitio sean lo más relativas posible, ya sean 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 URLs entre sitios (cuando sea posible).

Haz esto con una secuencia de comandos, no de forma manual. Si el contenido de tu sitio está en una base de datos, prueba tu secuencia de comandos en una copia de desarrollo de tu base de datos. Si el contenido de tu sitio consta de 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, ya que no puedes controlar el modo en que operan esos sitios.

Para que la migración de sitios grandes se realice sin problemas, te recomendamos las URLs 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 podría 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 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 y que ofrezca tanto HTTP como HTTPS. De todos modos, esta suele ser una buena idea, ya que luego tienes más control sobre la apariencia, el rendimiento y la seguridad de tu sitio. Además, no tienes que confiar en un tercero, lo cual siempre es bueno.

Redirecciona de HTTP a HTTPS

Debes colocar un vínculo canónico en el encabezado de la página para indicarles a los motores de búsqueda que HTTPS es la mejor forma de acceder a tu sitio.

Establezca etiquetas <link rel="canonical" href="https://…"/> en sus páginas. Esto ayuda a los motores de búsqueda a determinar la mejor manera de llegar a tu sitio.

Activa la Seguridad de transporte estricta y cookies de seguridad

En este punto, ya tienes todo listo para “fijar” el uso de HTTPS.

  • Usa HTTP con Seguridad de Transporte Estricta (HSTS) para evitar el costo del redireccionamiento mediante el código 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 a través de HTTPS, incluso si siguen una referencia http://. Esto anula ataques como los de SSL Stripping y también evita el costo de ida y vuelta del 301 redirect que habilitamos en Redirecciona de HTTP a HTTPS.

Para activar la seguridad de transporte estricta de HTTP (HSTS), configura el encabezado Strict-Transport-Security. En la página de HSTS de OWASP, encontrarás vínculos a instrucciones para diferentes 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ía la garantía de seguridad de toda su sesión, incluso si hiciste todo lo demás bien.

Por lo tanto, cambia la aplicación web para configurar siempre la marca Secure en las cookies que establece. En esta página de OWASP, se explica cómo configurar la marca de seguridad en varios frameworks de aplicaciones. Todos los frameworks de aplicaciones tienen una forma de establecer el marcador.

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 mientras mantienes 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 excelentes 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. (para obtener excelentes consejos sobre la optimización de TLS y en general, consulta High Performance Browser Networking de Ilya Grigorik). Consulta también la Guía de soluciones de OpenSSL y el SSL y TLS a prueba de balas de Ivan Ristic.

En algunos casos, TLS puede mejorar el rendimiento, principalmente como resultado de hacer posible HTTP/2. Chris Palmer dio una charla 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 pueden completar la sección Cómo habilitar HTTPS en tus servidores de esta guía, puedes cambiar los vínculos de tu sitio al de ellos, de http:// a https://, o bien puedes 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.

Debido a que los motores de búsqueda migran a HTTPS, en el futuro, es probable que veas más encabezados de referencia cuando migres a HTTPS.

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. Aquí se presenta un problema de acción colectiva engañoso: hasta que los anunciantes publiquen contenido 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 no migren a HTTPS, los anunciantes no tendrán mucha motivación para publicar HTTPS.

Los anunciantes deben, al menos, ofrecer servicios de anuncios a través de HTTPS (por ejemplo, completando la sección "Habilita HTTPS en tus servidores" de esta página). Muchos ya lo hacen. Deberías pedirles a los anunciantes que no ofrecen HTTPS para nada que por lo menos comiencen a hacerlo. Te recomendamos postergar la finalización de la sección Haz que las URLs dentro del sitio sean relativas hasta que una cantidad suficiente de anunciantes interoperen de manera adecuada.