Hola. Aquí el pesao del SSL..... El error que da con curl depende de la versión de openssl no del certificado. Desde mi máquina con OpenSSL 1.1.1d me da error : curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
Y desde mi máquina pero con docker y una debian 9 y la versión de OpenSSL 1.1.0l funciona. Voy a ver que diferencia hay entre versiones de openssl que da error con este certificado On Mon, 27 Apr 2020 at 16:43, Jose Legido <[email protected]> wrote: > > > On Mon, 27 Apr 2020 at 13:57, elle_flane <[email protected]> wrote: > >> ok, a mi tambien me parecía el tema gravísmo, >> >> pero hay que descartar el error por tema de certificado. >> > Hola. > Yo creo que el "problema" del certificado es con let's encrypt. > El certificado solo tiene CA y certificado, pero let's encrypt deltro de > la CA pone una CA y una subCA. El navegador lo separa, pero con openssl o > curl no lo hace. > Dicho esto, creo que el certificado está bien. Es decir, si llegas a la IP > y te da el de let's encrypt, es correcto. > > El misterio que me queda por resolver es lo de allot.com, me gustaría > saber un caso que le pase. > > > >> Tampoco lo entendía. >> >> El propio hosting puede emitir un certificado, porque no emite un >> certificado válido? >> >> Podeis explicar hacer una mini explicación de como funcionan los >> certificados quien los regula? >> >> >> Los certificados los da letsencrypt (o la CA que sea) validando que tu > eres el propietario del dominio. Si lo hacen bien, consultarán el DNS en tu > DNS principal, así es imposible suplantar la personalidad. > > >> Gracias, elle >> >> >> El 27/04/20 a les 10:25, Jose Legido escribió: >> >> Hola. >> Si os parece usamos este hilo de los 3 para mirar el problema. A mi me >> interesa mucho entenderlo. >> Yo creo que el bloqueo es solo de DNS, pero si que es verdad que algo >> pasa con el certificado. >> Una vez resuelto el problema de DNS poniendo la IP en /etc/hosts me >> descargo el certificado correcto. >> Es el mismo para los dos dominios aunque cambia el nombre >> openssl s_client -showcerts -servername www.womenonweb.org -connect >> 67.213.76.19:443 -prexit >> openssl s_client -showcerts -servername womenonweb.org -connect >> 67.213.76.19:443 -prexit >> >> La web womenonweb.org redirije a www.womenonweb.org. Si lo grabo en un >> fichero certificado.txt (desde BEGIN CERTIFICAT a END CERTIFICATE) >> Le pongo -L para que siga el redireccionamiento: >> curl -L --cacert certificado.txt https://womenonweb.org >> Me da este error: >> curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong >> signature type >> >> Que es el mismo que si voy directamente a la web final: >> curl -L --cacert certificado.txt https://www.womenonweb.org >> >> Yo en ningún caso veo el certificado que decís de allot.com y me >> gustaría entender en que casos aparece. >> >> Cuando accedo por el navegador añade una CA de "DST Root CA X3" pero la >> CA de let's encrypt y el certificado de www.womenonweb.org son correctos. >> >> En resumen, me gustaría saber si en el algún caso este comando devuelve >> un certificado diferente que el de womenonweb: >> openssl s_client -showcerts -servername www.womenonweb.org -connect >> 67.213.76.19:443 -prexit >> >> Salut >> >> >> On Mon, 27 Apr 2020 at 03:28, fadelkon <[email protected]> wrote: >> >>> Creo que están filtrando por el SNI (server name indication) >>> >>> El 27/4/20 a les 1:49, fadelkon ha escrit: >>> > El 27/4/20 a les 0:19, Jose Legido ha escrit: >>> >> Si de línea de comandos hacen esto: >>> >> openssl s_client -connect 67.213.76.19:443 <http://67.213.76.19:443> >>> >> -prexit >>> >> Tiene que mostrar el certificado original de let's encrypt y >>> >> poniéndose esta línea en /etc/hosts tendrían que poder navegar >>> >> correctamente: >>> >> 67.213.76.19 womenonweb.org <http://womenonweb.org> >>> www.womenonweb.org >>> >> <http://www.womenonweb.org> >>> > Me parece muy interesante. Con openssl (TLS sin nada más) me devuelve >>> el >>> > certificado correcto, con lynx (TLS con HTTP dentro) no. >>> >>> Mirad: >>> >>> > $ openssl s_client -connect 67.213.76.19:443 |& grep issuer >>> > issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >>> >>> Si llamamos el cliente de openssl con la IP, no sabe nada del server >>> name, así que no añade esta "extensión" al Client Hello de TLS >>> (corroborado con wireshark). En cambio: >>> >>> > $ openssl s_client -connect www.womenonweb.org:443 |& grep issuer >>> > issuer=C = ES, ST = Madrid, L = Madrid, O = Allot, OU = Allot, CN = >>> allot.com/[email protected] >>> >>> Si llamamos el cliente por el dominio, a parte de resolverlo a una IP, >>> añade el nombre del servidor al Client Hello de TLS (corroborado >>> también). >>> >>> Creéis que puede ser ésto? >>> Qué os sale a vosotrxs? >>> >>> fdk >> >> >> >> On Mon, 27 Apr 2020 at 03:07, fadelkon <[email protected]> wrote: >> >>> Ey >>> >>> El 27/4/20 a les 3:01, chanchan ha escrit: >>> > he pasado por el correo muy en diagonal. está bien eso de jugar con los >>> > parámetros de red y compartirlos cuando no hay otra cosa >>> > >>> > peeero resulta que ahí fuera hay un supuesto pedazo de herramienta para >>> > analizar la censura desde diferentes puntos y con un montón de datos >>> > llamada ooni >>> >>> Sí, empecé por ooni, pero no da tanta información como una captura de >>> wireshark y pruebas complementarias como el traceroute o abrir un tunel >>> con openssl, como propuso Jose. Aportan infomación adicional muy >>> interesante. >>> >>> fdk >>> >>> _______________________________________________ >>> HackMeeting mailing list >>> [email protected] >>> https://listas.sindominio.net/mailman/listinfo/hackmeeting >> >> >> >> _______________________________________________ >> HackMeeting mailing >> [email protected]https://listas.sindominio.net/mailman/listinfo/hackmeeting >> >> >> _______________________________________________ >> HackMeeting mailing list >> [email protected] >> https://listas.sindominio.net/mailman/listinfo/hackmeeting > >
_______________________________________________ HackMeeting mailing list [email protected] https://listas.sindominio.net/mailman/listinfo/hackmeeting
