OpenSSL s_client: el 403 del proxy llega antes del TLS del destino
Interpreta un 403 de CONNECT a través del proxy de OpenSSL como un fallo de la etapa de túnel y no diagnostiques el certificado del destino a partir de un handshake que nunca empezó.
Si openssl s_client recibe un HTTP 403 como respuesta a su solicitud CONNECT al proxy, empieza por ese rechazo. El túnel solicitado no se ha establecido.
Con -proxy, s_client pide primero al proxy HTTP que se conecte al destino indicado por -connect. Solo una respuesta CONNECT correcta convierte ese intercambio en un túnel para el handshake TLS del destino.
Este orden explica una salida que de otro modo resulta confusa: un error del proxy seguido de encabezados relacionados con TLS, ningún certificado del par o una línea de verificación aparentemente tranquilizadora. Esos campos no demuestran que el certificado del destino se haya recibido y verificado. La operación se detuvo en una etapa anterior.
Anota la respuesta del proxy y el host y el puerto de destino solicitados. Un 403 dirige la atención hacia la decisión de acceso del proxy; un 407 pide autenticación en el proxy. Ninguno de los dos se arregla desactivando la verificación del certificado del destino.
Cuando se permite inspeccionar el intercambio, la salida -debug de s_client puede ayudar a exponer el rechazo. Mantén cualquier credencial del proxy fuera de las trazas compartidas. Un túnel correcto seguiría necesitando después su propia evaluación de TLS y de certificados, pero no hay ninguna cadena de certificados de destino que diagnosticar hasta que se haya alcanzado realmente esa etapa.