Firma Digital BNCR para Factura y Tiquete Electrónico en Costa Rica
La firma digital en Costa Rica para factura electrónica requiere un certificado emitido por el BNCR o entidad autorizada por el Ministerio de Ciencia y Tecnología.
El certificado digital del Banco Nacional de Costa Rica (BNCR) es el mecanismo estándar para firmar documentos electrónicos ante Hacienda. Sin certificado vigente, la facturación electrónica se detiene completamente: ningún documento puede transmitirse sin firma XAdES válida. Y cuando el certificado es válido pero la firma sigue rechazándose, el problema casi siempre está en una sutileza de la canonicalización XML o en los algoritmos aplicados que ninguna librería detecta automáticamente.
Esta guía explica qué certificados acepta Hacienda Costa Rica, cómo obtener uno BNCR, cómo se aplica la firma XAdES sobre un documento v4.4, qué algoritmos y mecanismos de canonicalización exige Hacienda, y los errores frecuentes en la firma que aparecen en producción cuando algún parámetro queda fuera de lo esperado.
Qué certificado exige Hacienda Costa Rica
Firma de persona física vs jurídica
Hacienda acepta certificados de firma digital emitidos a personas físicas (cédula de identidad) o a personas jurídicas (cédula jurídica). El que se usa para firmar facturas electrónicas debe corresponder al emisor del documento. Para empresas, lo habitual es que el representante legal firme con su certificado personal o que la empresa cuente con certificado jurídico específico. El sistema emisor debe almacenar el certificado correcto según el caso.
Emisores autorizados de certificado
El BNCR es el emisor principal y más usado en Costa Rica para certificados de firma digital con fines fiscales. Adicional, otras entidades autorizadas por el Ministerio de Ciencia, Innovación, Tecnología y Telecomunicaciones (MICITT) también pueden emitir certificados válidos para Hacienda. La elección entre proveedores se basa principalmente en conveniencia del trámite y de la atención: la firma resultante es idénticamente válida ante Hacienda.
Proceso para obtener el certificado BNCR
Trámite y requisitos
El trámite ante el BNCR requiere identificación vigente (cédula de identidad para personas físicas, cédula jurídica más personería jurídica vigente para empresas), una visita presencial en una sucursal autorizada del banco, y la entrega del dispositivo criptográfico que almacena la clave privada. El BNCR entrega un token físico o un certificado en formato P12 según la modalidad solicitada.
Vigencia y costo aproximado
La vigencia típica del certificado es de dos a cuatro años según la modalidad. El costo varía pero se mueve en el rango de unos miles de colones costarricenses por año de vigencia. La renovación se hace siguiendo un proceso similar al de emisión: visita al BNCR con la documentación actualizada. No conviene esperar al último día; la práctica recomendada es renovar al menos 30 días antes del vencimiento.
Aplicación de XAdES sobre v4.4
Estructura de la firma en el XML
La firma XAdES se incluye dentro del propio XML del documento v4.4 en un bloque específico definido por el esquema. La firma contiene tres elementos principales: SignedInfo con las referencias canónicas al contenido firmado, SignatureValue con el hash firmado por la clave privada, y KeyInfo con los datos del certificado del firmante. Adicional, los qualifying-properties (SigningTime, SigningCertificate) que XAdES exige.
Algoritmos y canonicalización requeridos
Hacienda Costa Rica exige específicamente SHA-256 para los digests, RSA-SHA256 para la firma asimétrica, y C14N Exclusiva (Exclusive XML Canonicalization 1.0) para la canonicalización. Una combinación incorrecta — por ejemplo, C14N inclusiva en lugar de exclusiva — produce firma que matemáticamente verifica localmente pero que Hacienda rechaza al recalcularla en el lado servidor. Verificar explícitamente la variante de canonicalización configurada en la librería es paso obligatorio.
Errores frecuentes en la firma
Certificado vencido sin alerta previa
El BNCR no envía notificaciones automáticas al titular antes del vencimiento del certificado. Una vez vencido, todas las firmas se rechazan inmediatamente y la facturación se detiene. La buena práctica es implementar un check automatizado dentro del sistema emisor que alerte 30, 15 y 5 días antes del vencimiento, integrado al monitoreo del servicio. Renovar requiere visita presencial al BNCR, que toma uno o más días hábiles.
Canonicalización inválida
Aparece como rechazo de firma cuando matemáticamente la firma local verifica pero Hacienda no la acepta. Causa habitual: librería configurada en C14N inclusiva por defecto. La verificación recomendada es firmar y validar el documento localmente con xmlsec1 usando el certificado público de Hacienda como confianza. Si valida localmente y Hacienda sigue rechazando, el problema es del policy ID o de un qualifying-property faltante.
Reloj del servidor desincronizado
El SigningTime de la firma debe estar dentro de una ventana razonable respecto al servidor de Hacienda. Si el servidor del cliente está desfasado más de unos minutos, las firmas se rechazan por SigningTime fuera de ventana. Sincronizar NTP en el servidor que ejecuta la firma es la primera verificación cuando aparecen rechazos intermitentes sin causa aparente.
Almacenamiento seguro del certificado privado
Cifrado en reposo y acceso restringido
El certificado privado (P12 o token) debe almacenarse cifrado en reposo. No se debe versionar en el repositorio de código bajo ninguna circunstancia. La práctica recomendada es usar un secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) con rotación periódica de la contraseña del P12 y acceso restringido solo al servidor que ejecuta la firma.
Backup y restauración
Si el archivo P12 se pierde y no hay backup, la única vía es solicitar reemisión al BNCR, lo cual implica visita presencial y bloquea la facturación durante el trámite. Mantener backup del P12 cifrado en al menos dos ubicaciones independientes es obligatorio operativamente. La contraseña del P12 debe almacenarse en un sistema distinto del backup.
Preguntas frecuentes
¿Cuál es la diferencia entre el certificado del BNCR para fines fiscales y para otros usos? El BNCR emite certificados digitales para distintos propósitos: firma de documentos generales, autenticación bancaria, y firma con propósito fiscal. El certificado válido para facturación electrónica debe tener el propósito fiscal habilitado explícitamente y debe estar emitido a la persona física o jurídica que figura como emisor en los documentos. Confundir certificados de propósito general con los fiscales es un error común al iniciar: si el certificado no tiene el propósito correcto, Hacienda rechaza la firma aunque matemáticamente sea válida.
¿Cómo puedo validar una firma localmente antes de transmitir a Hacienda? Con xmlsec1 desde línea de comandos: xmlsec1 verify --trusted-pem cert-hacienda.pem documento_firmado.xml. Si la verificación local pasa pero Hacienda rechaza, el problema es de validación específica del policy de Hacienda, no de la firma matemática. En Java con Apache Santuario: instanciar XMLSignatureFactory, parsear el documento, llamar a XMLSignature.validate(). En Python con xmlsec: usar XMLSecurity.verify_signature(). Los tres deben coincidir; si uno valida y otro no, hay diferencia en la canonicalización aplicada.
¿Qué diferencia hay entre los certificados del BNCR y los de otras entidades certificadoras? Funcionalmente, los certificados de cualquier entidad autorizada por el MICITT son equivalentes ante Hacienda: la firma resultante es idénticamente válida. Las diferencias están en el proceso de emisión (visita presencial requerida o no, modalidades de entrega), el costo, la vigencia ofrecida y la conveniencia de la atención. El BNCR es el más usado por su red de sucursales y por ser banco estatal. Otras entidades pueden ofrecer procesos más ágiles o costos diferentes. La elección depende más de comodidad operativa que de funcionalidad ante Hacienda.
¿Es posible firmar facturas sin tener el certificado físicamente en el servidor? Sí, mediante HSM (Hardware Security Module) o servicios cloud equivalentes (AWS CloudHSM, Azure Dedicated HSM, Google Cloud KMS con keys asimétricas RSA). En esas arquitecturas, la clave privada nunca sale del HSM; el servidor envía el hash a firmar y recibe la firma de vuelta. Es la opción más segura operativamente y la única viable en arquitecturas multi-tenant con auditoría regulatoria estricta. El costo es mayor que un P12 local pero elimina el riesgo de filtración del certificado y simplifica la auditoría SOC 2 o ISO 27001.
Artículos Relacionados
Errores de rechazo de la DGII en e-CF: cómo diagnosticarlos y corregirlos desde un agente de IA
Los rechazos de la DGII en e-CF tienen causas precisas y acciones correctivas definidas. Esta guía explica el ciclo de vida del documento, los códigos de error más frecuentes y cómo un agente de IA puede diagnosticar y corregir rechazos de forma autónoma.
Cómo conectar un agente de IA a la DGII en República Dominicana: guía paso a paso con el MCP de Alanube
Guía completa para conectar un agente de IA a la DGII de República Dominicana usando el único servidor MCP de infraestructura fiscal disponible actualmente: configuración del cliente, primer e-CF en lenguaje natural y emisión programática con TypeScript.
Las 30 herramientas del MCP de infraestructura fiscal de República Dominicana: referencia completa
Referencia consolidada en español de las 30 herramientas del único servidor MCP de infraestructura fiscal conectado a la DGII en República Dominicana: organización por capas, casos de uso y cuándo usar el orquestador vs. emisión directa.