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>
        <staticContent>
            <remove fileExtension="." />
            <mimeMap fileExtension="." mimeType="text/plain" />
        </staticContent>
    </system.webServer>
</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

 

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

CRL: Lista de revocación de certificados publicada 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.

"Recuperar" claves privadas de certificados SSL en IIS

En ocasiones es posible tener alguna que otra dificultad a la hora de crear peticiones (CSR) o renovar si no se realizan los pasos con cuidado en IIS. Debemos tener en cuenta que a la hora de crear una petición de certificado, la clave privada se almacena en el equipo que la realiza y solo en este es posible recuperarla.

Pese a ello en ocasiones se producen errores en el proceso, llegados a este extremo podemos intentar dos opciones:

  1. Desde la linea de comandos podemos intentar reparar el almacen de certificados:
    certutil -repairstore my "ThumbprintDelCertificadoConoSinEspacios"
    Si el comando encuentra las claves privadas asociadas al certificado indicado con el thumprint las asocia, en otros casos es posible que muestre errores del tipo "Insertar tarjeta inteligente" ya que busca en todos los medios y proveedores criptográficos existentes, en tal caso no podrá acabar.

  2. Si hemos solicitado el certificado a una autoridad online, es posible que tenga almacenadas las claves privadas en la solicitud web, en este caso podremos unirlas con el certificado de respuesta para obtener el PFX resultante mediante OpenSSL, puedes probar online pero nunca en producción
    openssl pkcs12 -export -inkey clave.pem -in pki.crt -out certificadoCompleto.pfx

 

CRL: Lista de revocación de certificados

En ocasiones debemos configurar el acceso interno y externo a las listas de revocación de certificados con Entidades de Certificación de confianza, habitualmente autoemitidas. Si hemos comprado un certificado, estas estarán disponibles y no tendremos ente problema seguramente. En otros casos en los que obtenemos errores indicando que no es posible acceder a la lista de revocación de certificados (CRL), debemos comprobar:

  • El dominio en el que se publica esta accesible dentro de la red interna y desde fuera de ella.
  • Podemos navegar y acceder a la lista CRL via web
  • No aparecen errores relacionados en la Autoridad de certificación

Desde cualquier equipo con Windows esta disponible en la linea de comandos "certutil" en la que debemos añadir el parámetro con la URL que queramos verificar:

certutil -URL "http://ejemplo.mainmind.com:8682/CertEnroll/CA%20nombre%20compuesto.crl"

Seleccionamos el certificado CER y recuperamos las direcciones web del CRL, en este caso vemos que pese a poder navegar y acceder no es posible acceder...

Después de comprobar todos los pasos, activamos temporalmente la visualización/listado del servidor que contine los CRL y nos encontramos por fin con el error! El nombre de la CA con la que se publican es demasiado largo y con espacios, por lo que con la seguridad predeterminada de IIS no es posible acceder.

Es posible deshabilitar en la aplicación de IIS esta verificación, pero no es una práctica de seguridad recomendada. Por lo que otra opción sencilla sería acortar el nombre desde la CA en la configuración de extensiones, por ejemplo: "http://ejemplo.mainmind.com/listado.crl"

Volvemos a emitir e instalar el certificado, en el que aparecerá la nueva CRL y volvemos a verificar con certutil, ahora sin problemas de acceso: