Hi Hanno,
Could certs.c live in `tests/data_files`?
I don't have a strong opinion about that. Actually we could even have multiple such files for different uses cases, living in different places (for example one in programs/ssl, one in tests/suites, I'm not saying this makes sense, just that we could). Or for each cert and key that we have in `tests/data_files`, we could have a companion `foo.crt.h` file that contains just the data for this file (with an appropriate naming convention). This could for example be useful to modify `test_suite_x509parse` to run usefully on targets that do now have a filesystem - again I'm not saying this would be the best approach, just throwing out ideas.
We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past.
Unless I'm mistaken, this script is only present in the baremetal branch so far and hasn't been upstreamed yet (partly due to questions about its implementation language): https://github.com/ARMmbed/mbedtls/pull/2596
But I strongly agree this or these files should be generated (and automatically checked to be up-to-date). Actually, I think we should even provide a general-purpose script (and/or python module) for generating a C version of a certificate. There are several workflows where you want to embed certificates in an application (for example a list of trusted CAs) and too often I've seen people embedding a PEM representation of a certificate, which is the easiest thing to do but is a waste of resources: not only because the cert data itself is larger that way, but because you then need to include PEM_C and BASE64_C in your config, which your probably wouldn't need otherwise. I can only guess that one of the reasons is because PEM looked easy and people didn't always know there was a better way - if we provided a convenient script to generate suitable data (from a certificate in any format), it would probably help with that.
(By the way when I say "people" that includes us: before the baremetal branch we couldn't run (non-PSK) SSL tests without adding BASE64+PEM to the config. We still can't in the upstream branch - unless you count programs/ssl/mini_client.c, which has a hand-generated, hence probably outdated, copy of test-ca2.crt embedded.)
Regards, Manuel.