Hi jb3,
It would be my pleasure to provide some insight on these items!
1) Why does the server need to load 3 different PEM files ?
2) What is the relationship between those 3 PEM files?
3) What type of certs are those 3 PEM files?
The number three is not fixed! A server has two requirements to load:
1) An "entity certificate" and chain of trust
The "entity certificate" is used to identify the server to clients connecting to it, the cert that signed the "entity cert" (often times an intermediate CA), and all certs in the chain providing a complete chain of trust back to the ROOT CA. The server is NOT REQUIRED to load the ROOT CA because the client is expected to already have a copy in order to validate the server. Root CA's are provided by trusted entities such as GlobalSign, GoDaddy, LetsEncrypt, etc. When setting up a trust chain order does matter as each cert loaded must be able to validate the previously loaded cert in the chain with the only exception being the "entity cert". When loading a cert chain with wolfSSL_CTX_use_certificate_[file | buffer], the file or buffer must be organized with the "entity cert" first followed by the signer of the entity cert followed by the cert that signed that signer and so on up to the last cert in the trust chain. ONLY the Root CA is not required to be loaded but you can load the Root CA too if you wish, the Root CA is the only one that is optional and not required to be loaded.
2) The server must load a private key associated with the "entity certificate" ONLY. No other keys need to be loaded, just the one used when creating the entity certificate. Use wolfSSL_CTX_use_PrivateKey_[file | buffer] to load the private key.
(OPTIONAL ITEM) 3) If the server is validating clients that connect to it (99.9% of all servers do NOT do this) then the server will need to load the ROOT CA only** that ultimately signed the clients certificate chain. This is loaded with wolfSSL_CTX_load_verify_locations.
EXAMPLE:
If you go to https://www.google.com and look at the certificate chain for the website you will see three (again this is not a fixed number, just so happens to be 3 in this case) certificates. The top-most cert being "GlobalSign", the second cert being "Google Internet Authority G3" and the bottom most cert being the "Entity Cert" and it is "www.google.com". (See attached screen shot)
YOUR ITEMS:
So when you call CyaSSL_CTX_load_verify_locations(ctx, "../../BRU-support/wolfssl/wolfssl-3.15.0/certs/ca-cert.pem",0) you are loading the ca that signed the clients certificate chain. This means the server is doing mutual authentication. Again 99.9% of all servers do not do this, we have this as default in our example server because it is the most secure solution. However we are aware that it is not practical for servers such as google to load a cert unique to every phone, laptop, pc, tablet, smart TV, etc in the world that might connect to a google server.
When you call CyaSSL_CTX_use_certificate_file(ctx,"../../BRU-support/wolfssl/wolfssl-3.15.0/certs/server-cert.pem" you are loading the certificate that identifies the server and starts it's trust chain. The client will receive a copy of the certs in server-cert.pem (there are more than one in there) during the TLS handshake and use that chain to validate the server against any Root CA's the client has loaded to use for validating peers. (The client will be calling wolfSSL_CTX_load_verify_locations with ca-cert.pem which is the CA that signed the server-cert.pem chain)
Finally when you call CyaSSL_CTX_use_PrivateKey_file(ctx,"../../BRU-support/wolfssl/wolfssl-3.15.0/certs/server-key.pem" you are loading the private key used when creating the "entity cert" that is in server-cert.pem
4) How would I go about generating my own 3 PEM files using openssl or some other application? For me to do this I think I need to know what type of PEM files they are ... ?
We have examples of using the openssl command line tool in the script <wolfssl-root>/certs/renewcerts.sh You can use those examples to generate your own keys and certs. Those certificates however will only be good for testing. Ultimately if you are looking to stand up your own valid website you will need to use openssl command line tool to create what is called a "certificate signing request" or CSR for short. You would then send that "CSR" to a trusted root provider such as GoDaddy, GlobalSign, LetsEncrypt, etc and they will use your CSR to generate a certificate for you and sign it using their trust chain. This way your website will be trusted by all common browsers (Chrome, IE, FireFox, Safari, etc).
Please let me know if you have any other questions on this subject or if you need clarification on any of my answer above.
Warm Regards,
- Kaleb
** There are cases where servers or clients that send trust chains do not send the entire chain of trust and the other side must then load all certs from the trust chain that were not sent during the connection in addition to the ROOT CA. For example:
If you have a chain for your server where "E" is the entity cert and "A" is the Root CA where A signed B signed C signed D signed E
Now lets assume the server is improperly setup and only loads C->D->E when calling wolfSSL_CTX_use_certificate_[file | buffer] and the client has only loaded "A" using wolfSSL_CTX_load_verify_locations. This connection would fail because the client ends up with a missing link in the chain:
In this scenario the client would have to load both certs "A" and "B" since the server is improperly not sending it's entire trust chain with the only exception being the Root CA.