> I went through the capture between the app (local end) and the proxy. It appears that the sequence is:
>
> ClientHello -> (from app to proxy, with a ton of cipher suites, including 0xc02f)
> <- ServerHello (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 – present in ClientHello)
> <- CertificateServer Key Exchange, Server Hello Done (includes proxy’s cert rather than the remote end’s cert)
>
> Alert (Level: Fatal, Description: Certificate Unknown) ->
>
> So it appears that the app expects the remote end’s cert, and is not happy getting the proxy’s cert instead?
Please report tshark output, not an approximate rendition. In what direction
is the alert sent?
I’m using WireShark. The IP addresses on the Alert packet show local host as the source, and the proxy as the destination. Is there another way to tell the direction? Or how to present it in a way that I can sanitize the output and post here?
In response to this Alert packet I see two packets from the proxy to the local host:
- [ACK]
- [PSH, ACK]
And then from the local host to the proxy:
- [FIN, ACK]
- [RST]
- [RST]
It is indeed possible that the application is not configured for and correctly
rejects the forged certificate of the MiTM proxy. It would need the Root CA
of the proxy as a trusted issuer, but that may not be configurable. In which
case you'd need to let the app connect directly to the remote server without
an MiTM-proxy.
Understood, thanks!
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
