Imprimir
Categoría: Factura Electrónica - AFIP Argentina
Visto: 10296

Aquí describo los pasos a seguir para conectarse al WSAA utilizando SOAPUI y OpenSSL. Esto permite conocer todos los pasos que deberá realizar nuestra aplicación para obtener la clave de sesión que después debe emplearse para obtener el CAE y experimentar un poco con los WS antes de comenzar a desarrollar.

Requisitos Previos

Seguridad y presionar el botón certificados. A continuación debemos importar el certificado:
pruebaWSAA02.jpg

Creación del certificado de la empresa que se conecta a la AFIP

openssl genrsa -des3 -out privada1.pem 2048

Si llegamos a perder la contraseña que utilizamos en este caso, no habrá forma de que firmemos los archivos XML y tendremos que comenzar todo el proceso de nuevo.

[ req ]
default_bits         = 2048
default_keyfile     = privada1.pem
distinguished_name     = req_distinguished_name
prompt             = no
 
[ req_distinguished_name ]
C            = AR
ST            = Capital Federal
L            = Capital Federal
O            = MiOrganizacion
serialNumber  = CUIT 20305949125
OU            = Facturacion
CN            = MiSistema

Nos conviene en este caso, utilizar nuestro CUIT ya que la AFIP permite solamente un certificado por CUIT en su ambiente de homologación.

openssl req -config confCert.txt -out privada1.request.csr -verify -key privada1.pem -sha1 -new -batch

El mismo se debe enviar a la AFIP (Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo., no estoy seguro), para que nos envíen el certificado asociado. Como este proceso tarda uno o dos días, a continuación vamos a crear un certificado firmado por nosotros. Este no sirve para conectarse al WS, ya que la AFIP nos reportará un error, pero al menos sirve para saber cuáles son los pasos a seguir con el que finalmente recibamos de la AFIP.

openssl req -x509 -days 1095 -config confCert.txt -out privada1.selfsigned.cer -verify -key privada1.pem -sha1 -new -batch

Ahora vamos a utilizar el certificado privada1.selfsigned.cer para nuestras pruebas.

Conectarnos al Web Service

De esta manera, después de haber leído los dos archivos con las definiciones de los Web Services de la AFIP, el SOAPUI creara templates para el XML que hay que enviar.
pruebaWSAA03.jpg

En este caso el único dato que nos esta faltando es el tag request se debe llenar con el contenido de un pequeño
archivo XML firmado con el certificado.

<?xml version="1.0" encoding="UTF-8" ?>
<loginTicketRequest version="1.0">
  <header>
    <source>serialNumber=CUIT 20305949125,CN=MiSistema,OU=Facturacion,O=MiOrganizacion,ST=Capital Federal,C=AR</source>
    <destination>cn=wsaahomo,o=afip,c=ar,serialNumber=CUIT 33693450239</destination>
    <uniqueId>123456</uniqueId>
    <generationTime>2008-06-01T20:49:00-03:00</generationTime>
    <expirationTime>2008-06-01T20:09:00-03:00</expirationTime>
  </header>
  <service>wsfe</service>
</loginTicketRequest>


El campo source hay que llenarlo con el campo Subject del certificado. Para obtener este dato, solo hay que hacer
doble click sobre archivo con el certificado y Windows nos mostrará el dato que necesitamos en la segunda solapa.

pruebaWSAA01.jpg

Las fechas es conveniente adelantarlas un par de minutos.

Nota: Ahora los tags source y destination son opcionales. Todavía no hice las pruebas con nuestra aplicación, pero me informaron que sí. Así que directamente se pueden quitar del XML, es decir, no tienen que ni aparecer.

Por ese motivo, el archivo puede quedar así:

<?xml version="1.0" encoding="UTF-8" ?>
<loginTicketRequest version="1.0">
  <header>
    <uniqueId>123456</uniqueId>
    <generationTime>2008-06-01T20:49:00-03:00</generationTime>
    <expirationTime>2008-06-01T20:09:00-03:00</expirationTime>
  </header>
  <service>wsfe</service>
</loginTicketRequest>

Hay que asegurarse que nuestro editor guarde el archivo ticket.xml como ASCII puro y no como UNICODE. Ultraedit tiene
un bug y automáticamente realiza la conversión a Unicode.

openssl smime -sign -signer privada1.selfsigned.cer -inkey privada1.pem -out ticket.xml.cms -in ticket.xml -outform PEM -nodetach
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode xmlns:ns1="http://xml.apache.org/axis/">ns1:coe.notAuthorized</faultcode>
         <faultstring>Computador no autorizado a acceder los servicio de AFIP</faultstring>
         <detail>
            <ns2:exceptionName xmlns:ns2="http://xml.apache.org/axis/">gov.afip.desein.dvadac.sua.view.wsaa.LoginFault</ns2:exceptionName>
            <ns3:hostname xmlns:ns3="http://xml.apache.org/axis/">avaricia.afip.gov.ar</ns3:hostname>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

El motivo por el cual no estamos autorizados para acceder a los WSs de la AFIP, es que el certificado que utilizamos
para firmar el ticket no fue creado por la AFIP.

Cuando se utilice el certificado devuelto por la AFIP, el XML de respuesta debería traer un tag token y otro sign.
En la pagina del WSAA encontrará ejemplos.

Conclusión

Este es el primer paso para utilizar los WS de la AFIP. A continuación, tenemos que utilizar el valor de token y sign, para armar los XMLs para conectarnos a los restantes, en particular, el que nos devuelve los CAEs.
Sin embargo, después de haber realizado los pasos anteriores, tendrá una idea más acabada de los pasos para obtener la clave de sesion (ticket en la jerga de la AFIP) que es el paso más complejo de todo el procedimiento.