Consul Client join consul servers cluster | certificate error

We have a server cluster setup of 3 consul servers & 3 corresponding consul clients configured to join the server cluster for Watch & config changes.
Upon configuring ssl for both server & clients, we are facing the below error with certs despite creating it with same CA signatures.
[WARN] agent: error getting server health from server: server=consul-client1 error=“rpc error getting client: failed to get conn: x509: certificate specifies an incompatible key usage”

Earlier we were facing the following error, and then we tried adding the server.dc1.consul into the CN of the cert.
error=“rpc error getting client: failed to get conn: x509: certificate is valid for consul-client.example.com, consul-server1.example.com, consul-server2.example.com, consul-server3.example.com, not server.dc1.consul”

Consul-client config json

{
“server”: false,
“datacenter”: “dc1”,
“data_dir”: “/consul/data”,
“encrypt”: “”,
“log_level”: “INFO”,
“enable_syslog”: true,
“leave_on_terminate”: true,
“client_addr”: “0.0.0.0”,
“enable_script_checks”: false,
“disable_remote_exec”: true,
“node_name”: “consul-client1”,
“watches”: [
{
“type”: “key”,
“key”: “/config/ft.config.health.check”,
“handler_type”: “http”,
“http_handler_config”: {
“path”: “https://:8500/v1/watch”,
“method”: “POST”
}
}
],
“connect”: {
“enabled”: true
},
“ui_config”: {
“enabled”: true
},
“acl”: {
“enabled”: true,
“default_policy”: “deny”,
“down_policy”: “extend-cache”,
“tokens”: {
“agent”: “”
}
},
“retry_join”: [
“”,
“”,
“”
],
“verify_incoming”: true,
“verify_outgoing”: true,
“verify_server_hostname”: true,
“ca_file”: “certificate.pem”,
“cert_file”: “cert.pem”,
“key_file”: “key.pem”,
“ports”: {
“http”: -1,
“https”: 8500
}
}

Key usage and extended key usage are fields in X.509 certificates set when the certificate is created.

It seems yours denies a usage which is required in this use case.

Return to the software that created your certificates, and check its settings. The most likely one to be missing would be for the extended key usage to mark it as a server only certificate, not usable for client authentication.

yeah this was later addressed, by correcting the jks according to the required hosts. Thanks for the reply and suggestion.