Is there an example of using https rather than http?
I tried putting a cert and key file onto the module and then loading them into a options JSON to send to https.createServer but I get the following error which causes the app to crash and restart.
TypeError: cannot resolve module 'internal/root-certs.json', parent 'lib:tls'
at [anon] internal
at require () native strict preventsyield
at rootCertificates (lib:tls:133) strict preventsyield
at Server (lib:tls:29) strict
at Server (lib:https:211) strict construct
at createServer (lib:https:225) strict
at [anon] (/index.js:159) strict
at [anon] (lib:fs:235) strict preventsyield
Fatal error, restarting program...
Seems like the file got missing in the newest version. Thank you. Will try to fix next weekend.
But for your use case..it would not try to get the root certs if you add a ca file, see code:
if(!options.ca) options.ca = module.exports.rootCertificates;
You should always add a ca file if you create a server (well, unless it is not a self-signed cert with error message in browser).
Maybe that is an option to go forward.
Thanks, I will try that out.
Just out of curiosity, why is it trying to find the root cert? If I am creating a server, it should not care about the root cert (or the chain for that matter). As long as it has the key and the public signed certificate, all should be good. If I am using it to connect to a remote server, then having the full chain would be a requirement in order to trust the other server cert but only if the other server cert is not a publicly trusted cert that is..... although, I suspect you have all the usual root certs in root-certs.json (ie the ones most OS systems trust by default and that are shipped with the OS) If that is the case, what about allowing root-certs.json to be edited just like you can on a regular OS? (Think Certificate Manager in Windows OS for example) That said, options.ca should be an addition to root-certs.json rather than a replacement for it. Being a replacement means the module will only be able to connect to servers signed with that single CA certificate which would certainly be probelmatic. Idealy, it should be options.ca=['cert','cert'] rather than options.ca='cert'
Not 100% sure that the root certs do not have to be loaded on server side. You might be right that the root certs are not needed for the server side. But I am not sure. You need to give the intermediary certs on server side, otherwise the client does not accept if it only has the root ones. That I know. And I think the root certs file is actually not only root certs, but also intermediary certs. So it might matter to have them loaded on the server, too.
Regarding appending CAs:
- Last, the roots cert file is massive. So you do not want them loaded all the time, especially not on a device with 4 MB RAM. That is why they are not loaded if the user gives CAs.
- Second, complete replacement is also what Node.JS does: https://nodejs.org/api/tls.html#tls_tls_createsecurecontext_options
You can load multiple certs in options.ca. And you can specify  if you do not want any CA, including the root ones.
Will fix the missing file on the weekend!
Ok, so I tested with a ca cert and with options.ca=. Both work just fine which is what I expected. For the server, there should be no need to define anything other than the server cert and it's key. It is actually up to the client to decide if it will trust the cert or not based on the url firstly but then the chain. The client needs to have access to the cert chain through it's own cert store. This is where root_certs.json comes in. This is the equivalent of the preinstalled certs that are shipped with all OS systems and some runtime environments like JRE. So, for the project I am working on, I will need both server and client capabilities in the module. The server side is good based on the above and I tested my API server and it does what is needed. The client side is going to be a little more difficult. Obviously I don't want to load every possible root cert so I will need to be able to change root-certs.json on the fly. Basically I will add API endpoints that allow for adding to or deleting from that file. Is it available to the JS running on the module?
The way it is currently is exactly the way Node.JS does it, so I would like to keep it this way. No, the root certs cannot be appended/changed.
But, you can simply give your own certs, including root certs. That is as good, because the root certs will then not go into RAM, and on disk they do not really matter, they are compressed with gzip...
BTW, fixedd the missing root certs file in the new version 1.6.1, which you can flash now! The PC versions cannot be downloaded yet, takes a day, but the ESP32+neonious one versions are already available.
This post is deleted!