Firma digital en e-CF DGII: certificados INDOTEL, XAdES-BES y proceso de firma

Por Ing. Carlos Méndez | 18 de septiembre de 2026

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.

Sumario: El e-CF DGII requiere firma digital XAdES-BES con certificado X.509 emitido por entidad certificadora aprobada por el INDOTEL. El algoritmo obligatorio es SHA-256 con RSA. La firma se aplica sobre el XML completo y se valida antes de la autorización. El error 601 indica firma inválida.

La firma digital es el requisito técnico más complejo de la integración e-CF para un ISV que nunca ha trabajado con XML firmado. No es solo adjuntar un certificado: implica comprender el estándar XAdES-BES, manejar correctamente el formato PKCS#12, aplicar la firma en el nodo XML correcto, y verificar que ningún proceso posterior modifique el documento firmado. Un error en cualquiera de estos pasos produce el código 601 de la DGII, que por su nombre genérico 'Firma Inválida' no informa sobre la causa exacta.

Este artículo documenta los requisitos del certificado digital para e-CF en RD, el estándar de firma XAdES-BES, el proceso de firma paso a paso, y los errores más frecuentes con sus causas reales.

Requisitos del certificado digital para e-CF DGII

Tipo de certificado requerido

El certificado debe ser de tipo X.509 versión 3, emitido bajo el estándar PKIX. Debe ser un certificado de firma de persona jurídica (el RNC del contribuyente debe estar incluido en los campos del certificado). Los certificados personales de persona física son rechazados por la DGII en los tipos de e-CF empresariales. El Subject Alternative Name (SAN) o el campo Common Name del certificado debe incluir el RNC en el formato que acepta el parser de la DGII.

Proveedores de certificados aprobados por el INDOTEL

El INDOTEL (Instituto Dominicano de las Telecomunicaciones) es el organismo que acredita a las Autoridades Certificadoras en República Dominicana. Solo los certificados emitidos por entidades acreditadas ante el INDOTEL son aceptados por la DGII para firma de e-CF. E-CERTIFICA es la principal entidad certificadora reconocida. La lista de entidades vigentes está disponible en el portal del INDOTEL. El costo del certificado varía entre RD$6,000 y RD$12,000 anuales. La vigencia típica es de 1 a 2 años: el ISV debe implementar alertas de vencimiento para evitar interrupciones en la emisión.

Formato de almacenamiento: PKCS#12

El certificado se distribuye en formato PKCS#12 (extensión .p12 o .pfx), que incluye la clave privada y el certificado público protegidos por una contraseña. El ISV debe almacenar este archivo de forma segura: no en el repositorio de código, no en texto plano, idealmente en un HSM o en un servicio de gestión de secretos. La clave privada del certificado NO debe compartirse entre contribuyentes distintos: cada RNC emisor debe tener su propio certificado.

Estándar XAdES-BES: qué es y por qué lo usa la DGII

XAdES (XML Advanced Electronic Signatures) es el estándar europeo ETSI EN 319 132 para firmas electrónicas en documentos XML. La variante BES (Basic Electronic Signature) es el nivel base que incluye la firma criptográfica y los datos del certificado pero no requiere sello de tiempo externo ni validación de revocación en línea. La DGII adoptó XAdES-BES para los e-CF, alineándose con las prácticas de otros sistemas tributarios latinoamericanos que heredaron estándares de la experiencia española.

Para el desarrollador, XAdES-BES significa que la firma debe incluir: el valor de firma criptográfica (SignatureValue), el elemento KeyInfo con el certificado público en Base64, el elemento SignedInfo con la referencia al documento firmado y el algoritmo utilizado, y los elementos calificadores (QualifyingProperties) con la información del certificado y la hora de firma. La complejidad de ensamblar esta estructura manualmente es la razón por la que la mayoría de las implementaciones usan bibliotecas especializadas.

Algoritmo de firma: SHA-256 con RSA

La DGII requiere el algoritmo RSAwithSHA256 para la firma del e-CF. El URI del algoritmo en el campo SignatureMethod es 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'. El algoritmo de canonicalización del XML antes de firmar es Canonical XML 1.0, con URI 'http://www.w3.org/TR/2001/REC-xml-c14n-20010315'. Usar cualquier variante diferente (SHA-1, SHA-512, Canonical XML 1.1) produce el error 601. La longitud de clave RSA debe ser mínimo 2048 bits.

Proceso de firma paso a paso

El proceso de firma del XML e-CF sigue estos pasos: (1) Generar el XML completo con todos los campos del e-CF pero sin el nodo de firma. (2) Aplicar la transformación de canonicalización C14N al XML. (3) Calcular el digest SHA-256 del XML canonicalizado. (4) Construir el elemento SignedInfo con la referencia al digest y los algoritmos utilizados. (5) Firmar el SignedInfo con la clave privada del certificado PKCS#12 usando RSA-SHA256. (6) Insertar el elemento Signature completo en el XML, normalmente como último hijo del elemento raíz <ECDF>. (7) Verificar que el XML con la firma incluida supera la validación XSD antes de enviarlo.

Bibliotecas de firma por lenguaje: qué han usado los ISVs en RD

Para Java: xades4j es la opción más documentada para XAdES-BES en Java. Tambien se usa Apache Santuario (xml-security) para la firma XML base. Para .NET: el espacio de nombres System.Security.Cryptography.Xml ofrece soporte nativo para XML dsig; para XAdES-BES especificamente existen bibliotecas como FirmaXADES.NET. Para PHP: el manejo de XML firmado en PHP es el más complejo por la falta de soporte nativo robusto para C14N; la mayoría de los ISVs en PHP delegan la firma a un microservicio Java o .NET. Independientemente de la biblioteca, el ISV debe verificar que genera el elemento QualifyingProperties correcto según la especificación XAdES-BES que acepta la DGII.

Preguntas frecuentes sobre firma digital e-CF DGII

¿Cuál es el error 601 de la DGII y cuáles son sus causas más frecuentes?

El error 601 significa 'Firma Inválida' y puede tener varias causas: (1) El certificado no está vinculado al RNC emisor, (2) el XML fue modificado después de firmar (incluso whitespace o encoding), (3) el algoritmo de firma no es SHA-256 con RSA, (4) el elemento Signature está mal posicionado en el XML, (5) el certificado está vencido o fue emitido por una CA no reconocida por la DGII, (6) el BOM en UTF-8 alteró el digest del documento. El 601 es el error de firma más frecuente y el mensaje de la DGII no distingue entre estas causas.

¿Cómo puedo verificar localmente que la firma del e-CF es válida antes de enviarlo a la DGII?

Usando la misma biblioteca de firma para verificar el documento firmado: cargar el XML, extraer el elemento Signature, verificar el SignatureValue contra el público del certificado, y verificar que el digest de la referencia coincide con el contenido actual del documento. Si la verificación local pasa pero la DGII sigue rechazando con 601, revisar si el certificado está en la lista de CA aceptadas por la DGII. Algunos PSFEs ofrecen endpoints de pre-validación de firma.

¿Qué diferencia hay entre XAdES-BES y XAdES-T para el e-CF DGII?

XAdES-BES (Basic Electronic Signature) es el nivel que requiere la DGII: incluye la firma criptográfica y los datos del certificado, sin sello de tiempo externo. XAdES-T (Timestamp) agrega un sello de tiempo de una TSA (Timestamp Authority) que garantiza que la firma existía en un momento determinado, protegiendo contra certificados revocados después de la firma. La DGII no requiere XAdES-T para los e-CF estrictamente, aunque algunos PSFEs lo implementan internamente para garantizar mayor integridad legal.

¿Es posible rotar el certificado digital sin interrumpir la emisión de e-CF?

Sí, con planificación correcta. El nuevo certificado debe ser gestionado ante la misma CA o una nueva CA aprobada por el INDOTEL, y el RNC del emisor debe ser el mismo. La rotación debe programarse en un período de baja actividad. El proceso es: obtener el nuevo certificado con anticipación, configurarlo en el sistema de firma, validar con envíos de prueba en sandbox, y hacer el cambio en producción. Los e-CF firmados con el certificado anterior que ya están autorizados mantienen su validez; solo los nuevos e-CF deben usar el nuevo certificado.

Vigencia, costo y almacenamiento seguro del certificado

El certificado de firma digital para e-CF tiene vigencia limitada (normalmente 1 a 2 años según la entidad certificadora) y debe renovarse antes de su vencimiento para evitar interrupciones en la emisión. El costo varía según la CA autorizada por el INDOTEL y el tipo de certificado (persona física o jurídica), por lo que conviene presupuestar la renovación como un costo operativo recurrente, no como un gasto único de implementación.

Almacenamiento seguro del certificado privado

La clave privada asociada al certificado debe almacenarse cifrada en reposo (nunca en texto plano en el repositorio de código ni en variables de entorno sin cifrar), con acceso restringido a los servicios que efectivamente firman documentos. Es recomendable mantener un backup seguro del certificado y su contraseña en un gestor de secretos, ya que perder el acceso al certificado activo sin backup obliga a tramitar uno nuevo ante la CA y actualizar el rango de e-CF en la DGII, interrumpiendo la emisión hasta completar el proceso.