En esta página, se proporcionan instrucciones para configurar HTTPS en tus servidores, incluidos los siguientes pasos:
- Crea un par de claves pública/privada de RSA de 2,048 bits.
- Genera una solicitud de firma de certificado (CSR) que incluya 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 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 ofrece 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 descifrado por fuerza bruta pueden romper 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 obligatorios.
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 la CSR a una autoridad de certificación
Distintas 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 el proceso de manera parcial o total, incluida, en algunos casos, la generación de pares de claves y de la CSR.
Envía la CSR a tu AC y sigue sus instrucciones para recibir el certificado final o la cadena de certificados.
Las AC cobran diferentes montos de dinero por el servicio de certificación de tu clave pública.
También se ofrece la opción de asignar tu clave a más de un nombre de DNS, incluidos
varios nombres diferentes (p.ej., todas las instancias de example.com, www.example.com, example.net
y www.example.net) o nombres “comodín”, como *.example.com.
Copia los certificados a 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 en cualquier lugar donde lo requiera IIS (Windows).
Habilita HTTPS en tus servidores
La habilitación de 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 regularmente tu sitio con la SSL Server Test 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:
- Dedicar una dirección IP diferente para cada nombre de host del que obtiene contenido tu servidor web
- Utilizar el hosting virtual basado en nombres
Si has utilizado distintas direcciones IP 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, resulta más conveniente.
Si el servicio HTTPS aún no está 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 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 deberá usar el certificado correcto.
Ahora mismo, y con regularidad durante el tiempo que dure tu sitio, verifica la configuración de HTTPS con la SSL Server Test de Qualys. Tu sitio debe obtener una puntuación de A o A+. Considera como error todo aquello que genere una calificación inferior y mantén la diligencia, ya que siempre se están desarrollando nuevos ataques contra algoritmos y protocolos.
Cómo 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.
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, les 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.
Si sigues vínculos basados en HTTP a otras páginas de tu sitio, también se puede degradar 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 de protocolo (no tienen un protocolo, comienzan con //example.com) o relativas de 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>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>O bien, usa URLs intrasitio relativas al protocolo.
<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 los vínculos a otros sitios siempre que sea posible.
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 tu secuencia de comandos en una copia de desarrollo de la base de datos. Si el contenido de tu sitio consiste solo en archivos simples, prueba tu secuencia de comandos en una copia de desarrollo de los archivos. Aplica los cambios a producción únicamente luego de que estos aprueben el control de calidad, como siempre. Puedes usar la secuencia de comandos de Bram van Damme o algo similar para detectar contenido mixto en tu sitio.
Cuando realices vinculaciones a otros sitios (que es diferente de incluir recursos de otros sitios), no cambies el protocolo. No tienes control sobre el modo en que operan esos sitios.
Para que la migración de sitios grandes se realice sin problemas, recomendamos usar URLs relativas de protocolo. Si no estás seguro de si ya puedes implementar HTTPS por completo, forzar a tu sitio para que use HTTPS para todos los subrecursos podría tener consecuencias negativas. Es posible que durante algún tiempo HTTPS resulte nuevo y extraño. De todos modos, el sitio HTTP debe funcionar tan bien como siempre. Con el tiempo, completarás la migración y podrás utilizar HTTPS definitivamente (consulta las dos secciones siguientes).
Si tu sitio depende de secuencias de comandos, imágenes o otros recursos ofrecidos por un tercero, como una CDN o jquery.com, tienes dos opciones:
- Usa URLs relativas de protocolo para estos recursos. Si el tercero no ofrece HTTPS, pídele que lo haga. La mayoría de ellos ya lo hacen, incluido jquery.com.
- Ofrece los recursos desde un servidor que controles y en el que se ofrezca tanto HTTP como HTTPS. De todos modos, esta suele ser una buena idea, ya que luego puedes tener mejor control sobre la apariencia, el rendimiento y la seguridad de tu sitio, y no tienes que confiar en un tercero para mantenerlo seguro.
Redirecciona HTTP a HTTPS
Para indicar a los motores de búsqueda que usen HTTPS para acceder a tu sitio, coloca un vínculo canónico en el encabezado 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 está todo listo para usar HTTPS de forma segura:
- Usa la seguridad de transporte estricta de HTTP (HSTS) para evitar el costo del redireccionamiento mediante el código 301.
- Configura siempre el marcador Secure para las cookies.
En primer lugar, usa la seguridad de transporte estricta para indicar a los clientes que siempre deben conectarse a tu servidor a través de HTTPS, incluso cuando sigan una referencia http://. De esta forma, se frustran los ataques como la eliminación de SSL y se evita el costo de ida y vuelta del 301 redirect que habilitamos en Redirecciona de HTTP a HTTPS.
Para activar HSTS, establece el encabezado Strict-Transport-Security. La página de HSTS de OWASP tiene 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 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 el marcador Secure en las cookies que configure. En esta página de OWASP, se explica cómo configurar el marcador Secure en varios frameworks de apps. Cada framework de aplicación tiene una forma de establecer la marca.
La mayoría de los servidores web ofrecen una función simple de redireccionamiento. 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 redireccionar a tus usuarios de la versión HTTP a la versión HTTPS de tu sitio.
Clasificación de búsqueda
Google usa HTTPS como indicador de buena calidad de búsqueda. Google también publica una guía sobre cómo transferir, mover o migrar tu sitio y seguir manteniendo su clasificación de búsqueda. Bing también publica pautas para webmasters.
Rendimiento
Cuando las capas de contenido y aplicaciones están bien configuradas (consulta los libros de Steve Souders para obtener consejos), las inquietudes restantes sobre el rendimiento de TLS suelen ser pequeñas en relación con el costo total de la aplicación. También puedes reducir y amortizar esos costos. Para obtener consejos 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, la TLS puede mejorar el rendimiento, principalmente porque permite que HTTP/2 sea posible. 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 del 2014.
Encabezados de referencia
Cuando los usuarios siguen los vínculos desde tu sitio HTTPS a otros sitios HTTP, los agentes de usuario no envían el encabezado de referencia. Si esto representa un problema, se puede solucionar de varias maneras:
- Se deben migrar los otros sitios a HTTPS. Si los sitios de referencia completan la sección Habilitación de HTTPS en tus servidores de esta guía, puedes cambiar los vínculos de tu sitio por los de ellos, de
http://ahttps://, o bien puedes usar vínculos relativos de protocolo. - Usa el nuevo estándar de la política de referencias para solucionar provisoriamente diferentes problemas con los encabezados de referencia.
Ingresos publicitarios
A los operadores de sitios que monetizan su sitio mediante anuncios les conviene asegurarse de que la migración a HTTPS no reduzca las impresiones de los anuncios. Sin embargo, debido a las inquietudes de seguridad por contenido mixto, un <iframe> HTTP no funciona en una página HTTPS.
Hasta que los anunciantes publiquen en HTTPS, los operadores de sitios no podrán realizar migraciones a HTTPS sin perder ingresos por anuncio; sin embargo, hasta que los operadores de sitios no migren a HTTPS, los anunciantes no tendrán motivación para publicar en HTTPS.
Para comenzar el proceso de romper este punto muerto, puedes usar anunciantes que ofrezcan servicios de anuncios a través de HTTPS y pedirles a los anunciantes que no publican anuncios en HTTPS que, al menos, lo incluyan como opción. Es posible que debas posponer la sección Haz las URLs dentro del sitio relativas hasta que una cantidad suficiente de anunciantes interoperen adecuadamente.