paho.mqtt.c
paho.mqtt.c copied to clipboard
eclipse
Possibility to init MQTTClient from string based certificates
Hi Community,
the current implementation supports only the initialisation from file based certificates (using the MQTTClient_SSLOptions->trustStore, keyStore, privateKey). This forces us to have the certificates physically stored on the disk, exposing to risks to be stolen. It also make impossible to use external vaults where the certificates can be securely stored.
A solution could be to support string based certificates/keys, so we can initialise MQTTClient directly using the proper content.
Is there any concern about this feature? Any security/architecture issue why it was not introduced? We could in case open a pull request and implement our proposal.
Thanks, Lorenzo
I don't think there is a particular security risk. A PR would be welcome - preferably with a test. If it's without a test, then it will take (perhaps much) longer to get merged because I'll have to write it.
The reasons why it hasn't been implemented is because no-one asked before, and I don't have time to add every possible feature :-)
Dear Ian, thanks for the clarification and for the effort you put in Paho project. I know from your blog that a lot of things are changing for you in this period. We'll do our best to do the pull request, including the test of it. All the best for the future
Hi @LorenzoBe,
I had a similar problem and came to the following solution for a buffer only 'workaround' as you can see in this branch read_ssl_certificates_from_buffer
Unfortunately I did not find time to rework it in a way to support files and buffers in a good way (simply failing on trying to load one is not really good imho)
But maybe this helps you?!
Dear @waltronix , thanks a lot for sharing your branch, it really helps! We probably need to extend it to support certificates chains, like in the original file based version. At the begin we also thought about "failing on trying to load one", but it's probably better to find a solution more predictable. Even if maybe we'll have to extend the current SLL opts structure. Or maybe we'll find a more compatible solution. Thanks, I will keep you updated
Have you also seen #550?
I know it is something different, but if you are tackling the ssl struct, in my opinion it would be great if we could configure/switch the ssl connection at all.
But this would be quite a change and I don't know @icraggs opinion on that.
I also want this feature to be able to generate a pre compiled tool with all ssl things inside
