Convertir certificado PFX a CRT

Si disponemos de un certificado en entornos Windows y queremos utilizar un certificado en otro tipo de dispositivos, por ejemplo un wilcard (*.midominio.com) podemos desglosar en dos partes utilizando OpenSSL:

openssl pkcs12 -in certificadoCompleto.pfx -nocerts -out llaveSegura.key

De este modo tenemos en un archivo la parte correspondiente a la clave privada de forma encriptada (BEGIN ENCRYPTED PRIVATE KEY). Por otro lado tenemos el certificado firmado:

openssl pkcs12 -in certificadoCompleto.pfx -clcerts -nokeys -out certificado.crt

Si necesitamos las claves sin encriptar (BEGIN RSA PRIVATE KEY), cuidado donde guardar este tipo de ficheros, podemos hacerlo mediante:

openssl rsa -in llaveSegura.key -out llaveNoSegura.key

Con estas 2+1 partes podremos instalar el certificado, por ejemplo en PLESK:

 

 

 

 

Exportación de certificado X.509 codificado en PEM

La digitalización en la administración pública no lleva precisamente un ritmo rápido… y tampoco lo ponen fácil a usuarios finales…

Veremos como para dar de alta un proveedor en FACe, o gestionar su renovación, nos solicitan certificado en formato PEM. Por simplificar, tal como en un fichero de texto Word o una hoja de Excel tenemos diferentes formatos y versiones con los que podemos trabajar, con el certificado nos pasa lo mismo.

En este caso PEM se codifica en Base64 encerrado entre la cabecera «—–BEGIN CERTIFICATE—–» y el fin de contenido con «—–END CERTIFICATE—–«.

Sin entrar en detalles técnicos, por ilustrar con un ejemplo, el texto «Este frase sería codificada» en base 64 contendría: «RXN0ZSBmcmFzZSBzZXLDrWEgY29kaWZpY2FkYQ==»

Este tipo de certificados se basan en el estándar «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» siguiendo la normativa RFC 5280. Gracias a ello podemos identificar el propietario, emisor (Autoridad de Certificación), fecha de caducidad, fecha de misión… basándonos en infraestructura de clave pública (PKI – Public Key Infraestructure)

Por tanto lo que nos están pidiendo es un «certificado X.509 codificado en formato PEM».
En un escenario habitual en un entorno Windows donde tenemos almacenado el certificado accedemos ejecutando el comando «mmc.exe» (existen otras opciones de visualización pero esta funciona en todas las versiones de Windows hasta ahora)

Nos aparecerá una ventana de consola, y bajo la opción del menú «Archivo» la opción: «Agregar o quitar complemento»

A continuación seleccionamos «Certificado» entre los complementos disponibles y pulsamos en agregar: 

Seleccionamos «Mi cuenta de usuario» teniendo en cuenta que los certificados mostrados son los del usuario que ha iniciado sesión en el equipo:

Dentro de «Personal» / «Certificados» nos mostrará todos los disponibles del usuario actual. El icono del listado, muestra una pequeña llave en aquellos certificados de los que disponemos la parte privada:

Haciendo clic con el botón derecho sobre el certificado pulsamos en «Todas las tareas» y «Exportar». Debemos seleccionar el formato de codificación X.509, no debemos exportar la clave privada en este caso:

Indicamos una ruta de nuestro ordenador para guardar el certificado, pulsando con el botón derecho sobre el certificado «Abrir con…» y seleccionamos el editor de texto Bloc de notas nos mostrará:

Con este contenido ya podemos copiar y pegar en la página de FACe de proveedores.

 

Creación de PFX a partir de clave pública y privada

En entornos Windows la encapsulación de certificado en ocasiones suele ser algo complicada en algunos contextos. En este en concreto, plantemos unir un certificado CER/CRT (es lo mismo) recibido con la clave pública con otro archivo con las claves privadas en un único archivo PFX

En ocasiones se utilizan diferentes extensiones para los certificados, lo primero es identificar cada fichero, podemos abrirlos con bloc de notas y reconocer las cabeceras:

Certificado público (micertificado.cer):

-----BEGIN CERTIFICATE-----
MIIFszCCBJugAwIBAgIQCn/RxfJgDNYmoD7jyCSfGjANBgkqhkiG9w0BAQsFADBe
...BLOQUE DE TEXTO...
KPYJupIYuFSDoL/C77KF9zntk1gft5o=
-----END CERTIFICATE-----

Clave privada asociada (clave.key):

-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAzHvXgg7VbCHXDSihNDx3q5GrNhDhnw2IAU/z259t6wi+gTjv
..BLOQUE DE TEXTO...
PEMYrxRR46jUuQqNpqYqYk5Trg6dtjKf6/82caESpr1vYG0uErwXTow=
-----END RSA PRIVATE KEY-----

Necesitaremos varias herramientas:

  1. pvk2pfx en SDK Windows, en este caso de Windows 10 pero esta disponible para otras versiones
  2. Utilidad PVK de Stephen N Henson [mirror 1]

A partir de nuestro archivo de claves privadas (clave.key) generaremos un archivo PVK ejecutando (C:\Program Files (x86)\Windows Kits\10\bin\x64\):

PVK.exe -in clave.key -topvk -out misclaves.pvk -strong

Nos pedirá que introduzcamos una contraseña. Con los dos ficheros misclaves.pvk + micertificado.cer ejecturemos contra la herramienta del SDK asegurando las rutas de acceso:

pvk2pfx.exe /pvk misclaves.pvk /spc micertificado.cer /pfx MiCertificadoCompleto.pfx

 

Ya tendremos unificado en un fichero toda la información.

 

Manual Pvk2Pfx

Plesk + Dotnetnuke + Let’s Encrypt = CMS + SSL

Algunos gestores de contenidos, como en este caso Dotnetnuke, tienen reglas propias de redirección que pueden interferir a la hora de instalar certificados gratuitos de Let’s Encrypt desde panel de control Plesk. Existen varias opciones, pero una de la más sencilla para este problema concreto es cambiar el tratamiento de las redirecciones del CMS:

    <friendlyUrl defaultProvider="DNNFriendlyUrl">
      <providers>
        <clear />
        <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="humanfriendly" />
      </providers>
    </friendlyUrl>

Sustituyendo «advanced» por «humandfriendly«, lo que dejará el sitio añadiendo la extensión .aspx de nuevo generando el directorio «\.well-known\acme-challenge\» que incluye la descarga del ficheros sin extensión como texto plano en su propio web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <validation validateIntegratedModeConfiguration="false" />
      <staticContent>
         <clear />
         <mimeMap fileExtension="." mimeType="text/plain" />
      </staticContent>
      <handlers>
      <clear />
      <add name="StaticFile" path="*" verb="GET" modules="StaticFileModule" resourceType="Either" />
      </handlers>
   </system.webServer>
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

Ahora podemos volver a dejar la redirección como «advanced». Si, la otra opción es añadir el fichero anterior en el directorio indicado, Let’s Encrypt creará una petición de comprobación del tipo:

http://midominio.es/.well-known/acme-challenge/8-TsVgjMp5v3BRkUVk4zwdiCVDlSkDaf…b

A partir de versiones más modernas, podemos añadir una configuración específica de URLs amigables desde la configuración Host en Sistemas > Configuración del sisstema > Configuración Avanzada > Configuración de URLs amigables

Añadimos las reglas de redirección de IIS para no afectar al directorio:

<configuration>
<system.webServer>
    <rewrite>
      <rules>
        <clear />
        <rule name="LetsEncrypt" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                <add input="{REQUEST_URI}" pattern=".well-known/" />
            </conditions>
            <action type="Rewrite" url="{REQUEST_URI}" />
        </rule>
    </rewrite>
</system.webServer>    
</configuration>

 

Si pese a ello sigue sin poder acceder a la ruta, puedes deshabilitar temporalmente desde Plesk, el soporte para .NET y renovar manualmente.

Lista de revocación en servidor externo

Dependiendo de la complejidad de la infraestructura PKI de la organización, podemos desde la entidad de certificación publicar automáticamente en servidores externos, en este caso IIS, los datos.

Para ello compartimos una carpeta en el equipo con el servidor web asignando permisos de acceso y NTFS sobre el nombre de la máquina.

Añadimos en la publicación de la CA una nueva ruta hacia nuestro servidor local, el nombre del fichero y la ruta final debe ser el mismo que el expuesto externamente para el CRL:

file://\\servidorLocal\CA\<nombre de CA><sufijo de nombre de lista CRL><diferencias entre listas CRL permitidas>.crl

En nuestra entidad de certificación tendremos de la siguiente manera la publicación interna y el acceso de consulta externo, por ejemplo:

 

Para asegurarnos que el servidor es capaz de alcanzar las rutas de publicación, con el botón derecho sobre «Certificados revocados» pulsamos «Todas las tareas» -> «Publicar»

 

Comprobar las listas de revocación desde equipo externo

Existe la alternativa de utilizar OCSP para la comprobación de las listas, lo veremos en otro momento.