Behavior Change in ssl:connect/3 Between Erlang OTP 25 and OTP 26/27

[dergraf]

Describe the bug

The behavior of the ssl:connect/3 function has changed between Erlang OTP 25 and OTP 26. While the change in the default verify_peer option, replacing the previous verify_none, is well documented, there appears to be an additional, undocumented change. I am unsure whether this is a regression or an intentional feature.

What is concerning is that this issue occurs when connecting to a website from a globally trusted certificate authority (SwissSign in our case), which is assumed to follow best practices in certificate management. This raises a question about whether upgrading from OTP 25 to OTP 26/27 could potentially cause connectivity issues due to this behavior change.

Expected Behavior (OTP 25):

On Erlang/OTP 25 [erts-13.2.2.9], the expected behavior when connecting to www.swisssign.com is as follows:

iex> :ssl.connect(~c"www.swisssign.com", 443, verify: :verify_peer, cacerts: :public_key.cacerts_get())
{:ok,
 {:sslsocket, {:gen_tcp, #Port<0.4979>, :tls_connection, :undefined},
  [#PID<0.23807.5>, #PID<0.23806.5>]}}

This results in a successful connection, as expected.

Actual Behavior (OTP 26/27):

On Erlang/OTP 26 [erts-14.2.5.5] and Erlang/OTP 27 [erts-15.2], the same connection attempt produces the following error:

iex> :ssl.connect(~c"www.swisssign.com", 443, verify: :verify_peer, cacerts: :public_key.cacerts_get())
{:error,
 {:tls_alert,
  {:unsupported_certificate,
   ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2158 generated CLIENT ALERT: Fatal - Unsupported Certificate\n {key_usage_mismatch,{{'Extension',{2,5,29,15},true,[keyCertSign,cRLSign]},
                      {'Extension',{2,5,29,37},
                                  false,
                                  [{1,3,6,1,5,5,7,3,1},
                                    {1,3,6,1,5,5,7,3,2}]}}}"}}}

The same error is also seen in OTP 27, with the only difference being a slightly different line number:

iex> :ssl.connect(~c"www.swisssign.com", 443, verify: :verify_peer, cacerts: :public_key.cacerts_get())
{:error,
 {:tls_alert,
  {:unsupported_certificate,
   ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2199 generated CLIENT ALERT: Fatal - Unsupported Certificate\n {key_usage_mismatch,{{'Extension',{2,5,29,15},true,[keyCertSign,cRLSign]},
                      {'Extension',{2,5,29,37},
                                   false,
                                   [{1,3,6,1,5,5,7,3,1},
                                    {1,3,6,1,5,5,7,3,2}]}}}"}}}

Additional Context:

A potential related issue exist #9208, but this issue reports that OTP 26 is working.
I've discovered the new connect option allow_any_ca_purpose (I think introduced in #9130 ) which I tried to set to true on both 26 and 27 cases, returning the exact same error.

Questions:

• Is this change in behavior intentional as part of the SSL/TLS improvements in OTP 26/27?
• If it’s a regression, could this issue be fixed to restore compatibility with trusted certificate authorities like SwissSign?
• What steps should be taken to ensure that systems relying on globally trusted certificate authorities can safely upgrade from OTP 25 to OTP 26/27?

[IngelaAndin]

I think this is related to #9286 However I am not sure if should be fixed like this or in ssl applications own verify fun yet. Under investigation.

[IngelaAndin]

I will close this one in favor of #9208 as I believe they are the same and that one was first. Solution is coming as I said with #9286 but still waiting for team review and decision on final solution.