mbedtls: allow storing certificates in filesystem

[facchinm]

Summary of changes

This patch adds TLSSocketWrapper::set_root_ca_cert_path to allow using a (filesystem) path instead than an xxd generated array to store CA certificates.
If filesystem support is enabled in mbed_config.h or systemwide we try invoking mbedtls_x509_crt_parse_path which returns the number of certificates it was able to parse (or < 0 if it failed).

Impact of changes

Migration actions required

Documentation

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[x] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@facchinm, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[Patater]

Why not add a new nsapi_error_t TLSSocketWrapper::set_root_ca_cert(const char *root_ca_path) method? I believe we are OK with that sort of API extension. As is, it seems pretty awkward to use the buffer passing method with a length of 0 to mean look it up in the filesystem unless you have MBEDTLS_FS_IO disabled in which case use it as a buffer actually.

Also, this will need tests added before we could accept this sort of PR.

[facchinm]

@Patater you are right, it was quite awkward. But the overload nsapi_error_t TLSSocketWrapper::set_root_ca_cert(const char *root_ca_path) is already there and requires a \0 terminated string ca_cert array (which is exactly the same API with automatic length).
I reimplemented using set_root_ca_cert_path as signature, is it better? Adding the tests later today

[facchinm]

@Patater I added both a unit test and a greentea test. Should the dependency on MBEDTLS_FS_IO in the latter be moved one level up (like here )? Anything else I can do?

[jeromecoutant]

Ping

[0xc0170]

@ARMmbed/mbed-os-security Can you please review?

[jeromecoutant]

@0xc0170 maybe we can start CI in // ...?

[0xc0170]

CI started

[mbed-ci]

Jenkins CI Test : ❌ FAILED

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-test	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest	❌

[0xc0170]

@facchinm I think it will be better to create a new feature request for updating tls to 3.0, I am not aware of any plans to update for this new major version (this version contains the fix required here).

I'll close this pull request for now.