Comment 16 for bug 1952414

One thing I noticed was juju-f74f34-0-lxd-0.maas (FQDN) vs juju-f74f34-1-lxd-0 (hostname) in "cert_requests". I will run more testing to see if there is a correlation between cert_requests data and the failed units.

$ juju show-unit vault/0 --endpoint certificates
vault/0:
  workload-version: 1.8.8
  machine: 0/lxd/2
  opened-ports:
  - 8200/tcp
  public-address: 192.168.151.190
  charm: ch:amd64/jammy/vault-93
  leader: true
  life: alive
  relation-info:
  - relation-id: 10
    endpoint: certificates
    related-endpoint: certificates
    application-data: {}
    related-units:
      keystone/0:
        in-scope: true
        data:
          cert_requests: '{"juju-f74f34-0-lxd-0.maas": {"sans": ["192.168.151.193",
            "192.168.151.99"]}}'
          egress-subnets: 192.168.151.193/32
          ingress-address: 192.168.151.193
          private-address: 192.168.151.193
          unit_name: keystone_0
      keystone/1:
        in-scope: true
        data:
          cert_requests: '{"juju-f74f34-1-lxd-0": {"sans": ["192.168.151.187", "192.168.151.99"]}}'
          egress-subnets: 192.168.151.187/32
          ingress-address: 192.168.151.187
          private-address: 192.168.151.187
          unit_name: keystone_1
      keystone/2:
        in-scope: true
        data:
          cert_requests: '{"juju-f74f34-2-lxd-0": {"sans": ["192.168.151.188", "192.168.151.99"]}}'
          egress-subnets: 192.168.151.188/32
          ingress-address: 192.168.151.188
          private-address: 192.168.151.188
          unit_name: keystone_2