[erlang-questions] SSL Out of Order Cert Chain Question (9.2)
Michael Viveros
michaelviveros@REDACTED
Wed Feb 19 23:18:40 CET 2020
OTP-22.2 fixed certificate chains with out-of-order certificates but
certificate chains with duplicate certificates still don't work. Duplicate
seems like a subset of out-of-order and I've seen quite a few endpoints
with duplicate certificates so could we fix this as well?
Here's an example using the host inputs.alooma.com:
$ openssl s_client -connect inputs.alooma.com:443
...
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.alooma.com
i:/C=US/O=Google Trust Services/CN=GTS CA 1O1
1 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.alooma.com
i:/C=US/O=Google Trust Services/CN=GTS CA 1O1
2 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
$ erl
Erlang/OTP 22 [erts-10.6] [source] [64-bit] [smp:4:4] [ds:4:4:10]
[async-threads:1] [hipe]
Eshell V10.6 (abort with ^G)
1> c(ssl).
Recompiling
/Users/mviveros/.asdf/installs/erlang/22.2/lib/ssl-9.5/src/ssl.erl
{ok,ssl}
2> ssl:start().
ok
3> ssl:connect("inputs.alooma.com", 443, [{cacertfile,
"/etc/ssl/cert.pem"}, {reuse_sessions, false}, {server_name_indication, "
inputs.alooma.com"}, {verify, verify_peer}, {depth, 99}]).
=NOTICE REPORT==== 19-Feb-2020::17:16:43.559370 ===
TLS client: In state certify at ssl_handshake.erl:1768 generated CLIENT
ALERT: Fatal - Handshake Failure
- {bad_cert,invalid_key_usage}
{error,{tls_alert,{handshake_failure,"TLS client: In state certify at
ssl_handshake.erl:1768 generated CLIENT ALERT: Fatal - Handshake Failure\n
{bad_cert,invalid_key_usage}"}}}
On Thu, Nov 21, 2019 at 5:00 PM Michael Viveros <michaelviveros@REDACTED>
wrote:
> Heard back from Ingela and she confirmed it will be part of OTP-22.2 and
> OTP-23.0 as opposed to being a patch to OTP-21 (since it's not a
> vulnerability or critical bug).
>
> On Wed, Nov 20, 2019 at 9:22 PM Michael Viveros <michaelviveros@REDACTED>
> wrote:
>
>> Any update about next steps, Ingela?
>>
>> On Tue, Nov 12, 2019 at 5:47 PM Michael Viveros <michaelviveros@REDACTED>
>> wrote:
>>
>>> Just confirmed your fix worked!
>>>
>>> On Mon, Nov 11, 2019 at 6:16 PM Michael Viveros <
>>> michaelviveros@REDACTED> wrote:
>>>
>>>> Great news, thanks Ingela! I tried confirming the fix on my end but I'm
>>>> an Erlang noob so it's taking me awhile, will try again tomorrow.
>>>>
>>>> On Mon, Nov 11, 2019 at 5:17 AM Ingela Andin <ingela.andin@REDACTED>
>>>> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I have a patch that solves the problem. I have pushed it to my
>>>>> gitrepo
>>>>> https://github.com/IngelaAndin/otp/tree/ingela/ssl/unorded-chain
>>>>>
>>>>> I had to set the options {depth, 2} and {customize_hostname_check,
>>>>> [{match_fun, CustomFun}]
>>>>> where CustomFun = public_key:pkix_verify_hostname_match_fun(https) as
>>>>> the peer certificate is a wildcard cert.
>>>>>
>>>>>
>>>>> Regard Ingela Erlang/OTP team
>>>>>
>>>>>
>>>>> Den fre 8 nov. 2019 kl 21:46 skrev Curtis J Schofield <curtis@REDACTED
>>>>> >:
>>>>>
>>>>>> Oh this is wonderful news!! Glad you were able to identify the code
>>>>>> not reached !!
>>>>>>
>>>>>> Deeply appreciate your support and expertise!
>>>>>>
>>>>>> Best,
>>>>>> Curtis
>>>>>>
>>>>>> Sent from ProtonMail Mobile
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 8, 2019 at 12:15 PM, Ingela Andin <ingela.andin@REDACTED>
>>>>>> wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I think I am on to the problem, we have only whitebox tested the
>>>>>> unorded chain functionality (we intend to create a blackbox but that is a
>>>>>> bigger job as we need to find some introp software that can create such
>>>>>> chains or create a simulation modle),
>>>>>> so I am positive I found that we do not reach the code for sorting
>>>>>> the chain. I will try to fix it next week. It is easier now that I at
>>>>>> least I got a server that I can manually blackbox test with :)
>>>>>>
>>>>>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>>>>>
>>>>>> Den tors 7 nov. 2019 kl 20:53 skrev Ingela Andin <
>>>>>> ingela.andin@REDACTED>:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> Den tors 7 nov. 2019 kl 19:35 skrev Michael Viveros <
>>>>>>> michaelviveros@REDACTED>:
>>>>>>>
>>>>>>>> Hi Ingela,
>>>>>>>>
>>>>>>>> Curtis' example server from his first message, hooks.glip.com,
>>>>>>>> presents its certificates out-of-order. The correct order is Peer ->
>>>>>>>> Intermediate CA 1 - > Intermediate CA 2 -> Root CA but they get presented
>>>>>>>> as Peer -> Root CA -> Intermediate CA 2 -> Intermediate CA 1 and this
>>>>>>>> returns the "Unknown CA" error. You can confirm this by running `openssl
>>>>>>>> s_client -connect hooks.glip.com:443`.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes I agree that this is an out of order chain, in contrast to the
>>>>>>> social.fluffel.io. I will look into it at work tomorrow.
>>>>>>>
>>>>>>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Thu, Nov 7, 2019 at 1:23 PM Curtis J Schofield <curtis@REDACTED>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Ingela
>>>>>>>>>
>>>>>>>>> Thank you for your attention- perhaps Micheal can explain this
>>>>>>>>> better..
>>>>>>>>>
>>>>>>>>> Sent from ProtonMail Mobile
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 7, 2019 at 6:55 AM, Ingela Andin <
>>>>>>>>> ingela.andin@REDACTED> wrote:
>>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> I tried this out and it is not out of order, it sends the peer
>>>>>>>>> cert followed by the intermediate cert repeated, that is the chain looks
>>>>>>>>> like [Peer, CA1, CA1].
>>>>>>>>> Looking at TLS-1.3 RFC it looks like extra certs should ignored
>>>>>>>>> too, so I suppose we need to add that.
>>>>>>>>>
>>>>>>>>> Regards Ingela Erlang/OTP team - Ericsson AB
>>>>>>>>>
>>>>>>>>> Den lör 2 nov. 2019 kl 15:24 skrev Mark Reynolds <beastie@REDACTED>:
>>>>>>>>>
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>> I confirm that out of order certs does not seems to be fixed, and
>>>>>>>>>> it fails with 'Unknown CA' error:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> iex(2)> :hackney.get("https://social.fluffel.io")
>>>>>>>>>> {:error,
>>>>>>>>>> {:tls_alert, {:unknown_ca, 'received CLIENT ALERT: Fatal -
>>>>>>>>>> Unknown CA'}}}
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> the only issue with this server TLS certificates is the chain
>>>>>>>>>> order (CA is Letsencrypt):
>>>>>>>>>> https://www.ssllabs.com/ssltest/analyze.html?d=social.fluffel.io
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Nov 2, 2019, at 01:12, Curtis J Schofield wrote:
>>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> Just curious if there is an update on out of order certs.
>>>>>>>>>>
>>>>>>>>>> The example has id0, id1, id2, id3 certs with id1 being the
>>>>>>>>>> natural
>>>>>>>>>> root of id2 who is the root of id3, who is the root of id0.
>>>>>>>>>>
>>>>>>>>>> We can correct the out of order problem by including id1,id2,id3
>>>>>>>>>> certs
>>>>>>>>>> in our chain.
>>>>>>>>>>
>>>>>>>>>> It would be nice to hear from the erlang maintainers around what
>>>>>>>>>> kind of
>>>>>>>>>> "out of order" erlang can handle nicely and if there is planned
>>>>>>>>>> support for
>>>>>>>>>> our case!
>>>>>>>>>>
>>>>>>>>>> Thank you again,
>>>>>>>>>>
>>>>>>>>>> Curtis.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sent through ProtonMail <https://protonmail.com> Encrypted Email
>>>>>>>>>> Channel.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>> On Saturday, October 19, 2019 4:34 PM, Curtis J Schofield
>>>>>>>>>> <curtis@REDACTED> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi! Thank you.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I included the root cert in the example. The root cert is id1 in
>>>>>>>>>> cert chain - this is evident in the other file.
>>>>>>>>>>
>>>>>>>>>> It seems because the root cert is out of order - the cert chain
>>>>>>>>>> is invalid - IIRC this may be true for tls1.2 - however the negotiation is
>>>>>>>>>> at TLS1.2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you for your consideration!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sent from ProtonMail Mobile
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Oct 19, 2019 at 10:51 AM, Ingela Andin <
>>>>>>>>>> ingela.andin@REDACTED> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> "Unknown CA" means that you did not have the ROOT certificate of
>>>>>>>>>> the chian in your "trusted store" (cacerts option).
>>>>>>>>>> If you do not own the ROOT certificate you can not trust the
>>>>>>>>>> chain.
>>>>>>>>>>
>>>>>>>>>> Regards Ingela Erlang/OTP Team - Ericsson AB
>>>>>>>>>>
>>>>>>>>>> Den fre 18 okt. 2019 kl 21:52 skrev Curtis J Schofield
>>>>>>>>>> <curtis@REDACTED>:
>>>>>>>>>>
>>>>>>>>>> Dear Erlang Questions:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SSL 9.0.2 mentions a patch to fix out of order cert chains
>>>>>>>>>>
>>>>>>>>>> In SSL 9.2 we have a root CA and an out of order cert chain
>>>>>>>>>> for host hooks.glip.com.
>>>>>>>>>>
>>>>>>>>>> When we try to verify peer with the out of order cert
>>>>>>>>>> chain we get 'Unknown CA'.
>>>>>>>>>>
>>>>>>>>>> Is this expected behaviour for Erlang SSL 9.2 with verify_peer ?
>>>>>>>>>>
>>>>>>>>>> The http://erlang.org/doc/apps/ssl/notes.html#ssl-9.0.2 notes
>>>>>>>>>> mention that other care may need to be taken to ensure
>>>>>>>>>> compatibility.
>>>>>>>>>>
>>>>>>>>>> Reproduce error:
>>>>>>>>>>
>>>>>>>>>> https://github.com/robotarmy/out-of-order-ssl
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Curtis and Team DevEco
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sent through ProtonMail Encrypted Email Channel.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> erlang-questions mailing list
>>>>>>>>>> erlang-questions@REDACTED
>>>>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200219/ea8a75de/attachment-0001.htm>
More information about the erlang-questions
mailing list