Trabajando con el SII, me encontre que recibia null en una consulta SOAP que deberia traer datos. No arrojaba errores de Java asi que simplemente me regresaba null sin resultados en un servicio que deberia funcionar.
Usualmente en casos asi, hago una captura de paquetes para revisar retrasos, perdidas de datos, cruce información, etc. Pero esta conversacion estaba cifrada con TLS 1.2 por lo tanto toda la comunicacion estaba encriptada y la captura no arrojaba información util par resolver el caso.
Aqui les dejo un video de Chris Greer donde explica como hacer para aplicaciones web que les puede ser util:
Sin embargo, esta tecnica no funciona en el entorno Java que estaba trabajando ya que no captura las llaves de la sesion. Para poder capturar las llaves de sesion desde Java debemos usar una herramienta llamada jSSLKeyLog que nos ayudara a conseguir las llaves de sesion para desencriptar los datos y poder hacer un debug.
Para usar jSSLKeyLog primero debemos descargarlo y de preferencia guardarlo en la misma carpeta donde esta nuestro Jar para simplicidad. Importante que recomiendan Java 1.7 o superior.
Luego segun las instrucciones ejecutar nuestro Jar con el siguiente comando:
java -javaagent:jSSLKeyLog.jar=/path/to/your_logfile.log -jar file.jarEsto nos generara un archivo de texto que contiene las llaves de sesion en la ruta que ingresamos. Ahora lanzamos Wireshark para que comience la captura y luego de eso ejecutamos la funcion que hace la llamada, asi se capturaran las llaves de sesion y los paquetes al mismo tiempo. Una vez terminada la consulta podemos detener Wireshark.
Ahora debemos cargar las llaves de sesion en Wireshark para que pueda desencriptar los paquetes aqui:
Luego de dar aceptar Wireshark utilizara las llaves para mostrarnos informacion adicional de los paquetes como las rutas donde se hacen las request, tal como las vemos cuando analizamos paquetes sin cifrado. Podemos ver que se esta haciendo una request a esta direccion https://ws2.sii.cl/WSREGISTRORECLAMODTECERT/registroreclamodteservice
Al hacer una peticion curl al endpoint que conseguimos en el analisis obtenemos el siguiente resultado:
Y podemos ver que el problema no es nuestra aplicación sino que el servidor tiene error interno o error 500. Lamentablemente no podemos utilizar este servicio porque por el lado del servidor hay un error, pero por lo menos todo este trabajo nos sirvio para descartar un problema con nuestra aplicación.
