TLS certificate strings and custom SNI validation

[j4k0xb]

Please consider adding these features:

1. Allow setting the trust_store etc. to a string that contains the certificate, instead a path. Use case: crate ships with custom CA certificate of the server, avoid creating temporary files

2. Allow passing a custom server name that will be used for the SNI (server name indication), instead of using the host name. Use case: host name of the connection (IP) is different than the certificate's SNI (device serial number). See Node.js TLS servername parameter and paho.mqtt.c for how this could be implemented.

[fpagliughi]

As you probably know, this library is currently still just a wrapper around Paho C, which does all the network I/O including the TLS layer. So to load the certificate from memory, we'd need to add the feature to the upstream library. There have been requests for this across the projects for a while now, back to 2020 in #103. There's even a PR up for it in the C lib: eclipse-paho/paho.mqtt.c#1328. I'm with you 100%. I'd like to get this in. I can maybe push on the maintainer.

For 2: (SNI): Yeah on this one, too. Same issue with the upstream, but this seems easy enough to get a PR up to the C lib. I'll put an Issue up on that repo to bring it up.

[fpagliughi]

If you have the ability to test out a C client for the SNI feature, that might help to get it landed. See: eclipse-paho/paho.mqtt.c#1582

If not, I can try to hack a branch of the Rust client here that wraps that C branch.

[j4k0xb]

If you have the ability to test out a C client for the SNI feature

It sends the correct SNI:

But the host name check seems to still use the IP and fails when using ssl_opts.verify = 1:

Trace : 4, 20250226 235023.246 SNI server/host name is 01************
Trace : 4, 20250226 235023.246 SSL handshake started write:unknown:unknown
Trace : 4, 20250226 235023.246 SSL state connect:before SSL initialization:(NONE)
Trace : 4, 20250226 235023.246 SSL state connect:SSLv3/TLS write client hello:(NONE)
Trace : 4, 20250226 235023.246 SSL connect:SSLv3/TLS write client hello
Trace : 4, 20250226 235023.260 SSL state connect:SSLv3/TLS write client hello:(NONE)
Trace : 4, 20250226 235023.261 SSL connect:SSLv3/TLS read server hello
Trace : 4, 20250226 235023.263 SSL state connect:SSLv3/TLS read server hello:(NONE)
Trace : 4, 20250226 235023.263 SSL connect:SSLv3/TLS read server certificate
Trace : 4, 20250226 235023.816 SSL state connect:SSLv3/TLS read server certificate:(NONE)
Trace : 4, 20250226 235023.816 SSL connect:SSLv3/TLS read server key exchange
Trace : 4, 20250226 235023.817 SSL state connect:SSLv3/TLS read server key exchange:(NONE)
Trace : 4, 20250226 235023.817 SSL state connect:SSLv3/TLS read server done:(NONE)
Trace : 4, 20250226 235023.818 SSL state connect:SSLv3/TLS write client key exchange:(NONE)
Trace : 4, 20250226 235023.818 SSL state connect:SSLv3/TLS write change cipher spec:ECDHE-RSA-AES256-GCM-SHA384
Trace : 4, 20250226 235023.818 SSL state connect:SSLv3/TLS write finished:ECDHE-RSA-AES256-GCM-SHA384
Trace : 4, 20250226 235023.818 SSL connect:SSLv3/TLS write finished
Trace : 4, 20250226 235023.929 SSL state connect:SSLv3/TLS write finished:ECDHE-RSA-AES256-GCM-SHA384
Trace : 4, 20250226 235023.929 SSL connect:SSLv3/TLS read change cipher spec
Trace : 4, 20250226 235023.977 SSL state connect:SSLv3/TLS read change cipher spec:ECDHE-RSA-AES256-GCM-SHA384
Trace : 4, 20250226 235023.977 SSL state connect:SSLv3/TLS read finished:ECDHE-RSA-AES256-GCM-SHA384
Trace : 4, 20250226 235023.977 SSL handshake done write:unknown:unknown
Trace : 4, 20250226 235023.977 SSL certificate verification: X509_V_OK
Trace : 4, 20250226 235023.977 SSL connect:SSL negotiation finished successfully
Trace : 4, 20250226 235023.977 X509_check_host for hostname 192.168.0.12 failed, rc 0
Trace : 4, 20250226 235023.977 SSL alert write:warning:close notify

[fpagliughi]

Yes. I just caught this as well when I did some additional testing. I’ll have a look shortly.
Thanks for helping out.

[fpagliughi]

OK. I pushed another commit into that branch in the Paho C repo, and it now uses the optional server name for both the SNI and host name checks. I need to run the unit tests and do some minor cleanup, but I think this is the basic fix.

[j4k0xb]

That fixed it, thanks!

[fpagliughi]

Arghhh... but it failed CI. Note quite done yet...

[fpagliughi]

OK. Found a couple copy-paste errors in what I did for the synchronous client which broke the high availability (multiple URLs) check. I kept sending the same URL to verify all the server names. Oops.

I pushed a fix and all the unit tests in the C lib PR are working now.