The client and server cannot communicate, because they do not possess a common algorithm

Describe your question

I recently shifted a project from .Net Core 3.1 to .Net 5.0 and updated MQTTNet to 3.0.14. Since making the change, I have been unable to use the MQTTNet client to connect to my Mosquitto broker. During the call to ConnectAsync, the code throws the exception: “The client and server cannot communicate, because they do not possess a common algorithm”.

I am not sure why this is happening after the upgrade, one thought I had was to back the TLS version down to v1.2 instead of 1.3, but I get a remote certificate validation error (also new since the root for that certificate is in my Trusted Root Certificate Authority store and nothing on the other end changed)

I am running it on my (Windows) development computer, and have yet to try it on an Ubuntu box (same as the production server)

For reference, the MQTTClient options:

            List<X509Certificate> certs = new List<X509Certificate>
            {
                new X509Certificate2(config.GetValue<string>("DeviceCertificate"), config.GetValue<string>("CertificatePassword"))
            };
            IMqttClientOptions options = new MqttClientOptionsBuilder()
                .WithTcpServer("Server FQDN", 8883)
                .WithTls(new MqttClientOptionsBuilderTlsParameters
                {
                    UseTls = true,
                    Certificates = certs
                })
                .WithCleanSession()
                .Build();

The Mosquitto v2.0.7 config:

listener 1883 localhost

listener 8883
certfile /etc/mosquitto/certs/server.pem
capath /etc/mosquitto/ca_certificates/
keyfile /etc/mosquitto/certs/server_key.pem
require_certificate true
use_identity_as_username true
acl_file /etc/mosquitto/conf.d/aclfile

log_type all
log_timestamp_format %Y-%m-%dT%H:%M:%S

user mosquitto

Which project is your question related to?

• Client

[vukovinski]

This is probably due to TLS 1.2 -> TLS 1.3 changes.

https://www.microsoft.com/security/blog/2020/08/20/taking-transport-layer-security-tls-to-the-next-level-with-tls-1-3/

[KMcNickel]

In regards to TLSv1.2, it looks like theres an issue with it trying to connect to the revocation server which is odd since the server is running and the links are correct in the certificates, but is also an issue I can manage separately.

I still cannot seem to figure out why 1.3 doesn’t work but I would like to know if there is a way to find what algorithms are able to be / are actually being tried by the system and if there might be something else Im missing.