ssl_handshake code gives insufficient feedback

Questions / Help
,
1

I changed a configuration in my running Elixir system. I’m now getting a notice (which really seems more like an error or at least warning):

16:52:14.545 [notice] ssl_handshake.path_validation_alert/1:2076 TLS :client: In state :wait_cert_cr at ssl_handshake.erl:2076 generated CLIENT ALERT: Fatal - Handshake Failure
 - {:bad_cert, :hostname_check_failed}

It would be incredibly more helpful if the message indicated the hostname that was causing this problem. Telling me that a hostname check failed, without telling me which hostname, is very unhelpful. I don’t know the typical response codes in Erlang, but somehow including the hostname with the problem is pretty much essential.

I’ve seen similar problems in other ssl issues. Please print more data. Or tell me how to turn on a debug flag that would tell me the host name. (Please be specific - I’m a new Elixir guy and know next to nothing about Erlang.)

I have a similar problem in my production logs which periodically generate groups of logs that:
Jul 02 19:23:19.669 [warn] Description: 'Authenticity is not established by certificate path validation' Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'
This log also fails to tell me anything about the client or certificate with the issue, so I’ve been unable in over a year to find this problem. An error message that simply says “this error occurred” without giving any context, isn’t worth printing. How do I get these errors improved?

I’m on OTP 24.3 if anyone can tell me that a higher version has improved things.

1 Like
2

We can look into including the Server Name Indication into the host name check failed message as an enhancement. If no Server Name Indication is supplied to the client it will default to the first argument to ssl:connect. This will be checked against information provided in the servers certificate.

The warning is no longer part of OTP-26, as you will instead get an error if you do not provide any trusted certs to verify the connection with. If you still want to connect without verifying the servers certificates you can by specify the option {verify, verify_none}.

Previous to that the warning message was somewhat clarified to people not so familiar with TLS. “Server authenticity is not verified since certificate path validation is not enabled. The option {verify, verify_peer} and one of the options ‘cacertfile’ or ‘cacerts’ are required to enable this.”

2 Likes
3

I’d love such an enhancement. I have an application which I would judge quite complicated with many potential connections. If the error messages about connection issues are all just prepared text with no contextual parameters it is literally impossible to figure out where the problem is.

Possible solutions could include phrases like
Fatal - Handshake failure for your_server
or
Authenticity of your_server is not established...
These additions to the error text would at least give us a clue about what server to try connecting with.

If possible please let me know if these get incorporated in an upp-issue, and which issue that is.

Thanks.