Extensiones de fichero

Vamos a hablar de muchos formatos distintos, que son normalmente ficheros de texto plano, pero que no tienen una extensión de archivo estandarizada; de hecho, es irrelevante. De todas formas, os iré diciendo cuál es la más habitual para cada uno.

Normalmente el nombre del fichero es el dominio seguido de la extensión. En los ejemplos usaré example.com como dominio, así que los ficheros quedarán en formato example_com.pem o parecido.

Prerrequisitos

Para operar con todo tipo de certificados necesitamos instalar OpenSSL:

$ pkcon install openssl

El formato X.509

Este es el formato de claves que utilizan la mayoría de servidores web. Por lo tanto, gran parte del esfuerzo es convertir de cualquier PKCS a X.509.

La extensión de archivo a veces varía dependiendo de qué contenga el fichero.

• Si contiene la cadena de autorizaciones: .ca-bundle, .ca o .ca.pem.
• Si contiene el certificado sin claves: .crt o .crt.pem.
• Si contiene la clave privada (ver abajo): .key o .key.pem.
• Si contiene todo, o por defecto: .pem.

Lo más cómodo es meterlo todo en un mismo fichero. Más abajo verás los comandos que hay que usar para cada caso.

La clave privada RSA

Cuando hablamos de criptografía de clave pública/privada, el objetivo básico del funcionamiento es el siguiente:

• Si yo encripto un mensaje con tu clave pública, sólo tú puedes desencriptarlo con tu clave privada.
• Si yo firmo un mensaje con mi clave privada, cualquiera puede comprobar que yo he emitido ese mensaje utilizando mi clave pública.

Teniendo esto en cuenta, existen diversos algoritmos de clave pública/privada. El que probablemente necesites utilizar será RSA, así que nos centraremos en ese.

Seguridad

Por todo lo explicado anteriormente, es imprescindible que nadie tenga acceso a tu clave privada. Es de esperar que tengas bien claro el sistema de permisos de tu servidor para evitar este tipo de accesos, ya que con acceso a tu clave privada, un atacante podría suplantarte sin posibilidad de comprobar si eres tú o él.

Por otro lado, la clave pública puede saberla todo el mundo. De hecho, si nadie la sabe, no puede cumplir su objetivo.

Las claves privadas pueden ir protegidas por contraseña o no. Para un servidor web con HTTPS, lo más normal es que vaya sin contraseña (de otro modo, al reiniciar el servidor deberías proporcionarla).

Dentro de cada algoritmo, también está la longitud de la clave. Evidentemente, cuanto más larga, más difícil de desencriptar por fuerza bruta.

La longitud mínima recomendable hoy en día es de 2048 bytes, así que yo te recomendaría usar claves de 4096 bytes.

Para generar una clave RSA:

$ openssl genrsa -out example_com.key.pem 4096

... o también la puedes generar al mismo tiempo que el PKCS#10 (ver abajo).

Transformar X.509 en PKCS#12

Si tienes un fichero de clave y uno de certificados, lo puedes convertir en PKCS#12 (ver abajo) así:

$ openssl pkcs12 -export -in example_com.crt.pem -inkey example_com.key.pem -out example_com.pfx

Los formatos PKCS

Significa Public-Key Cryptography Standards, y son los formatos que se utilizan para todo el proceso.

Generar el PKCS#10 (CSR)

Lo primero que hace falta cuando solicitas un certificado SSL es realizar un fichero de solicitud. Se conocen como CSR (Certificate Signing Request), y suelen tener la extensión .csr.

La forma de generarlo dependerá del objetivo:

• Para un nuevo certificado normalmente no tenemos una clave RSA, así que generamos ambos ficheros de un comando:

  $ openssl req -new -newkey rsa:4096 -nodes -keyout example_com.key.pem -out example_com.csr

• Para renovar un certificado, o para cuando ya tenemos la clave privada RSA generada previamente:

  $ openssl req -new -key example_com.key.pem -out example_com.csr

Convertir el PKCS#7 en PKCS#12

A veces, cuando estamos solicitando una renovación, se nos devolverá un fichero PKCS#7. Suelen tener la extensión .p7b.

Estos ficheros pueden contener la misma información que un PKCS#12 (ver abajo), salvo porque no incluyen la clave privada, que será la misma que para la solicitud original. Por lo tanto, para poder trabajar con él, necesitaremos tener previamente la clave privada, y lo más cómodo suele ser transformarlos a PKCS#12 para luego trabajar con ese formato, que es el más versátil. Para ello:

$ openssl pkcs7 -in example_com.p7b -print_certs -out example_com.crt.pem
$ openssl pkcs12 -export -in example_com.crt -inkey example_com.key.pem -out example_com.pfx

Si lo prefieres en un solo comando:

$ openssl pkcs7 -in example_com.p7b -print_certs | openssl pkcs12 -export -inkey example_com.key.pem -out example_com.pfx

Cualquiera de estos métodos nos pedirá una contraseña, pero en este caso sí que conviene darle una.

El formato PKCS#12

Este formato es el más cómodo de trabajar, ya que contiene toda la información en un solo archivo, normalmente con la extensión .pfx:

• Clave privada.
• Clave pública.
• Cadena de autoridades certificadoras.
• Puede protegerse con una contraseña. Por esto, es ideal para llevarte tus claves adonde quieras.

Muchos programas que manejan claves privadas y públicas (por ejemplo Firefox o IIS) aceptan este formato directamente, y ya gestionan las conversiones internamente.

Convertir de PKCS#12 a X.509

Para servidores Apache, Nginx o HAProxy necesitarás los certificados en X.509, así que vamos a ver cómo convertirlos.

Crear un X.509 con todo:

$ openssl pkcs12 -in example_com.pfx -nodes -out example_com.pem

Crear un X.509 con el certificado y la cadena de confianza, y otro con la clave privada:

$ openssl pkcs12 -in example_com.pfx -nokeys -out example_com.crt.pem
$ openssl pkcs12 -in example_com.pfx -nocerts -nodes -out example_com.key.pem

Crear un X.509 con el certificado, otro con la cadena de confianza, y otro más con la clave privada:

$ openssl pkcs12 -in example_com.pfx -nokeys -clcerts -out example_com.crt.pem
$ openssl pkcs12 -in example_com.pfx -nokeys -cacerts -out example_com.ca.pem
$ openssl pkcs12 -in example_com.pfx -nocerts -nodes -out example_com.key.pem

Instalar los certificados en el servidor

En este caso, cada servidor tiene su sistema (a veces varios), así que te recomiendo que repases la documentación para cada uno, o que uses el magnífico Generador de configuraciones SSL de Mozilla, que además te ayudará a evitar todo tipo de cifrados o conexiones vulnerables.