Renovar certificados SSL: Comprabar si el certificado, clave privada y el CSR coinciden (OpenSSL)

Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados.

Apache + configuración SSLCipher strong

# SSLCiphers strong encryption
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# SSL certs config
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/web/public.crt
SSLCertificateKeyFile /etc/apache2/ssl/web/private.key
SSLCertificateChainFile /etc/apache2/ssl/web/intermediate.crt

Nginx + configuración SSLCipher strong

ssl on;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# Fix 'The Logjam Attack'.

ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/dh2048_param.pem;

#SSL certs config

ssl_certificate /etc/nginx/ssl/web/intermediate.crt;

ssl_certificate_key /etc/nginx/ssl/web/private.key;

 

CA Bundle

Si disponemos de un fichero CA Bundle no es otra cosa que un certificado intermediate y raíz de la CA en un solo archivo, uno detrás del otro, debes combinarlos en uno solo para tener un CA_bundle completo. Los certificados raíz no son necesarios cuando se instala el certificado, para la instalación es suficiente activar en el servidor el correspondiente certificado intermediate.

El orden de los certificados es partir del dominio y hacia la raíz. Intermedio cert1, intermedio cert2 por encima y así sucesivamente.

La cadena es necesaria para mejorar la compatibilidad de los certificados con los navegadores web y otro tipo de clientes para que los navegadores reconozcan su certificado y no aparezcan advertencias de seguridad.

Comprobar la integridad

Para Comprobar la integridad de los ficheros de certificados, debemos revisar que la suma de verificación (checksum) es la misma para el certificado, la clave privada y el CSR (Certificate Signing Request). Los tres deben coincidir para ser válidos entre sí.

Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden. De ser así podría ser que el certificado no se hubiese creado con el mismo CSR o el CSR se ha creado con otra clave privada. Para comprobar estos valores podemos hacerlo mediante modulus usando OpenSSL.

Usando OpenSSL: MD5 y sha256sum

Certificado, clave privada, CSR: 

# openssl x509 -noout -modulus -in public.crt | md5
# openssl rsa -noout -modulus -in private.key | md5
# openssl req -noout -modulus -in intermediate.csr | md5

# openssl x509 -noout -modulus -in public.crt | sha256sum
# openssl rsa -noout -modulus -in private.key | sha256sum
# openssl req -noout -modulus -in intermediate.csr | sha256sum

Saludos!

OpenSSL - Convertir certificados digitales: .PFX .CSR .PEM .CRT o .CER y extraer la clave privada de certificados

En Windows Server cuando se genera un certificado autofirmado por el propio servidor este se puede exportar por defecto en formato .pfx. Los certificados en formato .pfx contienen tanto la clave pública como la privada.

Tipos de formatos más frecuentes de certificados

• .CSR (Certificate Signing Request): Sería el archivo generado normalmente por el servidor que usará el certificado SSL. El CSR contiene información relativa a la organización.
• .KEY: Es el archivo de clave de privada para cifrar las solicitudes.
• .DER (Distinguish Encoding Rules): Suelen tener la extensión CRT o CER. Es un tipo de codificación de certificados X.509, NO un tipo de certificado. Es un formato binario o raw.
• .CRT .CERT .CER .PEM (Privacy Enhanced Mail): Ambos son usados indistintamente. .pem contiene el certificado y la clave, mientras que un fichero .crt solo contiene el certificado. Generalmente codificado en Base64, encerrado entre "---BEGIN CERTIFICATE---" y "---END CERTIFICATE---".
• .CRL (Certificate Revocation List): Fichero que contiene una lista de recovación de certificados.
• .P7B .P7C: Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s)
• .PKCS12 (PKCS #12) .P12 .PFX: Se usa en servidores Windows. Contiene todos los archivos en un único archivo, tanto la clave pública como la clave privada asociada, generada por el servidor en el momento en el que se generó el CSR.

Si necesitamos extraer la clave privada podemos usar OpenSSL el cual utilizará uno de los estándares de criptografía PKCS (Public-Key Cryptography Standards) concretamente PKCS#12 (formatos .PFX) que define un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica (es decir, una passphrase o contraseña).

Exportamos el certificado autofirmado del servidor IIS. Estará en formato PKCS#12.

Figura 1: Exportando certificado del servidor IIS.

Podemos exportar dicho certificado del propio equipo local a través de la consola de Microsoft para la administración de certificados certmgr.msc. Agregar administrador de certificados a través de un MMC. En el asistente de exportación nos permite la opción de incluir la clave privada en el certificado.

Figura 2: Exportando certificado desde certmgr.msc

Descargar OpenSSL para Windows. A través de una CLI de Windows Server ejecutamos OpenSSL con PKCS12 para la obtención de la clave privada del certificado. Tendremos que extraer el certificado (clave pública), la clave privada (nos pedirá la contraseña en ambos casos) y finalmente eliminar el passphrase de la clave privada extraída.

Figura 3: Usando OpenSSL para la extracción de certificados.

Extraer la clave pública del certificado .pfx

openssl pkcs12 -in certificate.pfx -out public-certificate.cer -clcerts -nokeys

certificate.pfx: certificado pfx del servidor.

public-certificate.cer: clave pública, también se podría exportar a un formato de salida .crt o .pem.

-nokeys: separará la clave pública de la clave privada del certificado .pfx.

-clcerts: certificados de cliente (no certificados de CA).

Figura 4: Fichero de salida de la clave pública.

Extraer la clave privada del certificado .pfx

openssl pkcs12 -in certificate.pfx -out private-key.key -nocerts -nodes

certificate.pfx: certificado pfx del servidor.

private-key.key: clave privada, también se podría exportar a un formato de salida .crt o .pem.

-nocerts: separará la clave privada de la clave pública del certificado .pfx.

-nodes: no cifra la salida de la clave privada (quedando visible en texto plano).

Figura 5: Fichero de salida de la clave privada en texto plano (-nodes).

Extraer la clave pública, privada y cadena de certificados CA del certificado .pfx

openssl pkcs12 -in certificate.pfx -out ca-certificate.cer -cacerts -chain -nokeys

certificate.pfx: certificado pfx del servidor.

ca-certificate.cer: certificados CA, también se podría exportar a un formato de salida .crt o .pem.

-chain: incluye toda la cadena de certificados del certificado de usuario.

-cacerts: certificados CA (no certificados de cliente).

-nokeys: separará la clave pública de la clave privada del certificado .pfx.

Eliminar la contraseña de la clave privada extraída del certificado .pfx

openssl rsa -in claveprivada.pem -out claveprivadasinpassphrase.key

Figura 6: Fichero de salida de la clave privada sin passphrase.

Con esto finalmente tendremos la clave privada sin contraseña para poder utilizarla en lo que nos sea necesario.

Convertir certificados CRT, CRT (CA) y clave privada .key a un solo archivo PFX

En el caso de tener el archivo .crt del certificado en sí, el archivo .crt de la CA y el archivo de la clave privada en un .key. Para poder fusionar estos tres ficheros en un solo fichero .pfx (PKCS #12 por lo general, usado en sistemas Windows).

openssl pkcs12 -export -out certificate.pfx -inkey rsaprivate.key -in certificate.crt -certfile fileca.crt

• certificate.pfx: Certificado de salida en formato pfx.
• rsaprivate.key: La clave privada.
• certificate.crt: La clave pública.
• fileca.crt: Fichero de autoridad de la entidad de certificadora (CA)

En el caso de que simplemente necesitemos obtener un certificado .pfx, por tipo de formato de fichero, solamente en base a la clave privada .key y pública .crt podemos omitir el fichero de la CA.

openssl pkcs12 -export -out certificate.pfx -inkey rsaprivate.key -in certificate.crt

Saludos!

Descifrando msgstore.db.crypt de Whatsapp

En sus comienzos, Whatsapp guardaba los ficheros de bases de datos donde se almacenaban las conversaciones que tenemos con el resto de nuestros contactos, en formato SQLite sin cifrar. Es decir, que simplemente con cargarlo en SQLite se podría ver las conversaciones, teléfonos y de más, en texto plano. De modo que en caso de perdida o robo del terminal nos podrían ver las conversaciones de forma muy sencilla.

Hace ya casi año y medio que Whatsapp debido a la inseguridad en estos ficheros y por protección de privacidad para los usuarios; Whatsapp lanzó una actualización en la que corrige este "descuido" encriptando dichos ficheros, dificultando así la simple visualización en plaintext de las conversaciones realizadas.

Este cifrado dificulta la visualización a primera vista, pero no la impide. El cifrado (AES-192-ECB) que utiliza aplicación en los ficheros de backup siempre usa la misma key (346a23652a46392b4d73257c67317e352e3372482177652c) y es lo mismo para todos los dispositivos, es decir, que no se crea nada único por cada dispositivo que tenga instalado Whatsapp.

En el caso de los teléfonos IOS este fichero está en la ruta: [ID de App]/Documents/ChatStorage.sqlite.
En el caso de los teléfonos Android en: ../whatsapp/databases/msgstore.db.crypt.

• msgstore.db.crypt (conversaciones actuales).
• msgstore-YYYY-MM-DD.X.db.crypt (backups de conversaciones por fechas).

Para descifrar el fichero/s en cuestión de las conversaciones que queramos visualizar. Simplemente tendremos que aplicar el siguiente comando con son sus respectivos argumentos.

Para ello descargamos gratuitamente el binario (en mi caso) para Windows de OpenSSL, la cual es una herramienta que permite cifrar y descifrar ficheros mediante líneas de comandos.

Una vez los instalamos se nos instalará (por defecto) en la carpeta la raíz del sistema (C:\).
Copiamos ahora los ficheros de conversaciones que queramos del origen de Whatsapp a una carpeta cercana a la instalación de OpenSSL (da igual donde estén, aconsejo simplemente por comodidad a la hora de mapear el directorio en el comando).

[1] - Abrimos una consola y nos situamos en el directorio donde está el ejecutable OpenSSL.exe (C:\OpenSSL-Win32\bin).

openssl enc -d  -aes-192-ecb -in copias\msgstore-entrada.db.crypt -out copias\msgstore-salida.db.sqlite -K 346a23652a46392b4d73257c67317e352e3372482177652c

Paso a explicar los argumentos, aunque creo que son claros:

• -d: [Decrypt] argumento para empezar a desencriptar.
• -aes-192-ecb: El tipo de encriptación del fichero.
• -in: [Input] Especificar el fichero de entrada a descifrar (en este caso).
• -out: [Output] Especificar el fichero de salida ya descifrado (en este caso).
• -k: [Key] es la clave necesaria utiliza por la aplicación.

En el caso de ejemplo que se muestra arriba en la linea de comando, tendríamos que referenciar el mapeado de nuestros ficheros tanto de entrada como de salida, en mi caso ambos estaban en una carpeta dentro de la ubicación de OpenSSL llamadas "copias".

[2] - Una vez tenemos descifrado el fichero, podremos abrirlo simplemente un gestor de SQLite, por ejemplo SQLite Administrator.

Figura 1: Fichero de conversaciones de Whatsapp (ya descifrado) cargado en SQLite (tabla messages)

En SQLite, podremos filtrar por los campos de la tabla messages e ir a un número de teléfono o a un contexto de conversación en concreto, eligiendo correctamente los campos de filtro adecuados.

Saludos!

Verificar la integridad de ficheros comprobando sus hashes MD5 y SHA

Cómo se genera un hash de verificación para comprobar la integridad de un fichero?

Sin entrar en cálculos matemáticos, básicamente una función hash o función resumen de un fichero se genera en base a un cálculo algorítmico obtenido por sus bytes. Según una palabra escrita o un fichero estos ocupan y están formados por un determinado grupo de bytes que serán los que se usen para calcular la codificación del tipo de hash que sea.

 
Por ejemplo en el caso de ser un hash de checksum MD5 este está formado por 32 dígitos hexadecimales el cual será el valor resultante de la codificación de salida del fichero tratado.

Existen múltiples algoritmos usados para la comprobación de checksum de ficheros, hoy en día los más usados son:

• CRC: Cyclic Redundancy Check.
• MD4/MD5: Message-Digest Algorithm 4/5.
• SHA-1/SHA-2/SHA-3: Secure Hash Algorithm 1/2/3.

Más información sobre como se calcula un hash:

• https://es.wikipedia.org/wiki/MD5
• https://es.wikipedia.org/wiki/Funci%C3%B3n_hash

¿Por qué es importante verificar los checksum MD5 o SHA-1 de los ficheros que descargamos de Internet?

Principalmente por integridad de la información por si el fichero se encuentra dañado y después por seguridad, ya que nos dirá si un archivo descargado de Internet a sido modificado o no. 

Muchas veces cuando descargamos una aplicación esta viene acompañada al lado del enlace de descarga (normalmente) un código de comprobación, lo que sería un checksum. Lo que nos viene diciendo es que el fichero de la aplicación que nos descargamos tiene ese código checksum y si cuando descargamos el fichero y comprobamos el este código checksum y NO concuerda quiere decir que ese fichero que nos descargamos a sido modificado por alguien o de algún otro modo pero lo que está claro es que no del propio desarrollador. Lo cual habría que tener cuidado o directamente borrarlo ya que pudo ser modificado para hacer la función de algún tipo de malware y este tener la capacidad de poder ejecutar código arbitrario en nuestro equipo local.

Existen infinidad de tools para poder comprobar los checksums de los ficheros, como puede ser:

• MD5summer
• FSUM 2.52
• MD5Fourmilab
• MD5Ckecker 2.3.1
• pySum y gtkhash (para Linux)
• OpenSSL

openssl dgst -md5 <Nombre_Fichero>

Pero en esta entrada me centré en FCIV ya que es propietaria de Microsoft y no está de más saber que también cuenta con su propia herramienta para esto.

En HashCheck Shell Extension el cual es muy cómodo y nos permite realizar un comprobación de integridad de los ficheros de forma rápida.

File Checksum Integrity Verifier (FCIV) es una utilidad propietaria de Microsoft y que funciona bajo línea de comandos, calcula y comprueba los valores hash de cifrado de archivos. FCIV puede calcular MD5 o SHA-1 los más típicos valores hash criptográficos.

Estos valores se pueden visualizar en la pantalla o almacenarse en una base de datos de archivo XML para su posterior uso y verificación.

Un ejemplo, creamos un fichero de imagen de formato JPG. Ahora comprobaremos su checksum MD5 del siguiente modo: Nos vamos a donde tenemos el ejecutable que descargamos de la herramienta FCIV.exe. Y la sintaxis del comando para esto sería la siguiente:

fciv -both pruebaMD5.jpg

Donde -both especifica que se muestren los dos hashes tanto MD5 como SHA-1 que se generó para esta imagen cuando la guardé. En vez de -both podríamos especificar los atributos "-md5 -sha1" seguido dle fichero, ambas sintaxis se interpretarían de igual forma.

pruebaMD5.jpg: Sería el nombre del fichero si no está en el mismo path, lo indicaremos.

Figura 1: Generación de hashes MD5 y SHA-1 para una imagen.

En el siguiente ejemplo vemos la integridad del fichero descargable del software Notepad++ v6.8.3 release.

Nuevamente la orden en línea de comandos en la misma que la anterior, con la única diferencia de la especificación del fichero .exe en cuestión.

Figura 2: Comprobación de integridad del hash SHA-1 en Notepad++.

Para más información sobre el uso de FCIV: https://support.microsoft.com/en-us/kb/841290

Otra alternativa más cómoda es: HashCheck Shell Extension, una utilidad que se añade como una pestaña en las propiedades de cualquier fichero la cual nos permite comprobar la integridad checksum de ese fichero en cuestión de forma rápida. CRC-32, MD4, MD5, SHA-1. Ya sea de un único fichero que estemos analizando o de una carpeta que agrupe un conjunto de ficheros.

Figura 3: HashCheck comprobando la integridad de un fichero de imagen .iso.

Otra funcionalidad de HashCheck Shell Extensión es que nos permite crear un checksum MD5, haciendo botón derecho sobre el fichero veremos la opción de "Crear archivo checksum...".

Otra alternativa similar a la anterior pero con más posibilidades de comprobación de hashes es: HashTab en la que podemos seleccionar entre múltiples funciones resumen las cuales queremos comprobar y mostrar, dispone de una larga lista de funciones, entre ellas SHA-2 y SHA-3.

Figura 4: HashTab comprobando función resumen de SHA-3 de un fichero .iso.

Saludos!