SSL connection issue

Unfortunately don’t work for me, there are some another issue persists. Using wrapped curl for now

I was having this same problem. The solutions provided here worked if you’re using a weak encryption AES128 but does not work for AES256.

HTTPoison supports the full list of SSL supported by erlang’s ssl. To get HTTPoison to work correctly with ssl specify the options like this.

HTTPoison.get! “https://google.com”, , [ssl: [ciphers: [“ECDHE-ECDSA-AES128-SHA256”,“ECDHE-ECDSA-AES128-SHA”]]]

that should solve the problem.

That’s actually useful, thanks!
openssl says all good, 1st one (out of 3 bundled) is personal and others are intermediate (which is expected).
And of course i’ve tried it this way, always getting handshake failure - malformed_handshake_data as a response. I fear the root is deeper, maybe some misbehaving elliptic curve or something like that, and that’s not distro-dependent (tried various OSes, erlang versions, including 18.x). It wastes way too much time

You can verify each of the PEM certificates by copy & pasting them (one at a time) into openssl x509 -text -noout: presumably if something is wrong with the PEM file contents, OpenSSL would also throw an error. In the output, note the subject and issuer, so you’ll know which PEM certificate is which, i.e. which one needs to be referenced from certfile and which ones need to go in the CA store.

The server tells me (when connecting using openssl s_client -connect api.searchads.apple.com:443) that it expects a client certificate that can be traced back to one of these root CAs:

Acceptable client certificate CA names
/CN=Apple Corporate Root CA/OU=Certification Authority/O=Apple Inc./C=US
/CN=Apple Corporate External Authentication CA 1/OU=Certification Authority/O=Apple Inc./C=US

Presumably the intermediate CAs linking your end-certificate to one of these root CAs are in the PEM file.

I can’t remember if I ever tried using the ssl_verify_fun package myself, but I have tried Erlang/OTP 20’s built-in :public_key.pkix_verify_hostname and it seems to work as advertised:

https://blog.voltone.net/post/11

I agree, even after looking at and trying to replicate hackney’s implementation for SSL connections, I still can’t get SSL connections working correctly.

It’s absolutely mind-boggling how crazy it is to establish a client SSL connection.

Thanks for the tip.
The most powerful, flexible, counterintuitive and illogical ssl implementation i’ve encountered.
providing cacerts as cacerts: [cert1, cert2] doesn’t work either, producing the same SSL WARNING: Ignoring a CA cert as it could not be... warning per line + handshake failure or reason: :closed
:public_key.pem_decode works just fine, producing parsed data. tried some other formats - no luck as well.

At this moment i gave up and just wrote wrapper which uses curl . Thanks everyone!

Instead of using the :cacertfile use the :cacerts option.

cert1 = File.read!("path/to/cert1.pem") |> :public_key.pem_decode
cert2 = File.read!("path/to/cert2.pem") |> :public_key.pem_decode

cacerts = [cert1, cert2]

SSL in Erlang is the most confusing thing ever.

Thank you, that could be the reason. Certificate contains 3 CERTIFICATE sections. Playing with it atm.
No progress so far though

... [ssl: [keyfile: "some.key", certfile: "cert-1.pem",  cacertfile: "certs-1,3.pem", ciphers: [{:rsa, :aes_128_gcm, :null, :sha256}], versions: [:"tlsv1.2"]]])

# cert 1
[error] SSL: :certify: tls_connection.erl:715:Fatal error: handshake failure - malformed_handshake_data
{:error, %HTTPoison.Error{id: nil, reason: {:tls_alert, 'handshake failure'}}}
# cert 2 and 3
[info] [83, 83, 76, 32, 87, 65, 82, 78, 73, 78, 71, 58, 32, 73, 103, 110, 111, 114, 105, 110, 103, 32, 97, 32, 67, 65, 32, 99, 101, 114, 116, 32, 97, 115, 32, 105, 116, 32, 99, 111, 117, 108, 100, 32, 110, 111, 116, 32, 98, 101, ...]
{:error, %HTTPoison.Error{id: nil, reason: :closed}}

decoded numbers: SSL WARNING: Ignoring a CA cert as it could not be (probably ends with correctly decoded)
Probably i’m not doing something right, just extracted one section to separate file and included other two as cacert.
Looks like it’s correct direction to dig in, thanks @voltone

P.S. cURL’s cacert bundle didn’t help as well

This is a bit of a long shot, but… the server requires a client certificate, and I’ve seen lots of unhelpful alert responses and log messages when things go wrong with client certs.

Does the client certificate include an intermediate cert? The way Erlang builds the chain of certs that is sent to the server is a bit different from some other tools. Instead of just sending all the certificates it finds in the PEM file, it expects to find just the end-certificate in there. It then scans the cacerts file (the same one that holds the trusted roots for verifying the server) for any intermediates that can be chained to it.

So, if the client cert file does indeed contain more than one cert, did you copy the intermediate CAs to the cacerts file?