En esta página, se proporcionan instrucciones para configurar HTTPS en tus servidores, incluidos los siguientes pasos:
- Crear un par de claves pública/privada RSA de 2,048 bits
- Generar una solicitud de firma de certificado (CSR) que incorpore tu clave pública
- Compartir tu CSR con la autoridad certificadora (AC) para recibir un certificado final o una cadena de certificados
- Instalar 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 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 de openssl, que viene con la mayoría de los sistemas, entre estos, Linux, BSD y Mac OS X, para generar claves privadas y públicas, y una CSR.
Genera un par de claves pública/privada
Para comenzar, genera un par de claves RSA de 2,048 bits. Los ataques de adivinación de fuerza bruta pueden descifrar una clave más corta, 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 genera el siguiente resultado:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Genera 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
Muestra 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 tu CSR a una autoridad certificadora
Las diferentes autoridades certificadoras (AC) requieren que les envíes tus CSR de diferentes maneras. Estos pueden incluir el uso de un formulario en su sitio web o el envío de la CSR por correo electrónico. Algunas AC, o sus revendedores, incluso pueden automatizar parte o todo el proceso, lo que incluye, en algunos casos, la generación de pares de claves y CSR.
Envía la CSR a tu AC y sigue sus instrucciones para recibir el certificado o la cadena de certificados finales.
Las diferentes AC cobran diferentes cantidades de dinero por el servicio de garantizar tu clave pública.
También hay opciones para asignar tu clave a más de un nombre de DNS, incluidos varios nombres distintos (p.ej., todos los nombres de example.com, www.example.com, example.net y www.example.net) o nombres "comodín", como *.example.com.
Copia los certificados en todos tus servidores de frontend en un lugar al que no se pueda acceder a través de la Web, como /etc/ssl (Linux y Unix), o donde IIS (Windows) los requiera.
Habilita HTTPS en tus servidores
Habilitar HTTPS en tus servidores es un paso fundamental para brindar seguridad a tus páginas web.
- Usa la herramienta de configuración del servidor de Mozilla para configurar tu servidor para la compatibilidad con HTTPS.
- Prueba tu sitio periódicamente con la prueba de servidor SSL de Qualys y asegúrate de obtener al menos una A o A+.
En este punto, debes tomar una decisión operativa crucial. Elige una de las siguientes opciones:
- Dedica una dirección IP distinta a cada nombre de host desde el que tu servidor web entrega contenido.
- Usa el hosting virtual basado en nombre.
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 el hosting virtual basado en nombre para conservar las direcciones IP y porque es más conveniente en general.
Si aún no tienes el servicio HTTPS disponible en tus servidores, habilítalo ahora (sin redireccionar HTTP a HTTPS). Consulta Cómo redireccionar HTTP a HTTPS para obtener más información. Configura tu servidor web para que use los certificados que compraste y que instalaste. Puede que te resulte útil el generador de configuración de Mozilla.
Si tienes muchos nombres de host o subdominios, cada uno debe usar el certificado correcto.
Ahora, y con regularidad durante el ciclo de vida de tu sitio, verifica la configuración de HTTPS con la prueba del servidor SSL de Qualys. Tu sitio debe obtener una calificación A o A+. Considera como un error todo lo que cause una calificación más baja y mantén la diligencia, ya que siempre se están desarrollando nuevos ataques contra algoritmos y protocolos.
Haz que las URLs intrasitio sean relativas
Ahora que publicas tu sitio en HTTP y HTTPS, todo debe funcionar de la manera más fluida posible, independientemente del protocolo. Un factor importante es usar URLs relativas para los vínculos intrasitio.
Asegúrate de que las URLs internas y externas no dependan de un protocolo específico.
Usa rutas de acceso relativas o omite el protocolo como en //example.com/something.js.
La entrega de una página que contiene recursos HTTP a través de HTTPS puede causar problemas. Cuando un navegador encuentra una página que, de otro modo, es segura, pero que usa recursos no seguros, advierte a los usuarios que la página no es completamente segura y algunos navegadores se niegan a cargar o ejecutar los recursos HTTP, lo que hace que la página falle. Sin embargo, puedes incluir recursos HTTPS de forma segura en una página HTTP. Para obtener más orientación sobre cómo solucionar estos problemas, consulta Cómo corregir el contenido mixto.
Seguir 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 intrasitio sean lo más
relativas posible, ya sea que sean relativas al protocolo (sin un
protocolo, comienzan con //example.com) o relativas al host (comienzan solo con
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>
<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>
<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>
Actualiza tus vínculos con una secuencia de comandos, no de forma manual, para evitar cometer errores. Si el contenido de tu sitio se encuentra en una base de datos, prueba la secuencia de comandos en una copia de desarrollo de la base de datos. Si el contenido de tu sitio solo consiste en archivos simples, prueba la secuencia de comandos en una copia de desarrollo de los archivos. Envía los cambios a producción solo después de que los cambios pasen QA, como de costumbre. Puedes usar la secuencia de comandos de Bram van Damme o algo similar para detectar contenido mixto en tu sitio.
Cuando crees vínculos a otros sitios (en lugar de incluir recursos de ellos), no cambies el protocolo. No tienes control sobre cómo operan esos sitios.
Para que la migración sea más fluida en sitios grandes, te recomendamos que uses URLs relativas al protocolo. Si aún no estás seguro de poder implementar HTTPS por completo, forzar a tu sitio a usar HTTPS para todos los subrecursos puede ser contraproducente. Es probable que haya un período en el que HTTPS sea nuevo y extraño para ti, y el sitio HTTP siga funcionando tan bien como siempre. Con el tiempo, completarás la migración y bloquearás HTTPS (consulta las siguientes dos secciones).
Si tu sitio depende de secuencias de comandos, imágenes y otros recursos que se entregan desde un tercero, como una CDN o jquery.com, tienes dos opciones:
- Usa URLs relativas al protocolo para estos recursos. Si el tercero no usa HTTPS, pídele que lo haga. La mayoría ya lo hace, incluido jquery.com.
- Publica los recursos desde un servidor que controles, que ofrezca HTTP y HTTPS. De cualquier manera, esta suele ser una buena idea, ya que así tienes un mejor control sobre el aspecto, el rendimiento y la seguridad de tu sitio, y no tienes que confiar en un tercero para mantenerlo seguro.
Redirecciona HTTP a HTTPS
Para indicarles a los motores de búsqueda que usen HTTPS para acceder a tu sitio, coloca un vínculo canónico al comienzo de cada página con etiquetas <link rel="canonical" href="https://…"/>.
Activa la seguridad de transporte estricta y las cookies seguras
En este punto, 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 establece la marca de seguridad en las cookies.
Primero, usa la Seguridad de transporte estricta para indicarles a los clientes que siempre deben conectarse a tu servidor con HTTPS, incluso cuando siguen una referencia de http://. Esto evita ataques como la eliminación de SSL y evita el costo de ida y vuelta de 301 redirect que habilitamos en Redirecciona HTTP a HTTPS.
Para activar el HSTS, configura el encabezado Strict-Transport-Security. La página de HSTS de OWASP tiene vínculos a instrucciones para varios tipos de software de servidor.
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 (como para la autenticación o las 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 correctamente.
Para evitar esto, cambia tu app web para que siempre establezca la marca de seguridad en las cookies que configura. 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 indicarles a los motores de búsqueda y 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 positivo de calidad de la búsqueda. Google también publica una guía sobre cómo transferir, mover o migrar tu sitio y 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 sugerencias), las preocupaciones restantes sobre el rendimiento de TLS suelen ser pequeñas en comparación con el costo general de la aplicación. También puedes reducir y amortizar esos costos. Para obtener sugerencias sobre la optimización de TLS, consulta High Performance Browser Networking de Ilya Grigorik, así como OpenSSL Cookbook y Bulletproof SSL And TLS de Ivan Ristic.
En algunos casos, TLS puede mejorar el rendimiento, principalmente como resultado de que hace posible HTTP/2. Para obtener más información, consulta la conferencia de Chris Palmer sobre el rendimiento de HTTPS y HTTP/2 en Chrome Dev Summit 2014.
Encabezados de referencia
Cuando los usuarios siguen vínculos de tu sitio HTTPS a otros sitios HTTP, los agentes de usuario no envían el encabezado de Referer. Si esto es un problema, hay varias formas de resolverlo:
- Los demás sitios deben migrar 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 a los suyos de
http://ahttps://o usar vínculos relativos al protocolo. - Para solucionar una variedad de problemas con los encabezados de Referer, usa el nuevo estándar de la política de referencia.
Ingresos publicitarios
Los operadores de sitios que monetizan su sitio mostrando anuncios quieren asegurarse de que la migración a HTTPS no reduzca las impresiones de anuncios. Sin embargo, debido a problemas de seguridad del contenido mixto, un <iframe> HTTP no funciona en una página HTTPS.
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 migren a HTTPS, los anunciantes tendrán poca motivación para publicar contenido a través de HTTPS.
Puedes comenzar el proceso para romper este punto muerto usando anunciantes que ofrezcan servicios de anuncios a través de HTTPS y pedirles a los anunciantes que no publican anuncios a través de HTTPS que, al menos, lo incluyan como una opción. Es posible que debas aplazar la finalización de la opción Hacer que las URLs intrasitio sean relativas hasta que suficientes anunciantes interactúen correctamente.