TEORÍA

Un certificado digital es un par de claves privada y pública (usadas para el establecimiento de una comunicación segura siguiendo el protocolo Diffie-Hellman) firmado por una Autoridad Certificadora, que es una empresa (institución, organismo, etc) que será objetiva e imparcial, esto es, que no usará los datos de un certificado digital de forma fraudulenta ni maliciosa y que además da veracidad de la identificación de la persona/empresa que está usando el certificado.

La Autoridad Certificadora (o CA en inglés) genera las claves (o se le mandan en la petición del certificado) y genera y firma el certificado (a cambio de pasta, por supuesto) para que los navegadores web (entre otros) sepan que ese certificado es de confianza (obviamente los navegadores web tienen una BD con las CA’s confiables).

Al conectarse a una página web mediante el protocolo HTTPS nos devuelve el certificado con la clave pública y la información del firmante. Cuando nos encontramos con un certificado cuya firma no pertenece a ninguna CA confiable, normalmente obtenemos un mensaje en el navegador como este:

Para una aplicación Web interna de nuestra empresa o algo similar no tiene mayor importancia que añadir este certificado a la lista de excepciones para que se confíe en él y se pueda usar una comunicación segura.

Pero cuando nuestra página está de cara al público no podemos permitir que aparezca un mensaje tan alarmante como este (ya que los usuarios no confiarán en nuestra página), y es en ese momento cuando tenemos que usar un certificado SSL firmado por una CA.

Hay algunas CA confiables gratuitas como Let’s Encrypt, pero para un sistema interno, como una aplicación web corporativa interna, valdría con un certificado auto-firmado.

NOTA: En muchas ocasiones, un certificado no es firmado por una sola CA, sino que hay una cadena de CA’s firmantes; teniendo en el nivel superior de la cadena las más confiables (como VeriSign). Digamos que es una «cadena de confianza» de CA’s.

DOCUMENTO CSR

Habitualmente, cuando vamos a solicitar un certificado SSL a una CA, tenemos que crear y enviar a la misma un documento CSR (Certificate Signing Request) en el cual incluimos la información de la empresa y el dominio que queremos proteger mediante HTTPS, además de la clave privada y pública. En estos CSR’s se incluye la siguiente información:

Obtenido de https://support.rackspace.com/how-to/generate-a-csr-with-openssl/

IMPORTANTE: nótese que un certificado SSL también puede ser llamado certificado TLS o SSL/TLS, pero esto no determina si el algoritmo de cifrado va a ser SSL o TLS (más información).

ESTÁNDAR Y FORMATOS

La forma del certificado, la información que se incluye en él y demás, viene determinado por un estándar del sector de la normalización de las telecomunicaciones (UIT-T) llamado «X.509» en el cual se indica que la sintaxis usada para «rellenar» el documento es el ASN.1 (Abstract Syntax Notation One).

Existen varios formatos de almacenar y codificar un certificado, los más comunes son:

PEM (Privacy Enhanced Mail) y DER (Distinguish Encoding Rules): Son certificados que incluyen la clave pública pero no la clave privada (esta última se almacena en otro archivo de extensión «.key«). Las extensiones de archivo más comunes son: .pem, .crt, .cer y .der. La diferencia entre PEM y DER es su codificación: DER se codifica en binario y PEM se codifica en ASCII.

PKCS#7: Es un paquete de certificados (se almacenan varios certificados en el archivo). Tampoco incluye la clave privada en él. Windows lo define como «Estándar de sintaxis de cifrado de mensajes». Las extensiones de archivo más comunes son: .p7b y p7c

PKCS#12: Es un paquete de certificados y claves privadas (encriptadas bajo una contraseña maestra definida por el usuario). Windows lo define como archivo para el intercambio de información personal (identificativo). Las extensiones de archivo más comunes son: .pfx y .p12

OTROS FORMATOS

BKS: formato de certificado para aplicaciones Java que almacena las claves públicas que se necesite usar en el código. Se suele emplear como «pinned certificates» (certificados incrustados) en aplicaciones Java que tienen que conectar con servidores a través de un socket seguro (HTTPS por ejemplo) que hagan uso de certificados firmados por CA’s no confiables (por ejemplo, un certificado auto-firmado). Este tipo de certificados se «incrustan» en la aplicación Java para que esta sepa que se puede confiar en el certificado del servidor. Este formato es creado por uno de los proveedores de APIs criptográficas de Java: «The Bouncy Castle«.