Segundo factor de autenticación 2FA en conexiones SSH

Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden elevarse a un contexto privilegiado de sudo y servidores críticos en una red interna corporativa. 

Con este mecanismo de autenticación en dos pasos se estaría reduciendo en gran medida la superficie de ataque de los vectores de entrada a estos sistemas por parte de un posible atacante.

Implementación 2FA en SSH (Google Authenticator)

Instalar el paquete del módulo PAM para 2FA libpam-google-authenticator de Google Authenticator, también se instalará el paquete libqrencode4 que permite generar códigos QR en la propia terminal. 

sudo apt install libpam-google-authenticator -y

Configurar SSH para que haga uso de este módulo PAM. Añadir la siguiente línea en el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so

Habilitar esta configuración el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. Añadimos o modificamos si ya existe la siguiente política a un valor "yes".

ChallengeResponseAuthentication yes

Reiniciamos el servicio sshd para aplicar los cambios realizados en el servicio de SSH.

sudo systemctl restart sshd

Finalmente vinculamos la cuenta de usuario en la que queremos habilitar 2FA. Se nos mostrará un código QR el cual debemos vincular con nuestra App de doble factor, ya sea Google Authenticator u otra que utilicemos para generar códigos de un solo uso basado en tiempo TOTP.

google-authenticator

Se lanzará el asistente de configuración donde asociaremos la clave secreta con nuestra App de segundo factor. También se generarán "5 códigos de emergencia de un solo uso" los cuales los almacenaremos de forma segura en caso de perder el acceso a nuestra App de TOTP instalada en un dispositivo físico.

Figura 1: Creación de código QR - Asistente de vinculación para habilitar 2FA. 

Una vez finalizado el asistente de vinculación. Si nos intentamos autenticar en el servidor nos solicitará la contraseña de usuario y un código de verificación TOTP.

Figura 2: Verificación del uso de 2FA en la autenticación SSH al servidor. 

En este caso se ha vinculado con la App de Google Authenticator donde cada 30 segundos se generará un nuevo código TOTP. 

Figura 3: Código TOTP en la App de Google Authenticator.

Aclarar que aunque tengamos la política de "PasswordAuthentication no" establecida en nuestro fichero de servicio SSH al implementar 2FA será ignorada y será exigido introducir la contraseña de usuario para autenticarse en el servidor.

Paranoid Mode 3FA: Combinar autenticación SSH Public Key + Password + TOTP 

¿Qué pasa si previamente tenemos configurado una autenticación de clave pública en nuestro servicio de conexión SSH hacia el servidor y añadimos 2FA TOTP?

Si ya tenemos configurado un tipo de autenticación asimétrico de clave pública y añadimos un segundo factor bastado en TOTP a priori con esta configuración actual, no nos funcionará.

Si queremos combinar un tipo de factor TOTP junto con nuestra autenticación de clave pública en SSH debemos añadir la siguiente política en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. 

AuthenticationMethods publickey,keyboard-interactive

Reiniciamos el servicio SSH para aplicar los cambios.

sudo systemctl restart sshd

De este modo cuando nos conectamos al servidor SSH no solo estaremos combinando SSH Public Key y TOTP sino que también debemos introducir la contraseña de usuario. Por lo que estaremos usando tres factores de autenticación (3FA) para acceder al servidor vía SSH.

• Autenticación con clave pública/privada.
• Autenticación password de la cuenta de usuario.
• Autenticación con código de verificación TOTP.

Aunque en el fichero de configuración del servicio SSH tengamos establecida la política "PasswordAuthentication no" al combinarla con "keyboard-interactive" nos obligará a introducir la password de la cuenta de usuario con el que nos autenticamos.

Figura 4: Verificación del uso de 3FA en la autenticación SSH al servidor.

Permitir autenticación SSH sin 2FA para usuarios que aún no configuraron Google Authenticator

Si en la máquina servidor hay más usuarios que necesiten autenticarse vía SSH y, por el momento, estos usuarios aún no han configurado 2FA para sus cuentas, o si son usuarios sin privilegios para los que no se considera la implementación de 2FA, pero que igualmente deben poder autenticarse e iniciar sesión en el servidor sin necesidad de utilizar TOTP como segundo factor.

Podemos añadir el valor nullock a la siguiente directiva del módulo de PAM editando el fichero /etc/pam.d/sshd.

auth required pam_google_authenticator.so nullok

Saludos!

Firmar scripts PowerShell [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Firmar scripts PowerShell

• [Parte 1 de 2]: Hardening en la política de ejecución
• [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Continuando con el artículo sobre como firmar scripts PowerShell estableciendo una política de ejecución AllSigned. En este post comentaré como hacer uso de las plantillas de certificados para el propósito de "Firma de código" emitidas por una Entidad de certificación CA implementada en un entorno de dominio haciendo uso del servicio ADCS (Active Directory Certificate Services), desplegando el certificado vía GPO y finalmente realizar una comprobación de integridad del script PowerShell firmado.

CA raíz y CA subordinadas

La CA raíz contiene la clave privada de toda la jerarquía de certificados, si un atacante obtuviera este certificado o emite un certificado para una entidad no autorizada, se compromete la seguridad basada en el certificado de la organización de todos los certificados que se han emitido en esa jerarquía.

Lo ideal y por seguridad sería disponer de una CA raíz que emita certificados para una CA subordinada, de modo que no se exponga directamente el primer nivel de certificado de la CA raíz, las CA subordinadas requieren una jerarquía de PKI establecida.

Entidades de certificación: empresarial e independientes

• Entidad de certificación empresarial: Deben pertenecer al dominio, se suele utilizar cuando es necesario emitir muchos certificados y aprobarlos rápidamente para un entorno de dominio Active Directory.
• Entidad de certificación independiente: Pueden pertenecer a un grupo de trabajo o a un dominio. No requieren de ADDS, se suele utilizar para emitir certificados directamente a los clientes. Dado que no tiene el certificado raíz, ofrece una mayor seguridad. La desventaja es que todos los certificados que se emiten deben ser aprobados.

Descripción del escenario para este lab

Por motivo de falta de recursos y no desplegar una CA subordinada, para estos ejemplos se hará uso únicamente de una CA raíz tipo empresarial ya implementada con el nivel de confianza máximo en la jerarquía de PKI de la organización y un equipo Windows 10 unido al dominio en el que se probará la ejecución de scripts PowerShell firmados donde se le aplicará una GPO con el certificado necesario. 

Entidad de certificación CA (ADCS) y plantilla de Firma de código

Esto sería opcional pero para tener un control de permisos podemos crear un nuevo grupo en AD para este fin y asignarlo desde la consola de "Plantillas de certifiado" (certtmpl.msc) a la plantilla de que tiene como propósito la "Firma de código". De modo que todos los usuarios/grupos que formen parte del grupo añadido tengan permisos para poder solicitar esta plantilla a la entidad de certificación desde las propia consola local de administración de certificados de usuario (certmgr.msc).

Figura 1: Asignación de permisos a la plantilla de certificado "Firma de código".

Desde la consola de "Entidad de certificación" (certsrv.msc). Emitimos la publicación de una nueva plantilla de certificado "Firma de código".

Figura 2: Emitir plantilla de certificado "Firma de código" desde una Entidad de certificación CA.

Es el momento de solicitar un certificado para "Firma de código". Esto lo haremos desde el propio almacén de certificados de Windows (certmgr.msc) y con un usuario que tenga permisos para poder solicitar el certificado de Firma de código a la Entidad de certificación.

Figura 3: Solicitar a la CA un certificado de Firma de código. 

Una vez solicitado, exportamos el certificado en formato .cer.

Figura 4: Exportar el certificado .cer con propósitos de Firma de código.

Despliegue de certificado vía GPO

Para que el resto de equipos del dominio dispongan del certificado .cer en su almacén de certificados, se crea una nueva GPO desde la consola de Administración de directivas de grupo (gpmc.msc). 

A nivel de directiva de equipo, importamos el certificado .cer en el almacén de "Editores de confianza" (Trusted Publishers). Es importante que esté importado en este almacén, de lo contrario la ejecución de scripts PowerShell firmados en cualquier máquina unida al dominio y que tenga establecida una política de ejecución de scripts en modo AllSigned nos arrojará un mensaje de advertencia inicial (como se muestra en la Figura 7).

Figura 5: Desplegar certificado para firma de código vía GPO. 

Firmar scripts PowerShell con un certificado tipo "Firma de código"

Con el mismo usuario que hemos solicitado el certificado, firmamos un script PowerShell. Si visualizamos el fichero de script vemos que se ha incluido una firma complementaria al final del código.

Get-AuthenticodeSignature -FilePath .\MyScript.ps1

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 6: Firmar y ejecutar script PowerShell desde el mismo usuario.

Ejecución del script firmado en otro equipo y usuario del dominio

Probamos a ejecutar el script firmado desde otro usuario y equipo unido al dominio, en este caso un cliente Windows 10 con la política de ejecución de scripts establecida en AllSigned.

Como vemos en la siguiente captura, hay posibilidad de ejecutar el script pero nos muestra un advertencia indicando que el certificado no está importado en el almacén de "Editores de confianza" (Trusted Publishers). Por esta razón lo comentado en el punto anterior de la figura 5. De momento cancelamos la ejecución (ctrl+c).

Figura 7: Ejecutar script PowerShell desde otra máquina y usuario del dominio (sin certificado importado).

Para importar el certificado en el almacén local de la máquina realizamos un forzado de la actualización de políticas (gpupdate /force). Una vez tenemos el certificado ya importado a través de la aplicación de la GPO creada en la Figura 5, podemos observar que al volver ejecutar el script firmado ya no se muestra ninguna advertencia.

Lógicamente si ejecutamos un script no firmado (MyScript_noSigned.ps1) se nos mostrará el mensaje de error común debido a la restricción aplicada AllSigned en la política de ejecución de scripts.

Figura 8: Ejecutar script PowerShell desde otra máquina y usuario del dominio (con certificado importado).

Comprobación de la integridad de firma en scripts PowerShell

¿Qué pasa si se modifica el código del script firmado?

Para realizar la verificación de integridad de la firma del script se modifica el código del script firmado y se vuelve a comprobar el estado del certificado. 

Si ejecutamos el script después de modificarlo se nos muestra un error indicando que "es posible que alguien no autorizado haya modificado el contenido del archivo", comprobamos nuevamente la firma del fichero y veremos un estado HashMismatch indicando claramente que se ha modificado rompiendo su integridad respecto a la firma.

Será necesario volver a firmarlo con el mismo certificado, generando así una nueva firma asignada al script. 

Figura 9: Modificar script PowerShell firmado para comprobar su integridad.

Saludos!

Firmar scripts PowerShell [Parte 1 de 2]: Hardening en la política de ejecución

Firmar scripts PowerShell

• [Parte 1 de 2]: Hardening en la política de ejecución
• [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Por motivos de seguridad Windows PowerShell establece unas políticas de ejecución de scripts. Con el fin de evitar posibles ejecuciones de scripts no deseadas. Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). Por defecto no están definidas y vienen deshabilitadas (Restricted) para todos los scopes.

En un escenario en el que formemos parte de un dominio y deseemos ejecutar scripts PowerShell para la realización de tareas en los endpoints o servidores del parque equipos de la organización. En la mayoría de los casos me encuentro con la "solución" sencilla y poco idónea. Se trata de aplicar un GPO estableciendo la política de ejecución en modo Unrestricted en las máquinas afectadas. Esto deja vía libre a cualquier usuario para que pueda comprometer la máquina sin ningún tipo de restricción.

Aplicar un hardening en la política de ejecución de scripts PowerShell

Lo más correcto en estos casos sería aplicar esta GPO en un modo AllSigned y firmar con un certificado de confianza todos los scripts que vayan ser ejecutados aplicando así un hardening en la política de ejecución de scripts de forma que sean seguros y confiables en entornos corporativos. 

Si disponemos de una PKI de una entidad de certificación ADCS (Active Directory Certificate Services) podremos generar un certificado específico para este fin y propagar este certificado a través de GPO.

Para los siguientes ejemplos usaré un certificado autofirmado.

Modos de la política de ejecución (ExecutionPolicy):

• Restricted: Bloquea todos los scripts en PowerShell y hace que todas las tareas deban ejecutarse de forma interactiva, nada automático. Es la política por defecto.
• Unrestricted: Puede ejecutar cualquier script, sin restricciones. Si se ejecuta un script sin firmar muestra una advertencia al usuario.
• RemoteSigned: Puede ejecutar scripts que han sido creados en la máquina local sin ser firmados. Pero los paquetes descargados deben estar firmados antes de poder instalarlos. Conlleva el riesgo de que no es necesario que los scripts locales vayan firmados digitalmente. Para ejecutar scripts descargados de internet (sin firmar) es necesario usar la opción Unblock-File. Es la política por defecto para Windows Server.
• AllSigned: Solo puede ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts escritos en el equipo local.
• Bypass: Similar a Unrestricted, con la diferencia de que no alerta de riesgos al usuario. Suele utilizarse en integraciones de PowerShell con otras aplicaciones, en las que funciona en una capa inferior, dado que dichas aplicaciones cuentan con un modelo de seguridad propio.
• Undefined: No se establece explícitamente ninguna de las directivas anteriores. Por defecto sería Restricted.
• Default: Establece la política de ejecución predeterminada. Restricted para clientes de Windows y RemoteSigned para Windows Server.

Tipos de ámbitos de la política de ejecución (Scopes):

• MachinePolicy: Establecido por una política de grupo para todos los usuarios de la máquina.
• UserPolicy: Establecido por una política de grupo para el usuario actual de la máquina.
• Process: Afecta solo a la sesión actual de PowerShell.
• CurrentUser: Afecta solo al usuario actual.
• LocalMachine: Alcance predeterminado que afecta a todos los usuarios de la máquina.

Referencia: Get-ExecutionPolicy y Set-ExecutionPolicy

Get-ExecutionPolicy -List
Set-ExecutionPolicy AllSigned -scope LocalMachine -Force

Figura 1: Políticas de ejecución de scripts PowerShell.

Bypass de la política de ejecución de un solo script

En el caso de que las políticas de ejecución estén en un modo Undefined y por lo tanto es como si estuvieran en Restricted. Si queremos ejecutar un script en esa misma sesión o contexto de ejecución podemos usar el modo Bypass. 

PowerShell.exe -ExecutionPolicy Bypass -File \.MyScript.ps1

También sería lo mismo.

powershell -ep Bypass .\MyScript.ps1

Figura 2: Bypass para la ejecución de un solo script.

Firmar un script PowerShell

Referencia: Set-AuthenticodeSignature

Firmar con un certificado del almacén de certificados local

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 3: Firmar con un certificado del almacén local.

Firmar un script usando un certificado de un archivo PFX

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 4: Firmar usando un un certificado .pfx.

Agregar una firma que incluya la autoridad certificación raíz (CA)

$cert = Get-PfxCertificate -FilePath C:\Certs\MySign.pfx
Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer "http://timestamp.globalsign.com/scripts/timstamp.dll"

• IncludeChain: Incluye todas las cadenas de confianza de la autoridad raíz.
• TimeStampServer: Agrega una marca de tiempo a la firma. Esto evita que el script falle cuando caduque el certificado. 

Figura 4: Agregar una firma que incluya la autoridad raíz.

Obtener información de la firma de un script firmado

Referencia: Get-AuthenticodeSignature

Get-AuthenticodeSignature .\MyScript.ps1 | Format-List *

Figura 5: Obtener información de la firma de un script firmado.

Crear un certificado autofirmado para realizar pruebas

Referencia: New-SelfSignedCertificate

New-SelfSignedCertificate -FriendlyName "Zona System ejemplo firma de código" -CertStoreLocation Cert:\CurrentUser\My -Subject "Zona System" -Type CodeSigningCert

Figura 6: Crear certificado autofirmado para pruebas.

Ejemplo de ejecución de script firmado

Estableciendo la política de ejecución de scripts de PowerShell en AllSigned.

Figura 7: Ejemplo de ejecución de script firmado.

Saludos!

Exportar certificados digitales no exportables a PFX (PKCS #12) y restablecer la password de la clave privada con Jailbreak y Mimikatz

En el momento de importar un certificado digital, ya sea para el usuario actual (certmgmt.msc) como para el equipo (certlm.msc), tenemos la opción de establecer dicho certificado como exportable. Esto nos permite exportar el certificado (clave pública) con la clave privada en un mismo fichero en formato pfx.

Más información sobre algunos tipos de formatos de certificados.

Figura 1: Checkbox "Marcar clave como exportable" al importar un certificado digital.

Si no marcamos el check "Marcar esta clave como exportable" cuando se importar un certificado. En el momento de exportarlo del almacén de certificados del usuario actual: Botón derecho > todas las tareas > exportar...

Figura 2: Exportar certificado del administrador de certificados.

Vemos desmarcada la opción "Exportar la clave privada".

Figura 3: Intento de exportación de clave privada, opción deshabilitada, certificado no exportable.

Para poder exportar un certificado ya instalado en el almacén de certificados del usuario actual, el cual no podemos exportar junto con la clave privada. Podemos usar dos opciones.

Usando Jailbreak

Jailbreak nos permitirá abrir una consola de Microsoft (MSC) del alamacen de certificados de Windows y poder realizar la exportación de la clave privada estableciendo una nueva password.

Una vez descargado Jailbreak abrimos una consola cmd con el mismo usuario donde tenemos instalado el certificado y nos situamos en el raíz, ejecutamos el proceso por lotes "jbcert32.bat". Este nos lanzará una ventana del alamacén de certificados de usuario (certmgr.msc).

Figura 4: Ejecución de jailbreak para exportar certificados no exportables.

Si quisiéramos ejecutar el almacén local de certificados a nivel de máquina certlm.msc, no el almacén de usuarios como el caso anterior. Ejecutaríamos lo siguiente.

64 bits

jailbreak64.exe %WINDIR%\system32\mmc.exe %WINDIR%\system32\certlm.msc -64

32 bits

jailbreak32.exe %WINDIR%\system32\mmc.exe %WINDIR%\system32\certlm.msc -32

Ahora vemos como al intentar exportar el certificado nos permite exportar la clave privada.

Figura 5: Opción habilitada para exportar clave privada.

Elegimos un formato .pfx (este almacenará tanto la clave pública como la clave privada), podemos también marca la opción de "Exportar todas las propiedades extendidas".

Figura 6: Opciones disponibles para exportar el certificado en formato .pfx.

Podemos establecer una nueva contraseña para la clave privada, este sería el modo de restablecer la clave privada. Al finalizar el asistentte tendremos exportado un certificado .pfx que contiene ambas claves y volver importarlo en otro usuario o equipo.

Figura 7: Establecer una nueva contraseña para la clave privada.

Usando Mimikatz

Otra opción para poder exportar certificados no exportables de forma sencilla es con la herramienta Mimikatz (ya comentada en el blog).

Una vez descargado Mimikatz abrimos una consola cmd y nos ubicamos en el raíz ejecutando "mimikatz.exe" (dependiendo la arquitectura del sistema operativo que tengamos win32 o x64).

crypto::capi
crypto::certificates /export

Esto buscará los certificados del alamacén del usuario actual y los exportará en codificación .der y formato .pfx. La contraseña por defecto que establece Mimikatz es "mimikatz" (sin comillas). 

Podremos cambiar la password importando el certificado y volviendo a exportarlo con la clave privada estacleciendo una nueva password (como se muestra en la figura 7).

Figura 8: Mimikatz - Exportar certificados no exportables.

Saludos!

Descifrar tráfico SSL/TLS con Wireshark teniendo la clave privada del servidor

Para poder descifrar tráfico SSL/TLS necesitamos la clave privada sin passphrase del certificado digital del servidor. No se trata de ningún "hack mágico" con el que podremos descifrar el tráfico SSL/TLS.

Si necesitamos analizar el tráfico de un servidor al que tenemos un acceso legítimo, este es un método que nos permitirá poder ver en texto plano todo el tráfico cifrado que pasa por el servidor con el fin de detectar posibles anomalías en un red local.

Una vez obtenida la clave privada podremos añadirla en un sniffer de red como Wireshark, de ese modo analizar el tráfico HTTPS como si de un paquete HTTP se tratase.

Al intentar hacer un seguimiento de un cifrado HTTPS este se muestra como un paquete TCP. Haciendo un "Follow > TCP Stream" en Wireshark veremos el tráfico cifrado, como se muestra en la siguiente captura.

Figura 1: Paquete de tráfico TCP cifrado con SSL

Exportamos el certificado con la clave privada del servidor. Una vez tenemos exportado el certificado en formato .pfx con OpenSSL lo convertimos en formato .pem que el formato que Wireshark reconoce. Primero extraemos la clave privada del certificado y después eliminamos la contraseña de la clave privada extraída.

Extraemos la clave privada del certificado y la convertimos a formato .pem.

openssl pkcs12 in certificado.pfx -out claveprivada.pem -nocerts -nodes

Eliminamos la passphrase de la clave privada extraída anteriormente.

openssl rsa -in claveprivada.pem -out claveprivadasinpass.pem

Figura 2: Conversión y extracción de la clave privada del certificado digital .pfx.

Añadir la clave privada .pem sin passphrase extraída del certificado .pfx en Wireshark: "Edit > Preferences... > Protocols > SSL". (Si no vemos el protocolo SSL, en las nuevas versiones de Wireshark será el equivalente a protocolo TLS). Editamos para cargar la clave privada.

• IP Address: IP del servidor.
• Port: 443
• Protocol: HTTP
• Key File: Path del fichero de la clave privada .pem.
• Password: Podremos dejar en blanco este espacio ya que el .pem de la clave privada está sin passphrase.

Figura 3: Añadir la clave privada .pem en Wireshark.

Podremos establecer un fichero de log "SSL debug file". En el que se almacenará en texto plano todos los paquetes cifrados, también podremos analizar desde otra perspectiva el tráfico cifrado desde el fichero log.

Figura 4: Fichero log debug SSL de Wireshark.

Una vez cargada la clave privada .pem reiniciamos Wireshark para actualizar los cambios. Los paquetes TCP cifrados anteriormente serán ahora paquetes HTTP en texto plano y se podrán seguir: "Follow > SSL Stream".

Figura 5: Seguimiento SSL Stream de paquetes HTTP descifrados

En la siguiente captura de pantalla se puede ver el seguimiento del SSL stream en texto plano en paquetes HTTP. En este caso se trata del mismo seguimiento de paquetes TCP referenciados en la "Figura 1".

Figura 6: SSL Stream en texto plano de paquetes HTTP.

Aunque por seguridad, en la generación de cualquier certificado se debería marcar la opción como no exportable para la clave privada, con el fin de minimizar riesgos en la organización. Ya que si alguien no autorizado consiguiese acceso al servidor este podría exportar un certificado PKCS#12 con la clave privada y generar su propia passphrase.

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!