Fix CA override functions

[graebm]

Update to awscrt 0.12.0. This fixes the issue where "override_default_trust_store" functions did not actually override the system trust store on Linux and Apple platforms.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[rtylecek]

This commit has broken authentication on aarch64 platform (tested on L4T 32.5.1).
Call to connect() after mqtt_connection_builder.mtls_from_path() fails with
AWS_IO_TLS_ERROR_NEGOTIATION_FAILURE
Downgrade to 1.6.2 fixed the problem. There must be some underlying issue with awscrt 0.12.0.

The problem does not seem to affect x86_64 platform.

[bretambrose]

This commit has broken authentication on aarch64 platform (tested on L4T 32.5.1).
Call to connect() after mqtt_connection_builder.mtls_from_path() fails with
AWS_IO_TLS_ERROR_NEGOTIATION_FAILURE
Downgrade to 1.6.2 fixed the problem. There must be some underlying issue with awscrt 0.12.0.

The problem does not seem to affect x86_64 platform.

I made an effort to reproduce this, reproed it, and then after some thought, realized what I was doing wrong, and then potentially where you may be making a mistake.

I started off with a custom ca, registered it with iot, then generated and registered a device certificate with iot and attempted to use that device certificate with the pubsub sample. I got a tls negotiation error, but after looking further I realized you don't pass in the custom CA as the root CA. Previously, this would work since the real root CA for the iot endpoint is AmazonRootCA1.pem which is in the default trust store of your machine. The buggy version which we corrected was unioning the rootCA you provide on the command line with the system trust store. You could then connect fine even though you were providing a rootCA which is not the root of the iot endpoint.

Now that we've fixed the incorrect unioning, providing anything other than the IoT endpoint's root CA as the connection's root CA is going to fail since now override_root_ca is genuinely an override that completely replaces the system trust store.

The easy fix (assuming your problem matches what I recreated) is to not supply a root CA or supply AmazonRootCA1.pem.

I can see (especially since I was) how it can be easy to confuse the rootCA supplied to make a tls connection with custom CAs for device certificates. But they key point is, the root CA you supply on the connection is to validate the server's certificate that it sends down. That certificate does not change and is completely unaffected by what the root of your device certificate is.