OVH Community, your new community space.

Certificado SSL de OVH + TPV Redsys


elabrelatas
07/02/2017, 18:03
¡Hola a todos!

Gracias por compartir el problema Saul Goodman y alvaroag por toda la información. Estaba buscando información sobre el TPV Redsys en Woocommerce, pero como he tenido el mismo problema en Prestashop, me gustaría compartirlo con vosotros.

El año pasado (finales de 2016) con el inminente cambio de funcionalidad Redsys basado en un nuevo sistema de firma HMAC SHA256 (antes tenían SHA-1), nos informó que deberíamos de instalar el certificado digital que cumpliera con esa características (SHA2).

Estábamos alojados en OVH en un hosting compartido, con lo cual, nos pusimos en contacto con el soporte y decidimos contratar el certificado SSL con las características que ellos nos indicaron. Ese certificado estaba perfectamente instalado por OVH, pero había un problema, a Redys, se les olvidó mencionarnos que la lectura del certificado debería estar asociada al dominio y a la IP. Ese pequeño descuido, lo conseguimos saber después de unos 200 emails y llamadas a un 902 de Redsys

Por supuesto, el servicio de hosting que teníamos contratado, no nos permitía pasar el certificado por IP. Desde OVH, nos informaron que, únicamente en un VPS o un Servidor Dedicado podríamos tener esa posibilidad.

En aquel momento, no nos podíamos hacer cargo ni económica ni personalmente (aunque estábamos muy contentos con el servido de OVH) de ninguna de las dos propuestas que nos hicieron.

Finalmente tuvimos que migrar nuestra página a otro proveedor que nos facilitara un certificado y una IP fija asociada a nuestro espacio web.

Ahora vuelvo a tener el mismo problema con la página de un cliente que está en woocommerce en otro proveedor de servicio hosting.

Espero que os ayude nuestra historia y os evite la pérdida de tiempo que nos supuso a nosotros por culpa única y exclusivamente de REDSYS un servicio que deja bastante que desear tanto en funcionalidad como en atención al cliente.

¡Un saludo!

virtual
17/10/2016, 18:57
Hola marionpy,

Que módulo de redsys tienes instalado ?

Muchas veces el problema suele ser de un módulo mal instalado o que no es el original y es una versión realizada o modificada por otro usuario.

Prueba a reinstalar el módulo que ofrece redsys y nos cuentas.

marionpy
17/10/2016, 17:16
Buenos días,
Has encontrado una solución a tu problema?
Tengo exactamente el mismo problema, he montado una tienda a través de prestashop con hosting y certificado SSL OVH y hace poco tengo la pasarela de pago Redsys Banc Sabadell, y prestashop no genera los pedidos aunque la compra se realiza ...
El soporte de redsys Banc Sabadell me dice que el certificado que utilizo no es valido, aunque OVH me dice que esta correctamente instalado y compatible con redsys ....
Si has conseguido solucionar tu problema, me podrías ayudar??
Gracias!

alvaroag
13/06/2016, 01:10
Agrégame a Skype. Hoy no estoy seguro que pueda ayudarte, pero mañana si.

Saul Goodman
12/06/2016, 21:07
Buenas de nuevo y gracias por contestar.

Como bien indicas y después de tropocientos mensajes a redsys y ovh me informaron de que el problema es el protocolo SNI así que la única opción que me ha quedado es migrar a un VPS con Centos 6 y Plesk, comprar un certificado SSL externo y configurármelo en el VPS... el problema ahora es el siguiente:

Uso Prestashop con pasarla de pago de Redsys y el problema que hay es que Redsys sólo soporta servidores que trabajen únicamente con protocolo TLS 1.0. He probado a desactivar SSL3, SSL2, TLS1.1 y TLS1.2 con multidud de guías : http://kb.odin.com/es/123160 pero desde https://www.ssllabs.com/ssltest/analyze.html siempre me marca como activo TLS1.1 y TLS1.2

¿alguien prodría hecharme una mano?

alvaroag
09/06/2016, 18:57
La prueba más simple y concluyente que puedes hacer, para descartar cualquier fallo por parte de OVH, es entrar tú mismo a tu web, con protocolo HTTPS. No deberías tener ninguna advertencia de seguridad, con ningún navegador. Con eso ya descartaste problemas de DNS, de servidor web, y de HTTPS.

Entiendo que el servidor de RedSys, en algún momento del proceso, realiza una llamada por HTTPS a tu servidor, supongo que para entregar el resultado de la transacción de manera asincrónica. En ese caso, sí que podemos estra frente a un problema. Las aplicaciones de bancos y empresas del mundo financiero son, por lo general, antiguas; y, al igual que un navegador antiguo, es posible que no soporten SNI (Server Name Indication).

Vayamos a la historia y funcionamiento del HTTPS para entender que es SNI. HTTPS, más que un protocolo, es el mismo HTTP, pero dentro de un canal encriptado. Esa encriptación requiere un certificado que indica las direcciones (hosts o dominios) para los que es válido; ese host, a su vez, tendría que coincidir con la cabecera "Host" del protocolo HTTP. El problema viene cuando vemos que la negociación del canal seguro(SSL) ocurre antes de que haya transmisión de cabeceras de solicitud HTTP, por lo que, en el momento de la negociación SSL, el servidor no conoce cual es el host o dominio que el cliente requiere. Como primera solución a esto, se acostumbró alojar los sitios HTTPS con IP exclusiva por host, haciendo que el servidor se identificara siempre con el mismo certificado según la IP a la cual había recibido la conexión, pues cada IP aloja un sólo sitio. Pero claro, eso es poco eficiente en cuanto al uso de IPs, más aún cuando el espacio IPv4 está casi agotado.

Para eso se creó SNI, una extensión del SSL que permite que el navegador envíe, durante la negociación SSL, el mismo valor que enviará más tarde en la cabacera "Host". De esta manera, el servidor puede elegir un certificado más adecuado para ese host en particular(o incluso generar uno, que se usa bastante en MITM).

El problema con SNI, aunque no es un problema técnico, es que, como toda tecnología, demora en ser asimilada por algunos fabricantes de software. Los navegadores lo implementaron rápidamente, al igual que varios servidores web, pero, cuando hablamos del mundo financiero, tengo la sospecha que podrían, en muchos bancos de todo el mundo, seguir utilizando librerías de cliente HTTPS que no soportan SNI. Y, cuando un servidor que soporta SNI recibe una conexión SSL sin la extensión SNI, se identifica con un certificado por defecto, generalmente el que corresponde al nombre real del servidor, y que, obviamente, no es válido para tu web(no coincide el host), por lo que falla la conexión segura por que el certificado no es el adecuado.

Ciertamente, los de OVH no se lo pensaron mucho a la hora de darte una respuesta; aunque, viéndolo desde su perspectiva, yo no esperaría que una librería de cliente HTTPS no soportara SNI, considerando que la especificación técnica de SNI fué publicada en 2003, ya hace 13 años. Veo más responsabilidad en los de RedSys, que no informan adecuadamente de ello como un requerimiento técnico.

Solución? Montarlo en un servidor en que sea tu certificado predeterminado. Un VPS puede servir, dale una mirada a los VPS Cloud, que además de la alta disponibilidad, incluyen licencia gratuita de Plesk Web Admin, que podría serte muy conveniente para no preocuparte de la administración del sitio. El certificado emitido por OVH no lo puedes montra en tu servidor, pero puedes utilizar Let'sEncrypt, que te genera certificados gratuitos.

macklus
09/06/2016, 14:59
Hola!

Te mensaje es muy raro, y si no nos das más información, malamente te podremos ayudar.

Hacer un dig a la IP no tiene sentido para comprobar un SSL, y seguramente el único problema sea que la zona DNS aún no se ha propagado. O nos dices el nombre de dominio, o nos pegas la respuesta de RedSys (que lo siento mucho, pero tienen tela...)

Saludos!

Saul Goodman
06/06/2016, 20:58
Buenas noches,

Recurro al foro ya que desde soporte me vienen copypasteando las respuestas desde hace una semana.

Mi problema es que contratamos un hosting (el más baratito que hay) para montar una tienda prestashop. Hace dos semanas contratamos el certificado SSL que ofrece OVH (es la única opción que teníamos ya que no podemos contratar un certificado externo) no sin antes abrir un ticket para asegurarnos que el certificado es totalmente compatible con la pasarela de Redsys / BancSabadell. Con el visto bueno por parte de OVH hicimos la compra e instalamos el modulo de Redsys para Prestashop y al hacer las pruebas nos encontramos con que prestashop no genera los pedidos ya que aunque la compra se realiza la URL de respuesta no la acepta Redsys por calificarla de insegura.
Total, que abrimos un ticket a Redsys para explicarles lo que ocurría y estos nos contestaron que el dominio no se encuentra correctamente instalado ya que al hacer un dig a la IP de nuestro dominio da un "Unable to connect" con lo que pasaron la pelota a OVH con este argumento... pues bien hacemos lo mismo explicando a OVH lo que nos dice Redsys y su respuesta es de que; "El dominio está correctamente instalado, le hemos hecho un dig, wget al dominio y resuelve correctamente. Pruebe a contactar con su webmaster para ver si hay algún problema con la zona DNS"....
Y así hasta en 4 ocasiones hasta que he decidido consultar en el foro a ver si alguien me arroja un poco de luz ya que no entiendo:
  • En primer lugar, si el hosting, dominio y certificado se contrataron con OVH y la instalación fue a cargo de ellos ¿por qué recae sobre mi la responsabilidad de arreglar algo que ellos han instalado mal?
  • Si Redsys me está diciendo y demostrando que la IP no resuelve correctamente el certificado, ¿por qué OVH ignora este comentario y me vuelve a soltar que el nombre de dominio a través de esa IP resuelve correctamente?
  • No veo por el foro a nadie con ése problema, ¿soy la única persona que ha contratado un TPV de Redsys y lo ha conjugado con un certificado SSL de OVH en un hosting web?
  • ¿POr qué ha decaído tanto el soporte de OVH? hace 2 años no se parecían tanto a 1&1