Ayuda con webservice via SSL

Battle-Cat

Catzilla!
Estimados,

Acudo a su infinita sabiduria con un kcho que me tiene mareado.

Ocurre que un proveedor X tiene 2 ambientes QA y PROD y se conecta con mi webservice. Yo tambien tengo ambientes QA y PROD--

El proveedor X desde su QA puede conectarse sin problemas a mis 2 ambientes QA y PROD.

Pero el proveedor X desde nu PROD no logra conectarse a ninguno de mis 2 ambientes.

Al realizar una captura de packetes con wireshark encuentro lo siguiente.

Prueba desde X QA a mi QA:

Despues del Client Hello la conexion se enlaca correectamente :D

1617737481228.png


Prueba desde X PROD a mi QA:

Despues del Clien Hello, inmediatamente mi server le hace un RST.

1617738918772.png



He buscado por todos lados la razon del por que mi server le genera un reset. Lo mas cercaro que ne encontrado es esto,



El workarround que dan es verificar los cipher que sugiere el cliente (X) y verificar si mi servidor los soporta. Esto ya lo realize y efectivamenmte varios de los cifrados ofrecidos son soportados por mi server, pero aun asi no se completa la conexion..

Alguien tiene alguna idea de donde podria buscar info? o de como resolver este tema?

Se agredece mucho su tiempo y ayuda.

Saludos,
 

Battle-Cat

Catzilla!
Encontre algo que tal vez podria ser el problema. Al comparar linea por linea el client hello entre lo enviador por PROD vs QA encontre que el largo era distinto (prod era mas corto). Al revisar al final me di cuenta de que QA me envia un parametro mas que PROD, se puede ver en el siguiente screenshot..
1617748286952.png


Sera por eso que mi server rechaza la conexion del proveedor X en ambos casos QA y PROD?
 
Upvote 0

Battle-Cat

Catzilla!
hola buenas..
tu cliente que version de JVM usa en el OSB 11g?
puede hacer un debug de ssl?

saludos
hola, segun los logs , utilizan Java1.7.0_191

Ni idea si podran hacer un debug SSL, espero que si.. por que les envie un correo con todo lo que encontre. Segun la documentacion RFC sobre las extensiones del TLS 1.2 (https://tools.ietf.org/html/rfc6066#page-19), el "server_name" es necesario para servidores que alojen multiples dominios), como es mi caso..
 
Upvote 0

Battle-Cat

Catzilla!
bueno , finalmente salio humo blanco. El problema era que el proveedor X habia configurado mal la conexion hacia mi webservice. En vez de poner la direccion con nombre onda https://webservice.loquesea.cl/servicio.svc habia dejado nuestra ip publica...

Entonces cuando el paquete de datos me llegaba obviamente no tenia el nombre, y por ende mi servidor lo reseteaba ya que no podia entregarlo a destino.
 
Upvote 0

neoyagami

Un misterio
bueno , finalmente salio humo blanco. El problema era que el proveedor X habia configurado mal la conexion hacia mi webservice. En vez de poner la direccion con nombre onda https://webservice.loquesea.cl/servicio.svc habia dejado nuestra ip publica...

Entonces cuando el paquete de datos me llegaba obviamente no tenia el nombre, y por ende mi servidor lo reseteaba ya que no podia entregarlo a destino.
llegue tarde.
cuando dijiste ambiente prod de inmediato pensé que tenia que ver con alguna regla del certificado. al ser solo ip de seguro el cert no era valido (los certificados van normalmente contra el nombre del fqdn y al ir por ip el cert se vuelve inválido

Por lo general las capas TLS(no ssl, eso esta deprecado) son super standard y salvo que tengan por norma prevenir el uso de ciertos cyphers no deberian tener problemas salvo su validación (como es el caso ahora)
 
Upvote 0
Subir