A handshake error cannot be simply ignored and continued with the connection. It is like asking that a car simply continues to drive after a fatal crash.
With a handshake error the current connection is in a state where there is no common ground between client and server to continue with the handshake, like they find no shared ciphers, no shared protocol version or the other site has simply closed the underlying TCP connection.
This is different from errors with certificate validation where the side which does the validation (i.e. client in case of server certificates) might decide to ignore these validation problems and continue with the handshake (but now risk man in the middle attacks).
Modern browsers can't access it because it uses ancient ciphers.
This is likely the same problem nginx is facing. "Supported ciphers" is like the languages each side speaks. Communication will fail if they find no common language to talk with each other.
Such a problem of not understanding each other can obviously not be simply ignored. Instead haproxy would need to be configured to support ciphers and protocols which are also supported by the upstream. Depending on how broken the upstream is in terms of protocol support this might be simply done by tuning the ciphers and ssl-min-ver settings. In some cases (really old broken stacks) it might the ancient protocol versions or ciphers needed might not be compiled into haproxy though, so recompiling of openssl and haproxy with support for such old stuff would be needed.