Creando tu propia Entidad Certificadora SSL (y volcando certificados autofirmados)

Otro artículo que no es mío original, pero sinceramente, la idea que tengo de certificados es la justa. Este artículo ma ha parecido que va al grano y que cuenta por qué aparece el incómodo mensaje de “certificado no confiable” y cómo evitarlo.

El artículo original es Creating Your Own SSL Certificate Authority (and Dumping Self Signed Certs), y creo que el autor es Tony Bourke, mirando los comentarios.

Espero que os parezca tan interesante como a mí, aunque el último ejemplo lo he añadido sólo por completitud.

SSL (o TSL si se quiere ser totalmente correcto) nos ofrece muchas cosas (a pesar de los defectos aparecidos recientemente):

• Privacidad (deja de mirar mi password)
• Integridad (los datos no se han modificado al vuelo)
• Confianza (eres quien dices ser)

Se necesitan las tres cuando se construye algo en Amazon (¡maldito seas, Amazon Prime!). Pero también se utiliza SSL para las interfaces de usuario web y otras GUI cuando se administras dispositivos bajo nuestro control.

Cuando un website obtiene un certificado SSL, típicamente lo compra a una de las principales entidades certificadoras como DigiCert, Symantec (compraron la sección de registros de Verisign), o si te gusta el asesino de elefantes y libertad, GoDaddy. Oscilan entre $12 USD a varios cientos al año, dependiendo de la compañía y del nivel de confianza.

El beneficio que ofrecen estas entidades certificadoras consiste en una cadena de confianza. Tu navegador confía en ellas, ellas confían en un website, por lo que tu navegador confía en el website (se puede revisar su artículo sobre confianza SSL, que contiene el mejor diagrama SSL jamás imaginado).

Nuestros dispositivos, por otra parte, aquéllos que configuras y a los que sólo accede tu organización, no necesitan esa cadena de confianza sobre infrastructuras públicas. Lo primero, puede resultar realmente caro comprar un certificado SSL para cada dispositivo que se controla. Y segundo, fuiste tú quien levantó esos dispositivos, por lo que no necesitas ese nivel de confianza.

Por eso las interfaces de usuario web (y otras interfaces basadas en SSL) casi siempre se protegen con certificados autofirmados. Son realmente sencillos de crear y gratuítos. También proporcionan toda la seguiridad que implica la encriptación, aunque no hacen nada sobre la confianza. Por esa razón, cuando te conectas a un dispositivo con un certificado autofirmado verás algo como esto:

Por lo que tienes la elección, comprar un costoso certificado SSL de una CA (Entidad Certificadora) u obtener esos errores. Bueno, hay una tercera opción, que es crear una entidad certificadora privada y venderlos completamente gratis.

OpenSSL

OpenSSL es una herramienta libre que viene en la mayoría de las instalaciones de MacOS X, Linux, *BSD y Unix. También se puede descargar el binario para instalaciones Windows. Y OpenSSL es todo lo que se necesita para crear una entidad certificadora privada.

El proceso para crear tu propia entidad certificadora es muy simple:

1. Crear una clave privada.
2. Autofirmarla
3. Instalar la CA raíz en varias máquinas.

Una vez hecho esto, cada dispositivo que se maneje vía HTTPS sólo necesita tener creado su propio certificado con los pasos siguientes:

1. Crear un CSR por dispositivo.
2. Firmar el CSR con la clave CA raíz.

Puedes tener configurada la CA raíz en menos de una hora. Y aquí viene cómo hacerlo.

Crear el Certificado Raíz (se hace una vez)

Crear el certificado raíz es fácil y se hace rápidamente. Con estos sencillos pasos se obtiene un certificado SSL raíz que se instalará en todos los escritorios, y una clave privada que se utilizará para firmar los certificados que se instalan en varios dispositivos.

Crear la clave raíz

El primer paso es crear la clave raíz privada que sólo requiere un paso. En el ejemplo de abajo, estoy creando una clave de 2048 bits:

1

openssl genrsa -out rootCA.key 2048

Los tamaños de clave estándar actuales son 1024, 2048 y, aunque mucho menos extendido, 4096. Yo he elegido 2048, que es el más utilizado hoy en día. 4096 suele ser una exageración (y las claves con longitud 4096 es 5 veces más intensa computacionalmente que 2048), y se está abandonando 1024.

Nota importante: Mantener esta clave privada muy privada. Ésta es la base de toda confianza para tus certificados, y si alguien obtiene una copia, podría generar certificados que acepte el navegador. También se puede crear una clave que esté protegida mediante una contraseña añadiendo -des3:

1

openssl genrsa -out rootCA.key 2048 -des3

Se pedirá que se introduzca una contraseña, y desde entonces se retará a introducir la contraseña cada vez que se use la clave. Claro, si olvidads la clave tendrás que hacer todo esto de nuevo.

El siguiente paso es autofirmar este certificado

1

openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem

Lo que comenzará un script interactivo que preguntará varios bits de información. Se rellenarán como vea conveniente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

   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]:US
   State or Province Name (full name) [Some-State]:Oregon
   Locality Name (eg, city) []:Portland
   Organization Name (eg, company) [Internet Widgits Pty Ltd]:Overlords
   Organizational Unit Name (eg, section) []:IT
   Common Name (eg, YOUR name) []:Data Center Overlords
   Email Address []:none@none.com

Una vez hecho, se creará un certificado SSL llamado rootCA.pem, firmado por sí mismo, válido durante 1024 días, y que funcionará como tu certificado raíz. Lo más interesante de las autoridades certificadoras tradicionales es que ese certificado raíz está también autofirmado. Pero antes de comenzar una entidad certificadora propia, recuerde que el truco es mantener estos certificados en cada navegador del mundo.

Instalar el certificado raíz en las máquinas

Para los portátiles/sobremesas/terminales, se necesitará instalar el certificado raíz en los repositorios de certificados confiables. Lo que puede ser un poco difícil.

Algunos navegadores utilizan el repositorio por defecto del sistema operativo. Por ejemplo, en Windows tanto IE como Chrome usan la gestión por defecto de certificados. Vaya a IE, Internet Options, a la pestaña Contenido/Content, y pulse el botón Certificados/Certificates. En Chrome vaya a Opciones/Settings, Mostrar opciones avanzadas/Show advanced settings y Manejar certificados/Manage certificates. Lo que se pretende es instalar el certificado CA raíz (no la clave) bajo la pestaña Trusted root Certificate Authorities.

Por el contrario, en Windows Firefox tiene su propio repositorio de certificados, por lo que si se utiliza IE o Chrome tanto como Firefox, se tendrá que instalar el certificado raíz tanto en el repositorio de Windows como en el de Firefox.

En Mac, Safari, Firefox y Chrome utilizan el sistema de gestión de certificados del Mac OS X, por lo que sólo se tendrá que instalar una vez. En Linux, creo que se gestiona desde cada navegador.

Crear un certificado (hacer una vez por dispositivo)

Será necesario seguir este proceso para cada dispositivo en el que se desee instalar un certificado confiable. Primero, al igual que con el paso del CA raíz, se necesita una clave privada (diferente de la del CA raíz).

1

openssl genrsa -out device.key 2048

Una vez creada la clave, se generará la solicitud de firmado de certificado:

1

openssl req -new -key device.key -out device.csr

El sistema realizará varias preguntas (País, Región/Provincia, etc.). Responder según corresponda. Sin embargo, la pregunta importante es common-name.

1

Common Name (eg, YOUR name) []: 10.0.0.1

Lo que se ve en el campo de la dirección del navegador cuando se accede a tu dispositivo debe ser lo que se ponga bajo el common name, incluso si es una dirección IP. Sí, incluso una dirección IP (IPv4 o IPv6) funciona como common name.

Si no se corresponden, incluso un certificado firmado adecuadamente no se validará adecuadamente, y se obtendrá el error de que “No se puede verificar la autenticidad”.

Una vez hecho esto, se firmará el CSR, lo que requiere la clave CA raíz:

1

openssl x509 -req -in device.csr -CA root.pem -CAkey root.key -CAcreateserial -out device.crt -days 500

Esto crea un certificado autofirmado llamado device.crt que es válido durante 500 días (se puede ajustar el número de días, claro, pero no tiene sentido que sea mayor que el del certificado raíz).

El paso siguiente consiste en coger la clave y el certificado e instalarlos en el dispositivo. La mayoría de los dispositivos de red que se controlan mediante HTTPS tienen algún mecanismo para instalarlo. Por ejemplo, tengo un LTM VE (virtual edition) F5 como máquina virtual en mi host ESXi 4.

Entro en la GUI web del F5 (y debería ser la última vez que saluda el aviso) y voy a System, Device Certificates, y Device Certificate:

En el desplegable selecciono Certificate and Key, y bien puedo pegar el contenido de los ficheros con la clave y el certificado o puedo subirlos desde mi máquina:

Después, todo lo que necesito hacer es cerrar el navegador y volver a entrar en la web del GUI. Si todo fue bien, no habrá aviso y se obtendrá un precioso verde en la barra de navegación:

Y hablando de VMWare, ¿os suena, quizá, el molesto mensaje que se ve cuando se conecta contra un servidor ESXi?

Se puede eliminar creando una clave y certificado para el servidor ESXi e instalándola en /etc/vmware/ssl/rui.crt y /etc/vmware/ssl/rui.key.