Certificado digital para web services de ARCA

Todo web service de ARCA (ex AFIP) se apoya en un certificado digital. Es la identidad con la que se firma el pedido de acceso del WSAA. Entender sus piezas, sus ambientes y quién lo custodia te evita la mayoría de los errores de configuración, tanto si integrás directo con ARCA como si facturás por la API de YoFacturo.

Las tres piezas de un certificado de web service

Cuando se habla del "certificado" de ARCA en realidad hay tres archivos distintos que se relacionan entre sí:

Con la clave privada y el certificado se arma la firma CMS del TRA que se envía al WSAA. Ese circuito está explicado paso a paso en la guía de WSAA.

Un certificado, un alias, un computador fiscal

En ARCA el certificado queda registrado bajo un alias, y ese alias figura como un computador fiscal. Es el motivo por el cual, al delegar un servicio a otro CUIT, ARCA a veces muestra la advertencia "Ud no cuenta con Computadores Fiscales registrados". Esa advertencia se refiere a que quien delega no tiene computadores propios, lo cual no impide delegar. Los servicios (facturación electrónica, padrón, exportación) se habilitan sobre ese computador fiscal.

Producción y homologación llevan certificados distintos

ARCA emite los certificados de cada ambiente por separado. El de homologación se gestiona en el portal WSASS y el de producción en el circuito habitual de certificados digitales de ARCA. Un certificado de un ambiente no sirve en el otro: el WSAA de homologación rechaza el certificado de producción. Si en tu integración ves que la autenticación falla solo en uno de los dos ambientes, lo primero que hay que revisar es que cada uno firme con su certificado.

Para el resto de las diferencias entre ambientes, mirá homologación vs producción.

Cómo lo resuelve YoFacturo

YoFacturo no emite ni administra certificados por cliente. La plataforma tiene un único par de certificado y clave por ambiente, guardado en un almacén de secretos y no en el código. El certificado de producción está emitido a nombre del CUIT 20-44894138-9, y el de homologación es otro, emitido por separado.

Lo que cada cliente hace es delegar: le indica a ARCA que autoriza a ese CUIT a operar el web service de facturación electrónica en su nombre. Con esa relación aceptada, el certificado de la plataforma firma y el CUIT del cliente figura como emisor de cada comprobante. Por eso un cliente nuevo no genera claves ni sube archivos. El paso a paso está en la guía de delegación.

Cuándo sí necesitarías un certificado propio

Si escribís tu propio cliente SOAP y hablás directo con el WSAA y con WSFEv1, ARCA te exige tu certificado y tu clave privada, porque ahí el firmante sos vos. Es el camino de quien integra sin intermediarios. Con la API de YoFacturo ese trabajo desaparece: no implementás el WSAA, no renovás tickets y no custodiás claves. La diferencia entre ambos caminos está contada en la guía de web service sin certificado.

Señales de un problema de certificado

Para ver en qué ambiente está tu cuenta de YoFacturo, GET /bill/tax_info/taxpayer/ devuelve el campo afip_environment del contribuyente activo, con el valor testing o production. Requiere el scope accounting:read. Si tu objetivo es evaluar el producto, la página de la API de facturación electrónica resume qué cubre.

Seguí leyendo