nope, not in my env - and I believe I do a plain-vanilla deployment with 'cephadm' I might have: -> $ ceph config-key get mgr/dashboard/key Error ENOENT: -> $ ceph config-key get mgr/dashboard/crt Error ENOENT: -> $ ceph config-key get mgr/dashboard/podster3.mine.priv/key -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCw7whSWhNzKln/ ... -> $ ceph config-key get mgr/dashboard/podster3.mine.priv/crt -----BEGIN CERTIFICATE----- MIIFIjCCA4qgAwIBAgIED/sABDANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlN ... -> $ ceph config-key get mgr/dashboard/podster1.mine.priv/key -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDbKrY2d/Tsg3xG ... -> $ ceph config-key get mgr/dashboard/podster1.mine.priv/crt -----BEGIN CERTIFICATE----- MIIFIjCCA4qgAwIBAgIED/sAAjANBgkqhkiG9w0BAQsFADA0MRIwEAYDVQQKDAlN ... -> $ ceph mgr services { "prometheus": "http://10.1.1.63:9283/" } The moment I add/recreate "global" cert: -> $ ceph dashboard set-ssl-certificate -i /root/bin/podster1.mine.priv.crt -> $ ceph dashboard set-ssl-certificate-key -i /root/bin/podster1.mine.priv.key dashboard starts and ! without fail/disable/enable: -> $ ceph mgr services { "dashboard": "https://10.1.1.63:8443/", "prometheus": "http://10.1.1.63:9283/" } But that, as show above, as per my original, first message, makes... In this case: 10.1.1.63 is poster3 - makes poster3 report "invalid" cert for it's poster1's cert. I believe this is a bug and is easily reproducible - unless it's intended behavior? Since I reported, I moved to 'reef' from 'squid' - the same (mis)behavior - I'm on Centos 9. I merely deploy a cluster with: -> $ cephadm bootstrap --mon-ip 10.1.1.61 --mon-id podster1.mine.priv --allow-fqdn-hostname which does its things. I add host, monitors, etc. Everything else seems to be a ok, it reproduces every time.