Llamadas a servicio https

[Drumpi]

Buenas a todos:

Definitivamente la programación en red no es lo mío ^^U O más bien, tengo un enorme hueco de conocimientos al respecto de usar librerías de comunicación en red.

A ver, tengo una API en red, que se presenta mediante, según leo, OData 3 o bien OData 4.
Hasta ahora, yo me creaba una WebApi y hacía las peticiones por http, pero ahora tengo que modificar el sistema para llamar a esta nueva API por https, y a pesar de que sigo las instrucciones, no consigo conectar.
El manual es muy genérico, no es específico de C#, por lo que sólo indica que para hacer login en el sistema deba mandar lo siguiente:

POST https://<server IP>:<port>/Login
{"User": "admin", "Password": "1234"}

Lo he intentado con Postman, y he podido mandar la info sin problemas... Bueno, me ha salido un mensaje de no se qué de TTS y lo he desactivado, y funciona (lo digo porque parece relevante).

Vale, pues este es mi código:

public static async Task Login ()
        {
            HttpResponseMessage response = null;
            HttpClient client = new HttpClient
            {
                BaseAddress = new Uri("192.168.1.2:55000")
            };
            HttpContent content;
            SLDataConnection data;
            string tempString;
            
            try
            {
                //Setting header as JSON
                client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

                data = new SLDataConnection()
                {
                    User = "admin",
                    Password = "1234"
                };

                //Envío del mensaje
                content = new StringContent(JsonConvert.SerializeObject(data), System.Text.Encoding.UTF8, "application/json");
                System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12 | System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls;
                response = await client.PostAsync("Login", content);
                
                if (response == null)
                    response = new HttpResponseMessage() { StatusCode = System.Net.HttpStatusCode.InternalServerError, ReasonPhrase = "Error de conexión" };


                if (response.StatusCode == System.Net.HttpStatusCode.OK)
                {
                    tempString = await response.Content.ReadAsStringAsync();
                    //data = JsonConvert.DeserializeObject<InfoLoginModel>(tempString);
                }
                else
                {
                    WriteInLog("Error de conexión " + ((int)response.StatusCode).ToString() + ": " + response.ReasonPhrase);
                }
            }
            catch (Exception ex)
            {
                System.Diagnostics.Debug.WriteLine("****** EXCEPTION: " + ex);
                WriteInLog("Excepción del programa:" + ex.Message);
            }

        }

Como veis, no hago nada raro (y quizás ese sea el problema, que falte algo). Pues este código me devuelve el siguiente mensaje de excepción en la línea del client.PostAsync:
"System.Net.Http.HttpRequestException: Error al enviar la solicitud. ---> System.Net.WebException: Se ha terminado la conexión: No se puede establecer una relación de confianza para el canal seguro SSL/TLS. ---> System.Security.Authentication.AuthenticationExcep tion: El certificado remoto no es válido según el procedimiento de validación."

Os daría más información, pero no la tengo.
He visto por internet que puedo usar Postman para obtener información de los metadatos de conexión, y usarlos para añadirlos como xml a las referencias del proyecto, y así consumir las llamadas a la API como si fueran funciones:
https://blogs.sap.com/2015/07/15/how...m-net-via-wcf/
Pero en el servidor de desarrollo usamos una BBDD común para varios proyectos, y los metadatos obtenidos son diferentes de los que van a tener los clientes finales (por las referencias a una serie de tablas y campos personalizados), por lo que no lo veo muy buena idea. Por eso intento hacerlo de esta forma tan "rudimentaria", porque una vez logeado, cada nueva llamada es coger los datos devueltos, meterlos en la cabecera, y añadir un JSON con los datos solicitados, que no es muy diferente a lo que se hacía hasta ahora (aunque tengo que modificar las clases "models" para que tengan los mismos campos que la nueva API).

Estamos pendientes de que nos den una formación al respecto, pero mientras, necesito avanzar por mi cuenta.
¿Alguna idea? Muchas gracias.

PD: Según he seguido leyendo, veo que es importante decir que el proyecto usa .NET Framework 4.5.2 (porque hay un callback para deshabilitar la seguridad que no tengo), y que por lo general, el programa que proporciona la API web, generalmente, en otros apartados de configuración que se hacen a través del navegador, Chrome suele dar el aviso de que no se puede confiar en el certificado de seguridad de la web... pero es porque creo que no implementa ninguno. Supongo que como está hecho para que el sistema funcione en local, les da igual el tema de seguridad... o es que no sabemos cómo instalarlo.

[juanvvc]

Menudo batiburrillo de cosas, ¿no?

Vamos a lo que creo que está pasando, que está en la postdata de tu mensaje:

Chrome suele dar el aviso de que no se puede confiar en el certificado de seguridad de la web... pero es porque creo que no implementa ninguno.

¿Cómo se llama https cuando no se incluye ningún certificado? http. Por eso y como Chrome dice que "no se puede confiar en un certificado" en vez de "no hay certificado", voy a a sumir que sí que hay certificado.

El error creo es ese: Chrome no confía en el certificado porque no conocerá a la CA o será autofirmado. Así que:

- Caso A: Si el certificado es autofirmado o similar, tiene que arreglarlo el servidor. Avísales
- Caso B: Si el servidor está usando una CA propia (es común es empresas grandes que tengan su propia CA para cosas internas), necesitas configurar HttpClient para que acepte el certificado de la CA de la empresa. Necesitas que el departamento de IT de la empresa te dé el certificado de la CA y lo añadas a la lista de certificados aceptados por HttpClient nosécómo porque no conozco tus librerías.
- Si quieres arreglar los casos A ó B como chapuza y solo para desarrollo y nunca debería llegar a producción, configura HttpClient para que ignore los certificados del servidor. En Chrome se hace dándole al botón "sé lo que hago, conecta" pero en librerías tienes que añadir la línea "ignora certificados de servidor" Ya te digo que no te recomiendo que esto llegue a producción.

Puedes encontrar opiniones sobre todo esto aquí, aunque me imagino que ya lo has visitado debido a esa muy probablemente innecesaria e insegura línea en la que escoges versión de TLS al ya obsoleto v1.1: https://stackoverflow.com/questions/...ing-httpclient

Todo lo demás que pones, XML y demás, hasta que HttpClient no haga una conexión no te valdrá de nada

Os daría más información, pero no la tengo.

Claro que la tienes. Cuando te conectas con Chrome, dale al candadito al lado de la barra de dirección y ahí verás si el certificado es autofirmado o la empresa está utilizando una CA propia

[Drumpi]

A ver, he avanzado un poco:
En Postman he encontrado la configuración que había deshabilitado: Enable SSL certificate verification.

Luego, el proyecto, lo he subido a .NET Framework 4.7.1 para poder añadir estas líneas al principio del método:

HttpClientHandler clientHandler = new HttpClientHandler();
            clientHandler.ClientCertificateOptions = ClientCertificateOption.Manual;
            clientHandler.SslProtocols = System.Security.Authentication.SslProtocols.None;
            clientHandler.ServerCertificateCustomValidationCallback = (httpRequestMessage, cert, cetChain, policyErrors) =>
            {
                return true;
            };

Con eso he pasado a tener respuesta, un error 500 del servidor, pero al menos no se me queja de error de protocolo de seguridad. Algo hay que no se entienden servidor y cliente.
Sigo haciendo pruebas, mirando lo de los protocolos de seguridad (como esa línea de clientHandler.SslProtocols, o añadiendo el protocolo TLS1.2 al System.Net.ServicePointManager.SecurityProtocol, que por lo visto es el que se usa).

He podido ver las lllamadas a la API. Cuando llamo con Postman, el log refleja esto:

[15/May/2023:13:45:05 +0200] 192.168.1.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 "POST /Login HTTP/1.1" 175

Por mi parte, he llegado a conseguir:

[15/May/2023:13:51:27 +0200] 192.168.1.2 TLSv1.2 ECDHE-RSA-AES256-SHA384 "POST /Login HTTP/1.1" -

Me faltaría por añadir ese GCM, que no sé lo que es, para que sea igual.

[juanvvc]

Eso de desactivar la validación de certificado es lo que te decía que no debería pasar a producción. Si estás seguro de que el certificado es correcto, añade la CA de la empresa a tu lista de CAs aceptadas (el departamento de IT debería ayudarte en esto) Si es autofirmado, avisa a quien gestione el servidor porque eso debería arreglarlo porque ya estamos en 2023

GCM es un modo de AES, que internamente usa SHA384. No va suelto: es todo junto AES256-GCM-SHA384,. No es algo que añadas o configures tú, es información de cómo está usando AES. Así que no será esto. Básicamente, porque no usar el modo GCM no provocará un error 500 en servidor, provocará el error que has visto antes "no puedo establecer una relación de confianza"

Un error 500 de servidor es un fallo del servidor. El admin del servidor puede dar más información de qué le está pasando. Seguramente es que no estás mandando los parámetros login/password como espera. En cualquier caso y pase lo que pase, un servidor bien hecho no debería dejar escapar un error 500 así que ahí tienen trabajo para arreglar.

[Drumpi]

No hables en tercera persona porque los que gestionamos el servidor somos nosotros ^^U
Sí que es verdad que hay un funcionamiento de "caja negra", en el que no tenemos acceso al código del programa... pero somos los encargados de instalarlo, configurarlo y mantenerlo.

Ya sé que no debería ignorar los certificados, pero quiero ver que funciona. Creía que se estaban ignorando, pero no, por lo visto sí que hay un certificado, y desde el navegador he podido exportarlo... aunque estoy hablando con un compañero, a ver si se puede obtener de otra forma.
Desde aquí
https://stackoverflow.com/questions/...ore-httpclient
veo cómo añadir el certificado a mi código, el problema es que no sé qué tipo de certificado de módulo System.Security.Cryptography debería usar, y no me da mucha confianza copiar el certificado a una carpeta del proyecto, porque al pasarlo a producción, si se copia tal cual, es un problema de seguridad.

Bueno, al menos voy avanzando poquito a poco. Espero que con el login hecho, el resto ya sólo sea consumir la API y traducir modelos de datos a JSON.

[juanvvc]

Estás mezclando otra vez

El enlace que mandas es para certificados de cliente. Es la primera vez que mencionas los certificados de cliente. De hecho, arriba mencionas login y password así que voy a asumir que tú te autenticas usando login y password y no certificados de cliente. No hagas caso a eso que dice la web que enlazas porque es para certificados de cliente

Lo que digo es que tienes que añadir a la CA que validó al servidor a tu lista de certificados de servidor aceptados. Certificado de servidor, no de cliente

En https hay al menos dos tres certificados:

- Los servidores tienen un certificado y se lo envían a los clientes cuando se conectan a ellos. Los servidores siempre tienen certificado, no son optativos. Los certificados de servidor están validados por una CA o por ellos mismos (autofirmados)
- Las CA tienen un certificado que son los que usan para validar a los servidores. No se envían, están instalados en tu navegador o en el sistema operativo. En librerías es común que puedas añadir un directorio con "certificados de CA extra". Este es el paso que puedes "ignorar" como has hecho más arriba.
- Los clientes podrían tener un certificado pero son optativos y casi nunca lo tienen, solemos conectarlos usando usuario/contraseña. ¿Recuerdas el follón para instalar el DNIe en tu navegador? Eso es un certificado de cliente. ¿Lo has hecho alguna vez? Casi seguro que no, para que veas lo poco que se usan.

[josepzin]

Vaya marrones que te caen eh!

[Drumpi]

A ver, que me estoy liando:
Desde Postman, con la opción "enable SSL certificate verification" desactivada funciona, pero si la activo me da error. En el primer caso me da un warning, y en el segundo un error con el mismo mensaje: "self signed certificate".

El caso es que tengo que conectarme con el código de arriba, y no sé qué estoy haciendo mal. En las instrucciones proporcionadas por el desarrollador de la aplicación no se menciona nada de cetificados, ni firmas ni nada, sólo enviar los dos valores en el body hacia la ruta de login, y eso me devuelve una cookie con el token y el identificador de sesión, que debo enviar en el resto de conexiones.
Luego hay dos protocolos extra de conexión, pero ambos comienzan con la misma llamada a la URL de Login.

A las malas, puedo suprimir la seguridad, porque podría poner las conexiones en la WebApi propia para que haga las conexiones con esta API de forma local. Aún no tengo claro si hacer las llamadas directamente a la API o pasarlas por la WebApi, porque el sistema actual no es compatible, y hay que modificar los modelos de datos para adaptarlos a la nueva API, cosa que podría hacer directamente en la APP, pero veo más sensato hacerlo en el servidor para mantener la compatibilidad.

[juanvvc]

Pues eso, que falta que tú aplicación valide el certificado de servidor

La solución más obvia es que el admin del servidor le ponga un certificado fácilmente validable, que es lo suyo. Por eso la documentación de tu librería no dice nada, porque asume que el servidor està configurado con un certificado validable sin hacer nada más especial. Como es normal a estas alturas de la vida.

-----Actualizado-----

Self signed certificate: significa que los admins del servidor han instalado haciendo okokok y no le han puesto un certificado válido.

-----Actualizado-----

No sé si lo estoy diciendo claro, eh: el problema está en el servidor.

Puedes configurar tu aplicación para ignorarlo (esa opción de que no valide certificado), pero el que tiene que arreglarlo es el servidor poniéndole un certificado válido al antes de que esto llegue a producción

[josepzin]

Lo suyo es echarle la culpa a los del servidor, pero en este caso estas jodido porque el servidor es vuestro :v

Enviado desde mi M2101K7AG mediante Tapatalk

[Drumpi]

Pues eso, que falta que tú aplicación valide el certificado de servidor

La solución más obvia es que el admin del servidor le ponga un certificado fácilmente validable, que es lo suyo. Por eso la documentación de tu librería no dice nada, porque asume que el servidor està configurado con un certificado validable sin hacer nada más especial. Como es normal a estas alturas de la vida.

-----Actualizado-----

Self signed certificate: significa que los admins del servidor han instalado haciendo okokok y no le han puesto un certificado válido.

-----Actualizado-----

No sé si lo estoy diciendo claro, eh: el problema está en el servidor.

Puedes configurar tu aplicación para ignorarlo (esa opción de que no valide certificado), pero el que tiene que arreglarlo es el servidor poniéndole un certificado válido al antes de que esto llegue a producción

Eso no se va a hacer, te lo digo ya, porque es una parte del sistema que no se usa y que daría más problemas que soluciones. De todas formas, me informaré sobre eso con los que llevan esa parte del ERP.

Supongo que cuando dices que configure mi aplicación para ignorarlo te refieres a la parte del ServerCertificateCustomValidationCallback del tercer mensaje. Eso ya está hecho, y en principio, no tengo más errores de TLS ni de seguridad.
Sin embargo, el servidor me devuelve un error 500 que no me da Postman. En este punto, o a mi aplicación le falta algo, que no está enviando bien los datos (no sé si porque falte una librería, o porque estén mal configurados lo datos que se envían), o el servidor tiene algún tipo de problema con mi APP, y no sé cómo comprobar de dónde viene el problema.
Voy a intentar hacer la llamada desde la APP, que tiene más masticadito el tema de peticiones por http, y también a cambiar de servidor donde estoy haciendo las pruebas, a ver si es que la API está mal instalada en este. Pero ya podría haber un log que me diga por qué hay un error 500, porque la API del servidor sólo me da datos de las llamadas.

[Drumpi]

Vale,he hecho algunas pruebas: he llamado a la API instalada en otro servidor y, mismo problema.
Luego he trasladado la función que llama a la API a una APP Android (he tenido que escribir un buen tocho para descartar que se miren los certificados, pero por suerte no he tenido que desarrollarlo yo), y desde ahí ha funcionado perfectamente, por lo que entiendo que tengo algún problema con las librerías instaladas en el primer proyecto.
El problema es que creía que mirando los paquetes Nuget (el que le puso ese nombre, se lució) daría con el problema, pero no, es algo más interno del proyecto, algo con las referencias, y no sé ni por dónde empezar a mirar.

[juanvvc]

no tengo más errores de TLS ni de seguridad.

Claro que tienes un problema de seguridad: estás aceptando certificados autofirmados. Eso y no tener seguridad es casi lo mismo.

Pero ya podría haber un log que me diga por qué hay un error 500

Y estoy seguro de que lo habrá, en el servidor. Un error 500 es un error de servidor, no porque tú estés haciendo algo mal (aunque a lo mejor sí). La excepción está saltando en el servidor y seguro que hay un log en el servidor diciendo qué está pasando

"pues ya podría decirme el servidor qué le pasa sin tener que ir a mirarlo yo". Pues sí, ya podría decírtelo. En mi opinión, un error 500 no debería llegar nunca a un cliente, significa que el programador del servidor está dejando pasar cosas que no debería. Así es como se hackean servidores...

[Drumpi]

Claro que tienes un problema de seguridad: estás aceptando certificados autofirmados. Eso y no tener seguridad es casi lo mismo.

Esto me suena más a troleo que a otra cosa
Me refiero a que no tengo avisos de errores especifícos de seguridad, que el error 500 viene por otro lado.
Sí, ya sé que no debería aceptar certificados autofirmados, ni ignorarlo, pero:
1- Estoy intentando averiguar cómo funciona la API.
2- La API se va a consumir en local. Finalmente la APP llamará a una WebApi propia, y esta será la que se comunique con la API web. Estas dos últimas estarán instaladas en la misma máquina, por lo que no hay necesidad de exponer la última a la red, y la funcionalidad que ofrecerá nuestra WebApi será mínima.

Y estoy seguro de que lo habrá, en el servidor. Un error 500 es un error de servidor, no porque tú estés haciendo algo mal (aunque a lo mejor sí). La excepción está saltando en el servidor y seguro que hay un log en el servidor diciendo qué está pasando

"pues ya podría decirme el servidor qué le pasa sin tener que ir a mirarlo yo". Pues sí, ya podría decírtelo. En mi opinión, un error 500 no debería llegar nunca a un cliente, significa que el programador del servidor está dejando pasar cosas que no debería. Así es como se hackean servidores...

He encontrado algunos logs, pero sólo dan datos de las peticiones (hora, programa solicitante, ruta de petición, respuesta, tiempo de respuesta...). Si hay algún otro, la "caja negra" no me dice dónde está.
Lo dicho, un proyecto de una APP Android no ha tenido problema en enviar y recibir los datos, pero un proyecto WebApi 2.0 envía, y no recibe, y cada vez estoy más convencido de que hay alguna librería en el proyecto que me falta por añadir o por actualizar. El problema es que no sé qué librerías necesito, ni dónde buscarlo.

[juanvvc]

Pero algún error guardará el servidor. Como solo dices "caja negra" pero no dices si es windows o linux o apache o tomcat o iss o qué, pues no te sé decir más. Mira el syslog o el eventlog o el errors.log según lo que sea el servidor.

Es muy raro que si falta una librería en el cliente provoque errores 500 en el servidor. Probablemente estás enviando los datos en un formato que el servidor no espera, o te falta alguna variable. A unas muy malas mete ahí en medio un proxy y espía las comunicaciones de la App Android. Total, ya tienes certificados autofirmados, aprovecha y espiate tú.