Udostępnij za pośrednictwem


Migración de Algoritmo hash SHA1 a SHA2 de una Entidad Certificadora. Lo que necesita saber!

 

Hola! soy Eric Avila del grupo de Directory Services de LATAM.  Desde hace un tiempo he visto en nuestros clientes varias dudas sobre el proceso de migración de SHA1 a SHA2 en entidades certificadoras.
El proceso comenzó a despertar la necesidad de los clientes, a partir del anuncio de Microsoft sobre la falta de seguridad que presentaba el algoritmo SHA1 y el cual sería obsoleto para Enero, 2016.

https://support.microsoft.com/en-us/help/3123479/microsoft-security-advisory-deprecation-of-sha-1-hashing-algorithm-for

A partir de este anuncio, muchos de nuestros clientes han abierto casos para entender tanto el proceso de migración, como el impacto en su actual infraestructura de PKI. El objetivo de este blog es aclarar las dudas más frecuentes y mostrar el proceso que deben seguir para lograr la migración de su infraestructura de PKI ya sea de uno, dos o tres niveles.

 

Empecemos respondiendo una serie de preguntas que comúnmente nos han hecho llegar al grupo de escalación:

¿En una infraestructura PKI de dos o tres niveles, es necesario migrar la Root CA?

La respuesta inicial es no, pero dependerá del requerimiento o la necesidad de migra al algoritmo a SHA2. Normalmente lo que requieren es que los certificados emitidos a los usuarios, computadora o servicios tengan el algoritmo hash en SHA2, por lo que bajo este escenario la única entidad que es necesario migrar es la denominada “Issuing”, es decir la entidad que emite los certificados.

La Root Certificate no es necesaria migrarla bajo este escenario, ya que no es la responsable de emitir los certificados a los usuarios, computadoras (finales) y servicios.  Pongamos el escenario: Usted ha decido migrar solo la entidad Issuing, lo cual conlleva solo el cambio de una llave de registro (proceso que más adelante se explicara), después de realizar el cambio un error común es revisar el certificado raíz de la entidad issuing y se percatan que dicho certificado aún
cuenta con una Hash algoritmo SHA1 (imagen 1), lo cual es totalmente normal y esperado, ya que dicho certificado fue emitido en su momento por la Root CA, la cual aún se encuentra configurada para emitir certificados SHA1.  La mejor
forma de validad si la issuing fue migrada a SHA2, es emitiendo desde la Issuing un certificado de usuario, computadora o servicio y al validar el algoritmo hash este debe ser SHA2.

 

¿Qué sucederá con los certificados emitidos antes de la migración, seguirán siendo validados?

Totalmente continuaran siendo validados, es importante aclarar que la entidad certificadora solo se le ha instruido a
través del cambio del algoritmo hash, que todos certificado emitido a partir del momento de la migración sean SHA2, pero el certificado raíz y su correspondiente llave privada seguirá siento la misma y con ello la validación
de los certificados emitidos ya sean SHA1 o SHA2, será realizada sin mayor problema.

 

¿Cuándo debo migrar la Root CA a SHA2?

La Root CA deberá ser migrada en el momento que por alguna razón especifica requiera que las entidades certificadoras
Intermedias (para el caso de 3 Niveles) o Issuing (Para el caso de 2 niveles), contengan como Root Certificate un certificado con Algoritmo SHA2. Lo cual, vuelo a reiterar no significa que teniendo un Certificado Raíz SHA2, la CA
emita certificados SHA2, eso lo hará hasta realizar el cambio en la llave de registro del proceso que explicara más adelante. “Proceso de Migración de una entidad certificadora de un algoritmo Hash SHA1 a SHA2.”

 

¿Cómo saber si la CA será migrada de forma exitosa a un algoritmo Hash SHA2?

Gran cantidad de los casos advisory que hemos recibido sobre el proceso de migración, han vuelto a ser abiertos dado
que el proceso no fue exitoso. Esto al emitir un certificado de prueba se percatan que el certificado aún tiene un algoritmo SHA1(Figura 1). La causa de esto es debido al “Proveedor de Criptografía”, lo cuales son capaces de manejar
diferentes algoritmos Hash de diferentes tamaños.  Si el certificado raíz hace uso de “Cryptographic Service Provider (CSP)”, el proceso de migración a SHA2 no será exitoso, por lo tanto es necesario migrar “Key Storage Provider (KSP)”.
Aquí dejo unas referencias quien deseé profundizar en el tema sobre CSP o KSP:

“Understanding Cryptographic Providers”

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931380(v=vs.85).aspx

“Cryptographic Service Provider (CSP)”

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931357(v=vs.85).aspx

“Key Storage Provider (KSP)”

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931355(v=vs.85).aspx

 

Para identificar el proveedor del certificado raíz de la entidad que deseo migrar es necesario ejecutar el siguiente comando:

– Certutil –store my <Your CA common name>

Como ejemplo usando un nombre de CA “Dispositivos”

    Certutil –store my “Dispositivos”

Número
de serie: 610e224900020000000e

Emisor:
CN=ROOTCA, SERIALNUMBER=123456789, O=contoso, C=com

 NotBefore: 28/01/2016 12:36 p.m.

 NotAfter:
28/01/2021 12:46 p.m.

Sujeto:
CN=Dispositivos, DC=contoso, DC=com

Versión
de CA: V1.0

Nombre
de plantilla de certificado (Tipo de certificado): SubCA

Certificado
no raíz

Plantilla:
SubCA

Hash
de cert(sha1): 07 01 32 d7 ac 34 7e c8 40 30 73 b2 63 5c 3d df ae 3f 11 29

Contenedor de claves = Dispositivos

Nombre de contenedor exclusivo:
b7e4a69d7b97e8da1c9436f2dfd73950_937f6140-3894-44f2-b93f-d49fbae60e51

  Proveedor = Microsoft Strong Cryptographic Provider                     

 Se ha pasado la prueba de firma

CertUtil:
-store comando completado correctamente.

 

Debemos de poner atención en el renglón:

  Proveedor = Microsoft Strong Cryptographic Provider       <<<<<<  AquÍ se refleja el uso de un proveedor CSP, y se tiene que convertir a KSP, para lograr una migración exitosa a SHA2.

 

Aquí hare referencia a un Blog ya existente

https://blogs.technet.microsoft.com/askds/2015/10/26/sha1-key-migration-to-sha256-for-a-two-tier-pki-hierarchy/

https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/58/02/metablogapi/clip_image005_2B2A4248.jpg

Si mi certificado tiene como “Provider” cualquiera de los resaltados en amarillo, es necesario migrar a “Key Storage
Provider (KSP)” (Imagen 2)

¿Cuál es proceso de Migración del “Proveedor de Criptografía”?

El proceso se explica detalladamente en el KB de Technet:

https://technet.microsoft.com/en-us/library/dn771627(v=ws.11).aspx

Cada uno de los pasos deberá seguirse con precaución

En términos generales los pasos a seguir son:

  1.  Usaremos como ejemplo el nombre de la entidad certificadora “Dispositivos”.

Obtener el “Provider” del certificado raíz de la entidad certificadora, “Dispositivos” que se desea migrar, esto con el comando:

Certutil –store my
" Dispositivos my "Personal"

================
Certificado 0 ================

Número
de serie: 612e0acd00020000000e

Emisor:
CN=ROOT Contoso, SERIALNUMBER=123456789, O=Contoso, C=com

 NotBefore:
11/01/2012 01:05 p.m.

 NotAfter: 11/01/2017 01:15 p.m.

Sujeto:
CN= Dispositivos, DC=contoso, DC=com

Versión
de CA: V0.0

Nombre
de plantilla de certificado (Tipo de certificado): SubCA

Certificado
no raíz

Plantilla:
SubCA

Hash
de cert(sha1): 8b c0 d7 24 67 7b 64 c5 4f ee fe f7 64 d7 10 45 75 bf 31 db

  Contenedor
de claves = Dispositivos

Nombre de contenedor exclusivo:
b7e4a69d7b97e8da1c9436f2dfd73950_937f6140-3894-44f2-b93f-d49fbae60e51

Proveedor = Microsoft Strong Cryptographic Provider

Se
ha pasado la prueba de firma

 

================
Certificado 2 ================

Número
de serie: 610e224900020000000e

Emisor:
CN=ROOTCA, SERIALNUMBER=123456789, O=contoso, C=com

 NotBefore: 28/01/2016 12:36 p.m.

 NotAfter:
28/01/2021 12:46 p.m.

Sujeto:
CN=Dispositivos, DC=contoso, DC=com

Versión
de CA: V1.0

Nombre
de plantilla de certificado (Tipo de certificado): SubCA

Certificado
no raíz

Plantilla:
SubCA

Hash
de cert(sha1): 07 01 32 d7 ac 34 7e c8 40 30 73 b2 63 5c 3d df ae 3f 11 29

Contenedor de claves = Dispositivos

Nombre de contenedor exclusivo:
b7e4a69d7b97e8da1c9436f2dfd73950_937f6140-3894-44f2-b93f-d49fbae60e51

  Proveedor = Microsoft Strong Cryptographic Provider <<<<<<<<<<<<<<<<< Aqui se refleja el uso de CSP, y se tiene que migrar a KSP

Se ha pasado la prueba de firma

CertUtil:
-store comando completado correctamente.

  

2. Una vez confirmado el uso de CSP y para continuar con el proceso de migración, es imperativo realizar un backup de la entidad certificadora.  Para ello se pueden apoyar el siguiente KB:https://technet.microsoft.com/en-us/library/ee126140(v=ws.10).aspx#BKMK_BackUpReg

 

3.     3. Detener el servicio de la Entidad Certificadora

4.      4. Abrir una consola de PowerShell y borrar el certificado raíz a través de los siguientes comandos:

Cd
cert:\localmachine\my
 

Del –deletekey
<"Certificate ID">
 

Esta operación se
deberá repetir para todos los certificados en el contenedor de MY.

5.       5. A través de línea de comandos, migrar el certificado raíz “Dispositivos” a KSP, haciendo uso del certificado *.p12 que fue resultado del
backup del paso No 2 y proporcionado la contraseña que fue asignada:

certutil -csp "Microsoft Software Key Storage Provider" -importpfx "c:\temp\Dispositivos.p12"

Escriba la contraseña PFX: El certificado "Dispositivos" se ha agregado al almacén.

El certificado "Dispositivos" se ha agregado al almacén.

CertUtil: -importPFX comando completado correctamente.

 

6.      6. El siguiente paso, es exportar el resultado del archivo migrado pfx al almacen de certificados My “Personal”

certutil -exportpfx my "Dispositivos" Dispositivos.pfx my "Personal"

 

7.      7. Restaurar el archivo *.pfx

     certutil -restorekey  Dispositivos.pfx

 8.       Crear un archivo llamado Csp.reg.  Asegurarse de sustituir por el nombre de la CA.

 Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your
CA Common Name>\CSP]

"ProviderType"=dword:00000000

"Provider"="Microsoft
Software Key Storage Provider"

"CNGPublicKeyAlgorithm"="RSA"

"CNGHashAlgorithm"="SHA1"

 

9.       9. Crear un archivo llamado: EncryptionCsp.reg Asegurase sustituir por el nombre de la CA.

Windows Registry Editor Version 5.00

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Your
CA Common Name>\EncryptionCSP] 

"ProviderType"=dword:00000000

"Provider"="Microsoft
Software Key Storage Provider" 

"CNGPublicKeyAlgorithm"="RSA"

"CNGEncryptionAlgorithm"="3DES"

"MachineKeyset"=dword:00000001

"SymmetricKeySize"=dword:000000a8

 

    10.  Antes de ejecutar los 2 archivos Csp.reg  y EncryptionCsp.reg, asegúrese de que su CA se encuentra usando SHA1 con el siguiente comando:

 

Certutil –v –getreg ca\csp\HashAlgorithm

Poner  atención en la salida:

 

HashAlgorithm REG_DWORD = 8004 (32772)

CALG_SHA1

Algorithm Class: 0x8000(4) ALG_CLASS_HASH

Algorithm Type: 0x0(0) ALG_TYPE_ANY

Algorithm Sub-id: 0x4(4) ALG_SID_SHA1

              De igual forma asegurarse de que se hace uso de 3DES con el siguiente comando:

              certutil -v -getreg ca\encryptioncsp\EncryptionAlgorithm

              Poner atención a la salida:

EncryptionAlgorithm REG_DWORD = 6603
(26115)

CALG_3DES

Algorithm Class:
0x6000(3) ALG_CLASS_DATA_ENCRYPT

Algorithm Type:
0x600(3) ALG_TYPE_BLOCK

Algorithm Sub-id:
0x3(3) ALG_SID_3DES

11. Una vez migrado el Provider de CSP a KSP el siguiete paso es migrar la entidad certificadora a SHA2.

 

Migración entidad certificadora de SHA1 a SHA2.

El proceso de migración de una entidad certificadora de SHA1 a SHA2 consiste en modificar una llave de registro, ya sea de forma manual o a través de línea de comandos.

El comando para realizar la migración es:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Una vez realizado el cambio, se necesita iniciar el servicio de la entidad certificadora:

Net start certsvc.

Estos son los pasos que comprendería hacer migración de una entidad certificadora de un algoritmo hash SHA1 a SHA2.

¿Qué pasa si mi Certificate Authority es Windows Server 2008 R2?

Windows Server 2008 o Windows Server 2008 R2 no soporta los comandos para la conversión a KSP dentro de la utilería certutil. Si nuestra CA que deseamos migrar a SHA2 es Windows Server 2008 R2 o anterior, el proceso tendrá una variante y el cual consiste en exportar el certificado raíz de la entidad certificadora a PFX y mover el archivo a un servidor Windows Server 2012 R2 y realizar el proceso descrito en la sección: ¿Cuál es proceso de Migración del “Proveedor de Criptografía”?”.

Una vez realizada la migración y el certificado se tenga listo, es necesario exportar el certificado migrado a un formato PFX y mandarlo nuevamente al servidor Windows Server 2008 R2 e importarlo dentro del contenedor Personal de Computer.

Conclusión:

Migrar el Algoritmo Hash de una entidad certificadora a SHA2 no tiene un impacto en la operación y validación de los certificados emitidos previamente.  Por otra parte, el proceso de migración solo comprende el cambio de un valor en la llave de registro. Sin embargo, la entidad certificadora debe cumplir los requerimientos de proveedor de criptografía siendo KSP el único soportado para lograr migrar a SHA2. En caso de no cumplir con el proveedor de criptografía a KSP, los pasos a seguir para la conversión son sencillos, pero deben de realizarse con cuidado para evitar confusión en el procedimiento. Esperando que este blog les sirva como una guía que los ayude a resolver las dudas respecto al tema de migración a SHA2 y proporcionarles las referencias para realizar la migración exitosamente.