MemoryDB certificate verification fails after upgrade to version 5.7.0 about emqx

[savonarola]

As far as I understand, SNI should contain the exact host, not a wildcard to match: not *.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com but clustercfg.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com

[savonarola]

Hello!
From v5.6.1 to v5.7.0 we didn't change redis-related connection settings. Can we check that v5.6.1 version still connects with the same tls settings? Wasn't the error caused by the very reconnection attempt?

[johannesfknx]

@savonarola Thanks for your reply!
We rolled back to v5.6.1 and connection works fine. We also changed the version back and forth with the same settings. Connection only fails with v5.7.0.

[johannesfknx]

Looking at the error message, it might be related to this cange: #12962

[id]

@johannesfknx could you share cert from your MemoryDB instance with us? We'll try to reproduce the issue.

[savonarola]

Yes, this is the default change for all clients making checking rules more strict.

ssl {
    enable = true
    verify = "verify_peer"
    cacertfile = "/etc/ssl/certs/ca-certificates.crt"
  }

Could you provide the full authorization section of the config?

Also, what is

• the hostname to which EMQX connects
• the CN's provided by the host certificate

[johannesfknx]

emqx.conf

node {
  name = "[email protected]" # this is overwritten with an env variable
  cookie = "emqxsecretcookie" # this is overwritten with an env variable
  data_dir = "data"
}
cluster {
  name = emqxcl
  discovery_strategy = manual # this is overwritten with an env variable
}
dashboard {
    listeners.http {
        bind = 18083
    }
}
authentication = [{
  auto_reconnect = true
  backend = "redis"
  cmd = "HMGET api:emqx:v0:mqtt_user:$${username} password salt"
  mechanism = "password_based"
  password_hash_algorithm {
    dk_length = 64
    iterations = 10000
    mac_fun = "sha512"
    name = "pbkdf2"
  }
  pool_size = 8
  redis_type = "cluster"
  servers = "$${var.cluster.config_redis_address}" # this is overwritten with an env variable
  ssl {
    enable = true
    verify = "verify_peer"
    cacertfile = "/etc/ssl/certs/ca-certificates.crt"
  }
}]
authorization {
  cache {
    enable = true
    max_size = 20000
    ttl = 30m
  }
  deny_action = "disconnect"
  no_match = "deny"
  sources = [
    {
      auto_reconnect = true
      cmd = "HGETALL api:emqx:v0:mqtt_acl:$${username}"
      pool_size = 8
      redis_type = "cluster"
      servers = "$${var.cluster.config_redis_address}" # this is overwritten with an env variable
      ssl {
        enable = true
        verify = "verify_peer"
        cacertfile = "/etc/ssl/certs/ca-certificates.crt"
      }
       type = "redis"
    }
  ]
}
telemetry {enable = false}
flapping_detect {
  enable = true

  ## The max disconnect allowed of an MQTT Client in `window_time`
  max_count = 10

  ## The time window for flapping detect
  window_time = 1m

  ## How long the clientid will be banned
  ban_time = 5m
}
# When a client subscribes with a wildcard topic, the server will send all matching retained messages at once, leading to a force shutdown of the connection
# this will trigger a reconnect on the client side and the server will send the retained messages again and again and thus create much load on the broker
# therefore, it is better to disable the force shutdown
force_shutdown {enable = false}

with

EMQX_AUTHENTICATION__1__SERVERS : clustercfg.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com:6379
EMQX_AUTHENTICATION__1__SSL__SERVER_NAME_INDICATION : *.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com
EMQX_AUTHORIZATION__SOURCES__1__SERVERS : clustercfg.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com:6379
EMQX_AUTHORIZATION__SOURCES__1__SSL__SERVER_NAME_INDICATION : *.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com

Cert:

Server certificate
subject=CN = *.xxx-config-store.szcvcy.memorydb.eu-central-1.amazonaws.com
issuer=C = US, O = Amazon, CN = Amazon RSA 2048 M02

Let me know if you need more information.

[zmstone]

Not the first time to see people end up confusing wildcard certificate with SNI.

Some learning material: https://www.cloudflare.com/learning/ssl/what-is-sni/

To put it simple, SNI is the server's name (indicator) which is sent by the client to the server.
The server takes it to figure out which name the client used to address the server.

Most of the time, SNI is exactly the FQND the client uses to connect the server.
However, technically SNI can be anything, it's just * is most likely not going to work because in no way it's a "indicator"