HTTP SSL error: "Unknown CA"—going down a Rabbit hole. Maybe an asdf Erlang issue?

dogweather

I get this error with both :httpc and HTTPoison.get. Here’s HTTPoison:

iex(1)> HTTPoison.get! "https://grad.tamu.edu/"

22:15:54.179 [notice] TLS :client: In state :certify at ssl_handshake.erl:2138 generated CLIENT ALERT: Fatal - Unknown CA

** (HTTPoison.Error) {:tls_alert, {:unknown_ca, ~c"TLS client: In state certify at ssl_handshake.erl:2138 generated CLIENT ALERT: Fatal - Unknown CA\n"}}
    (httpoison 2.2.0) lib/httpoison/base.ex:451: HTTPoison.request!/5
    iex:1: (file)

Same with this:

iex(1)> :httpc.request(:get, {'https://grad.tamu.edu/', []}, [], [])

22:24:10.836 [notice] TLS :client: In state :certify at ssl_handshake.erl:2138 generated CLIENT ALERT: Fatal - Unknown CA

{:error,
 {:failed_connect,
  [
    {:to_address, {~c"grad.tamu.edu", 443}},
    {:inet, [:inet],
     {:tls_alert,
      {:unknown_ca,
       ~c"TLS client: In state certify at ssl_handshake.erl:2138 generated CLIENT ALERT: Fatal - Unknown CA\n"}}}
  ]}}

.tool-versions:

elixir 1.15.2-otp-26
erlang 26.0.2

I’ve seen this pop up periodically over the years. What’s the root cause?

I’m thinking of making an elixir lib that simply shells out to curl, which has no problems:

$ curl --head https://grad.tamu.edu/
HTTP/2 200
cache-control: private
content-length: 46798
content-type: text/html; charset=utf-8
server: Microsoft-IIS/10.0
x-aspnetmvc-version: 5.2
x-aspnet-version: 4.0.30319
x-powered-by: ASP.NET
date: Wed, 15 Nov 2023 05:20:20 GMT
strict-transport-security: max-age=4294967294

EDIT: I made this dead simple Hex Package.

CurlEx.get!(url)

12 comments

#httpoison #httpc

1 4285 12

2023-11-24 16:48:51 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

D4no0

It seems that the underlying issue is with the certificate chain. You can take a look at this report.

From ssl erlang side, from which all libraries end up doing the request, it seems that erlang is failing to decode the certificate, cases being either the format being bleeding edge or a incorrect ASN.1 definition, which might be the case here.

I would recommend contacting one of their site administrators and inquiring about that, as it seems that this certificate is used for all of their subdomain sites and most probably was generated manually. This is a potential security threat and should be handled on their side ideally instead of using a workaround in the code.

I will do a investigation on why this happens and return here with a more detailed response.

Post #1

voltone

Looks like the server only sends its own certificate, not any intermediary CAs that would allow it to be traced to a trusted root CA. Instead it relies on the client to fetch the intermediate CA(s) from the URL in the Authority Information Access extension. This is supported by browsers and by some CLI tools, but not by Erlang’s ssl. I suspect they would have issues with other non-browser clients too.

For maximum compatibility they should consider adding the trust chain to their server, so it sends all the intermediate CA certificates and the client can complete the trust chain locally without additional network requests.

Post #2

D4no0

I’m not sure about the implementation, however I’ve downloaded the certificate locally and tried to decode it with :public_key.pkix_decode_cert/2 and it failed.

Another issue is for example when using a custom verify_fun, no peer certificate is returned (even though it should be, as you are validating the certificate and chain manually) only {:error, :unknown_ca}

Post #3

voltone

I’m not having any issues decoding the server’s certificate using public_key. The only reason ssl rejects it is because it can’t find that certificate’s issuer (/C=US/O=Internet2/CN=InCommon RSA Server CA 2).

If that certificate were included in the chain sent by the server, then the chain to /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority could be completed and the certificate verification would succeed.

Post #4

D4no0

Strange, I will try it again later, are you using openssl v1 or v3?

Post #5

voltone

Does not matter: OpenSSL is not used by public_key for decoding certificates.

Here is the PEM encoded server certificate, for reference:

Post #6

D4no0

I can confirm that this doesn’t work:

** (MatchError) no match of right hand side value: {:error, {:asn1, {{:invalid_value, 3}, [{:asn1rt_nif, :decode_ber_tlv, 1, [file: ~c"asn1rt_nif.erl", line: 93]}, {:“OTP-PUB-KEY”, :decode, 2, [file: ~c"../src/OTP-PUB-KEY.erl", line: 1233]}, {:pubkey_cert_records, :decode_cert, 1, [file: ~c"pubkey_cert_records.erl", line: 40]}, {:public_key, :pkix_decode_cert, 2, [file: ~c"public_key.erl", line: 522]}, {:elixir, :“-eval_external_handler/1-fun-2-”, 4, [file: ~c"src/elixir.erl", line: 376]}, {:erl_eval, :do_apply, 7, [file: ~c"erl_eval.erl", line: 750]}, {:elixir, :eval_forms, 4, [file: ~c"src/elixir.erl", line: 361]}, {Module.ParallelChecker, :verify, 1, [file: ~c"lib/module/parallel_checker.ex", line: 112]}]}}}
public_key.erl:526: :public_key.pkix_decode_cert/2
iex:2: (file)

I am using erlang 26.1.2, tried both with otp and plain options.

Post #7

voltone

I think you may be trying to call :public_key.pkix_decode_cert on a PEM encoded certificate, but it expect a DER binary. Try one of these:

pem |> :public_key.pem_decode() |> hd() |> elem(1) |> :public_key.pkix_decode_cert(:otp)
pem |> :public_key.pem_decode() |> hd() |> :public_key.pem_entry_decode()

Or try x509 | Hex for a convenient high-level API for working with certificates and other PKI data structures…

Post #8