Conectarse al WSAA utilizando OpenSSL y SOAPUI

Detalles: Categoría: Factura Electrónica - AFIP Argentina; Creado: 15 Junio 2008; Visto: 10240

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

Instalar OpenSSL y agregar el subdirectorio bin al PATH.
Instalar SOAPUI http://www.soapui.org/.
Instalar el certificado de la Autoridad Certificante de la AFIP del ambiente de homologación. Hay que instalarlo en la VM de Java. Para ello, tenemos que ir a Panel de Control / Java, a la solapa

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

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

Creamos la clave privada (archivo privada1.pem):

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.

Creamos un archivo confCert.txt con los datos que deseamos incluir en el certificado, en nuestro caso contiene:

[ 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.

Creamos un archivo request.

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.

Creamos un certificado self-signed.

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

Abrimos el SOAPUI.
Creamos un nuevo proyecto con la siguiente WSDL https://servicios1.afip.gov.ar/wsfe/service.asmx?wsdl y marcamos la opcion Create sample request for all operations.
Presionamos el botón derecho sobre el proyecto y seleccionamos Add WSDL from File e importamos el siguiente archivo wsdlAutentificacion.xml. Este archivo contiene la misma definición que el PDF sobre WSAA de la AFIP, porque en este caso no sé cuál es la URL.

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.

Abrimos el request1 del servicio LoginCMS.

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.

Creamos el siguiente archivo y lo guardamos con el nombre ticket.xml:

<?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.

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.

A continuación firmamos y convertimos a Base64 el archivo anterior:

openssl smime -sign -signer privada1.selfsigned.cer -inkey privada1.pem -out ticket.xml.cms -in ticket.xml -outform PEM -nodetach

Ahora lo que tenemos que hacer es copiar el contenido del archivo ticket.xml.cms quitando las lineas de header y footer, y dejando solamente lo que parece cifrado.

Tenemos que copiarlo al tag request en el SOAPUI.
Después editamos la URL para que quede https://wsaahomo.afip.gov.ar/ws/services/LoginCms y enviamos el request.
Si todo funciono bien, obtendremos una respuesta similar a:

<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.

Escribir un comentario

JComments