Pasos que se describen en este artículo
- Crea un par de claves públicas/privadas de RSA de 2,048 bits.
- Genera una solicitud de firma de certificado (CSR) que incluya tu clave pública.
- Comparte tu CSR con tu autoridad certificada (CA) 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 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ública/privada
Comencemos generando 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 2048.
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 el 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
Y la respuesta debería verse así:
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 certificadas (CA) requieren métodos distintos para enviarles tus CSR. Los métodos pueden incluir el uso de un formulario en su sitio web, el envío de la CSR por correo electrónico o alguna otra cosa. Algunas CA (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 CSR).
Envía la CSR a tu CA y sigue sus 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 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.
Por ejemplo, una AC actualmente ofrece los siguientes precios:
- Estándar: USD 16 al año; válido para example.com y www.example.com
- Comodín: $150/año; válido para example.com y *.example.com
Con 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 para un solo nombre. (por ejemplo, si tienes más de cinco subdominios, es posible que un certificado comodín te resulte más conveniente cuando decidas habilitar HTTPS en tus servidores).
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
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 tu sitio periódicamente con la práctica herramienta 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:
- Dedica una dirección IP distinta a 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 en las versiones anteriores a Android 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 string del usuario-agente en tus registros de solicitudes para saber cuándo se migró suficiente población de usuarios al software moderno. (puedes decidir cuál es tu umbral; tal vez sea 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 configuración práctico de Mozilla puede resultarte útil.
Si tienes muchos nombres de host o subdominios, cada uno debe usar el certificado correcto.
Ahora, y durante todo el ciclo de vida de tu sitio, verifica la configuración de HTTPS con la práctica herramienta SSL Server Test 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. (Una A de hoy será la B de mañana, ya que los ataques contra los algoritmos y los protocolos siempre están mejorando).
Haz que las URLs dentro del sitio sean relativas
Ahora que entregas tu sitio tanto en HTTP como en HTTPS, debe funcionar de la manera 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 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 les advierten a los usuarios que se perdió la potencia total de HTTPS. De hecho, en el caso del contenido mixto activo (secuencias de comandos, complementos, CSS o iframes), a menudo, los navegadores no cargan ni ejecutan el contenido en absoluto, lo que genera una página rota. Recuerda que es perfectamente 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 pasar de HTTPS a HTTP.
Estos problemas se presentan cuando tus páginas incluyen URLs dentro del sitio completas que usan el esquema http://.
<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 usar 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 (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 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 un guion, 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. Como de costumbre, envía los cambios a producción solo después de que estos aprueben el control de calidad. Puedes usar la secuencia de comandos de Bram van Damme o algo similar para detectar contenido mixto en tu sitio.
Cuando vincules otros sitios (a diferencia de incluir recursos de ellos), no cambies el protocolo, ya que no tienes control sobre el funcionamiento de esos sitios.
A fin de que la migración de sitios grandes se realice sin problemas, recomendamos las URL relativas de protocolo. Si aún no estás seguro de que puedes implementar HTTPS por completo, es posible que forzar a tu sitio a usar HTTPS para todos los subrecursos no sea un problema. Es probable que haya un período en el que HTTPS sea nuevo y raro para ti, y el sitio HTTP 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 entregado por un tercero, como una 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 en el que se ofrezcan HTTP y HTTPS. De todos modos, esta suele ser una buena idea, ya que así tendrás 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 tu página para indicarles a los motores de búsqueda que HTTPS es la mejor manera 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 acceder a tu sitio.
Activa la Seguridad de transporte estricta y las cookies seguras
En este punto, 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 configurar la marca Secure en las cookies
Primero, usa la Seguridad de transporte estricta para indicar a los clientes que siempre deben conectarse a tu servidor a través de HTTPS, incluso si siguen una referencia http://. Esto anula los ataques como la eliminación de SSL y también evita el costo de ida y vuelta del 301 redirect que habilitamos en Redirecciona de HTTP a HTTPS.
Para activar el HTTP con Seguridad de Transporte Estricta (HSTS), configura el encabezado Strict-Transport-Security. En la página de HSTS de OWASP, encontrarás vínculos a instrucciones para varios software del 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 (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 estuviera expuesta en texto sin formato, la garantía de seguridad de toda su sesión se destruiría, incluso si hiciste bien todo lo demás.
Por lo tanto, cambia la aplicación web para que siempre establezca 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 aplicaciones. Todos los frameworks de aplicaciones tienen 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 redireccionar a los usuarios a la versión HTTPS de tu sitio desde la 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 configuradas (consulta los libros de Steve Souders para obtener excelentes consejos), los problemas restantes con el rendimiento de TLS son, por lo general, menores en relación con el costo total 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 Bulletproof SSL And TLS de Ivan Ristic.
En algunos casos, TLS puede mejorar el rendimiento, principalmente porque permite que HTTP/2 sea posible. 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 los vínculos desde tu sitio HTTPS a otros sitios HTTP, los usuarios-agentes no envían el encabezado de referencia. Si esto es un problema, hay varias formas de resolverlo:
- Se deben migrar los otros sitios a HTTPS. Si los sitios de referencia pueden completar 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://ahttps://, o puedes usar vínculos relativos de protocolo. - Para solucionar una variedad de problemas con los encabezados de referencia, usa el nuevo estándar de la política de referencias.
Debido a que los motores de búsqueda están migrando a HTTPS, en el futuro es probable que veas más encabezados de referencia cuando migres a HTTPS.
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 anuncios. Sin embargo, debido a las inquietudes de seguridad por el contenido mixto, un HTTP <iframe> no funciona en una página HTTPS. Existe un problema de acción colectiva complicado: 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.
Los anunciantes deben, al menos, ofrecer servicios publicitarios 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ía pedirles a los anunciantes que no publican HTTPS que al menos comiencen a hacerlo. Te recomendamos que postergues 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 correcta.