🔐 D365FO elimina SHA-1 de las licencias ISV

Microsoft ha concretado un cambio pequeño en sintaxis, pero importante para cualquier ISV que proteja una extensión de Finance and Operations: el soporte para firmas SHA-1 de licencias ISV se eliminó en Platform update 73, build 7.0.8129.0. SHA-1 ya no está soportado para generar licencias y SignatureVersion debe usar el valor 2, que corresponde a SHA-256.

La documentación oficial incorporó un aviso de deprecación el 15 de septiembre de 2026 y lo corrigió el 16 de septiembre para hablar expresamente de eliminación. Esto convierte la generación en un corte real, no en una recomendación futura. Microsoft no aclara, sin embargo, si una licencia SHA-1 ya importada deja de validarse automáticamente al actualizar. Hay que retirar SignatureVersion:1, los scripts heredados de PU34 y anteriores y cualquier proceso de renovación que todavía produzca una firma SHA-1, además de probar las licencias instaladas antes de llevar PU73 a producción.

Flujo de firma y validación de una licencia ISV con SHA-256.

Diagrama original. La clave privada firma fuera de D365FO; el modelo distribuye únicamente el certificado público que permite validar la licencia.

Qué ha cambiado exactamente

axutil genlicense admite dos versiones de firma en el flujo heredado:

SignatureVersionHashEstado desde PU73
1SHA-1Soporte eliminado en PU73
2SHA-256Obligatorio para generar licencias

El alcance publicado es Platform update 73, build 7.0.8129.0. Microsoft utiliza una versión de build de plataforma para fijar el umbral; conviene comprobar la versión real del entorno y no inferirla solo a partir del número de aplicación.

Hay además una diferencia que evita muchos errores de migración:

  • en 10.0.43 y posteriores, las licencias se emiten para el tenant y la tabla de parámetros actual no expone SignatureVersion; los ejemplos actuales utilizan el flujo compatible con SHA-256;
  • en versiones anteriores a 10.0.43, SignatureVersion sí está documentado y su valor correcto es 2;
  • las licencias generadas en 10.0.43 o posterior no son compatibles con versiones anteriores.

No añadas a ciegas /SignatureVersion:2 a un generador moderno. En versiones actuales elimina cualquier dependencia de SHA-1 y valida el comando soportado por el axutil del build objetivo. El modificador explícito corresponde a la tabla documentada para versiones anteriores a 10.0.43.

Por qué importa aunque muchas instalaciones ya usaran SHA-256

Muchas instalaciones ya generan SHA-256, pero el documento revisado ha dejado de describir SignatureVersion como opcional y ha eliminado la afirmación de que 2 sea el valor predeterminado. No conviene depender de una omisión implícita en el flujo heredado. El riesgo está en las automatizaciones antiguas: plantillas que conservan /SignatureVersion:1, utilidades compiladas alrededor del flujo de PU34, documentación interna copiada hace años o renovaciones que no se ejecutan hasta que caduca un certificado.

Una licencia ISV no es un simple fichero de configuración. Controla configuration keys que pueden ocultar formularios, deshabilitar procesos y bloquear la solución. Si una licencia importada pasa a ser inválida, Microsoft indica que la solución continúa funcionando hasta el siguiente reinicio del servidor. Después, se deshabilita y AOS registra el error en el log de eventos. El reinicio es, por tanto, parte obligatoria de una prueba de migración.

Arquitectura de la validación

El flujo separa material privado y público:

  1. El ISV dispone de un certificado Authenticode X.509 con clave privada RSA.
  2. La clave privada, almacenada en PFX/PKCS #12 o en un HSM, firma el fichero de licencia.
  3. El certificado público .cer se incorpora al modelo como recurso de AOT y se asocia al license code.
  4. Uno o más configuration keys dependen de ese license code y gobiernan los elementos de la solución.
  5. Al importar la licencia, el entorno valida la firma con la clave pública distribuida en el modelo.
  6. En el arranque de AOS se aplica el estado válido o inválido y quedan trazas en el log de eventos.

SHA-256 cambia el hash de la firma, no este modelo de confianza. Tampoco sustituye el control del certificado: quien acceda a la clave privada puede emitir licencias que el modelo aceptará.

Plan de migración

1. Inventariar generadores y artefactos

Busca en repositorios, pipelines, runbooks y máquinas de firma:

SignatureVersion:1
/SignatureVersion 1
makecert
pvk2pfx
UseLegacyCryptoServiceProvider

UseLegacyCryptoServiceProvider no selecciona SHA-1, pero identifica una ruta de compatibilidad. Microsoft indica que su valor predeterminado es 0 y que solo debe utilizarse como fallback cuando falle el proveedor moderno.

Registra por producto y cliente:

  • versión de aplicación y build de plataforma objetivo;
  • license code y configuration keys afectados;
  • tenant ID, caducidad y contador de la licencia;
  • certificado, tamaño de clave, proveedor y fecha de expiración;
  • versión de firma configurada o asumida;
  • ubicación del generador y responsable de la clave privada.

No es necesario extraer ni distribuir la clave privada para completar el inventario.

2. Preparar el certificado

Microsoft admite certificados Authenticode RSA de 1024 y 2048 bits; desde 10.0.20 también admite 3072 y 4096 bits y recomienda los tamaños mayores. Para certificados basados en HSM, la clave privada debe ser RSA.

El PFX contiene la clave privada y no debe salir de la organización del ISV. El modelo solo debe incluir el .cer público. Cuando sea posible, instala el certificado en Current User/My de una máquina de firma controlada y selecciona simultáneamente subjectName y thumbprint; el thumbprint evita que axutil escoja otro certificado con el mismo sujeto.

Para desarrollo, PU35 y posteriores documentan este patrón SHA-256:

$cert = New-SelfSignedCertificate `
    -CertStoreLocation Cert:\LocalMachine\My `
    -DnsName "IsvCert" `
    -Type CodeSigningCert `
    -KeyExportPolicy Exportable `
    -HashAlgorithm sha256 `
    -KeyLength 2048 `
    -KeySpec Signature `
    -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"

Los certificados autofirmados son solo para desarrollo; producción no los admite.

3. Actualizar el generador

En 10.0.43 o posterior, la licencia se emite con el tenant ID en serialnumber. El ejemplo oficial con certificado en almacén es:

& "C:\AOSService\PackagesLocalDirectory\Bin\axutil.exe" genlicense `
    /file:C:\Licenses\Contoso.txt `
    /licensecode:ISVLicenseCode `
    /serialnumber:<tenant-id> `
    /subjectName:"ISVCert" `
    /thumbprint:<certificate-thumbprint> `
    /expirationdate:11/30/2027

No incluyas secretos en la línea de comandos ni en logs. El patrón con subjectName y thumbprint permite usar el almacén de certificados o un HSM compatible sin transportar el PFX.

En una versión anterior a 10.0.43, conserva los parámetros customer y serialnumber requeridos por ese contrato y fija explícitamente:

/SignatureVersion:2

No mezcles ambos contratos. Desde 10.0.43 la licencia es de tenant y puede usarse en varios entornos que compartan el mismo tenant ID; una licencia generada con ese modelo no funciona en versiones anteriores.

4. Probar importación y reinicio en sandbox

Para un entorno no productivo administrado con el flujo clásico, Microsoft documenta Microsoft.Dynamics.AX.Deployment.Setup.exe --setupmode importlicensefile y una sincronización de base de datos posterior. En producción, la licencia debe viajar en un paquete desplegable mediante Lifecycle Services; la plantilla se encuentra en:

<PackagesFolder>\bin\CustomDeployablePackage\ImportISVLicense.zip

Un plan de prueba mínimo debe comprobar:

  1. que la importación termina sin error;
  2. que el license code y las configuration keys aparecen habilitados;
  3. que formularios, menús, batch e integraciones protegidos funcionan;
  4. que el comportamiento se mantiene después de reiniciar AOS;
  5. que el log de eventos no contiene errores de validación;
  6. que caducidad, tenant ID y contador tienen los valores esperados;
  7. que la licencia antigua no es necesaria para completar el arranque.

La prueba tras reinicio es la que detecta el fallo operativo que más importa. Probar únicamente la importación puede dejar una licencia inválida aparentemente funcional hasta la siguiente ventana de mantenimiento.

5. Desplegar y preparar reversión

Genera de nuevo las licencias activas con SHA-256 antes de que el cliente llegue a PU73. En producción, crea una copia de ImportISVLicense.zip, coloca los ficheros en AosService\Scripts\License y despliega por LCS. Si instalas varias licencias, recuerda que se procesan en orden alfabético y nómbralas para respetar dependencias.

Conserva una matriz de versión, tenant, certificado, hash, caducidad y resultado de prueba. La reversión no debe consistir en volver a SHA-1: debe restaurar el paquete y certificado anteriores únicamente en una versión donde sigan soportados, mientras se corrige el generador SHA-256.

Seguridad del proceso de firma

  • Ejecuta la firma en un agente dedicado y con acceso restringido.
  • Prefiere HSM con clave RSA; si utilizas PFX, almacénalo en un gestor de secretos y limita su exportación.
  • No escribas la contraseña del PFX, el fichero ni su contenido en el repositorio o en artefactos del pipeline.
  • Distribuye solo el .cer público dentro del modelo.
  • Usa thumbprint cuando existan certificados con el mismo sujeto.
  • Protege license codes y configuration keys en paquetes binarios, como recomienda Microsoft.
  • Trata una rotación de certificado como un cambio coordinado de modelo y licencias; pruébalo antes de retirar la clave anterior.

SHA-256 mejora la función hash, pero no corrige una custodia débil de la clave. El control principal sigue siendo impedir que terceros firmen una licencia aceptada por el certificado público incluido en la solución.

Límites y cuestiones abiertas

  • La eliminación ya está efectiva en PU73, build 7.0.8129.0, para la generación de licencias; no existe un periodo de deprecación pendiente.
  • Microsoft dice que eliminó el soporte para firmas SHA-1, pero concreta el comportamiento como «ya no soportado para la generación». No afirma expresamente qué ocurre con una licencia SHA-1 importada antes de actualizar; debe validarse cada caso en sandbox.
  • SignatureVersion aparece en la tabla de versiones anteriores a 10.0.43, no en el contrato actual. No supongas que el modificador explícito está soportado en todos los builds.
  • AllowCrossDomainInstallation y el licenciamiento por tenant resuelven escenarios distintos; no cambies ese indicador como parte de la migración criptográfica sin revisar el alcance comercial.
  • Esta eliminación afecta al mecanismo técnico de licencias ISV, no al licenciamiento de suscripción de Dynamics 365.

Recomendación práctica

Trata PU73 como un corte ya efectivo: no intentes emitir más licencias SHA-1. Audita ahora los generadores, emite una licencia SHA-256 para cada variante soportada y ejecuta una prueba con reinicio antes de actualizar producción. El cambio es barato cuando se hace junto a una renovación; es caro cuando una extensión queda deshabilitada después del mantenimiento.

Referencias