[erlang-questions] SSL Out of Order Cert Chain Question (9.2)

Ingela Andin ingela.andin@REDACTED
Mon Mar 2 11:28:53 CET 2020


We will be fixing it , but it is not considered top priority. If you feel
it is a top priority to you PR are always welcome.

Regards Ingela Erlang/OTP team - Ericsson AB

Den mån 24 feb. 2020 kl 16:01 skrev Michael Viveros <
michaelviveros@REDACTED>:

> Any update?
>
> On Wed, Feb 19, 2020 at 5:18 PM Michael Viveros <michaelviveros@REDACTED>
> wrote:
>
>> 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/20200302/460d6ea9/attachment.htm>


More information about the erlang-questions mailing list