Unexpected 10 seconds delay if TlsHostCertificateFingerprint is different

Hello,
I'm using WinSCP 6.5.1 COM Automation to access a FTPS server.
I found that during the session initialization, after the TLS handshake, if the given TlsHostCertificateFingerprint is wrong, WinSCP waits 10 seconds before sending an error "Peer certificate rejected. Disconnected from server. Connection failed.", without exchanging any data with the server meanwhile.
I think it should abort immediately after receiving the server certificate, without waiting 10 seconds.

Please attach a full session log file showing the problem (using the latest version of WinSCP).

Hello, thank you for your reply !
I attached the requested log.
It seems that there is an interactive question that shouldn't be here, as WinSCP is called using COM automation.

Thanks for the log.

I have added this issue to the tracker:
Issue 2384 – Do not offer certificate verification in scripting if configuration is not persistent
You can vote for it there.

Hello,
I added my vote !

Indeed, I think that :

1) scripting should not have interactive behaviour : in this case, the question doesn't even show up, we just have a 10 seconds wait and can do nothing in script...
2) if a fingerprint IS NOT provided and we don't GiveUpSecurityAndAcceptAny, WinSCP should look in Certificate Store and give an immediate error (without 10 s wait) if no valid certificate is found
3) if a fingerprint IS provided, WinSCP should not even look in Certificate Store : if server certificate doesn't match the given fingerprint, WinSCP should just immediately give an appropriate error.

That way, our scripts using WinSCP are efficient and have a consistent behaviour.

Many thanks for all your great work and for your time in this forum !

A 10-second delay occurs when TlsHostCertificateFingerprint doesn’t match, due to the client retrying before failing the TLS handshake.