Machine charms with SSSD cannot use TLS certificates because of Common Name (CN) mismatch

[NucciTheBoss]

Now that #84 is fixed (thank you @wood-push-melon!), the sssd operator can successfully pull the TLS certificates from glauth-k8s via the certificate_transfer interface. However, sssd still fails to connect to glauth because of a Common Name (CN) mismatch between the hostname that was used to generate the TLS certificate in the glauth-k8s unit and the ingress URL sssd is using to connect to glauth. The sssd service generates the following error logs when I try to start it up with ldap_tls_reqcert set to hard (default):

libldap: TLS: hostname (10.0.0.135) does not match common name in certificate (ldap.glauth.com).
libldap: TLS: can't connect: (unknown error code).
libldap: ldap_err2string

10.0.0.135 is the LoadBalancer IP used by Traefik, and ldap.glauth.com is the configured hostname for my deployed glauth-k8s unit. ldap_tls_reqcert = hard basically tells sssd to wig out and throw out errors if the TLS certificate provided by the LDAP server is bad or doesn't match. The likely fix here is to provide the ingress URLs assigned to glauth-k8s without the port number as subject alternative names in the glauth-k8s unit's generated TLS certificate:

glauth-k8s-operator/src/integrations.py

Lines 183 to 192 in 9c78ee2

	hostname = charm.config.get("hostname")
	self.cert_handler = CertHandler(
	charm,
	key="glauth-server-cert",
	cert_subject=hostname,
	sans=[
	hostname,
	f"{charm.app.name}.{charm.model.name}.svc.cluster.local",
	],
	)

updated to something like the following...

        hostname = charm.config.get("hostname")
        self.cert_handler = CertHandler(
            charm,
            key="glauth-server-cert",
            cert_subject=hostname,
            sans=[
                hostname,
                f"{charm.app.name}.{charm.model.name}.svc.cluster.local",
                *[url.rsplit(":", maxsplit=1) for url in charm._ingress_per_unit.urls if charm._ingress_per_unit.urls],
            ],
        )

We'd also likely want to handle the case where ingress has departed and we should refresh the certificate. Here's a copy of my sssd.conf file for reference:

[sssd]
config_file_version = 2
domains = ldap

[domain/ldap]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://10.0.0.135:3893
ldap_search_base = dc=glauth,dc=com
ldap_default_bind_dn = cn=sssd,ou=sssd,dc=glauth,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = ec3fbf039df5dbcc1c08abdcce2da64fc17cb595edd8e9fdd7d78ee00e00d07a
ldap_use_tokengroups = False
ldap_group_member = member
ldap_schema = rfc2307bis
ldap_id_use_start_tls = True
ldap_library_debug_level = -1
cache_credentials = True

On the brightside, sssd can successfully connect to glauth-k8s and start using remote users and groups if I disable StartTLS in glauth-k8s and set ldap_id_use_start_tls to False 😄

Temporary workarounds

There are a couple of hotfixes you can use to get around the Common Name (CN) mismatch, but they're a bit hacky wacky:

Update /etc/hosts to resolve ldap.glauth.com to ingress URL

If you update /etc/hosts to resolve the LoadBalancer IP to the glauth-k8s hostname, sssd will happily connect to glauth-k8s:

<LoadBalancer IP> ldap.glauth.com

However, this doesn't work in production since sssd doesn't receive the glauth-k8s hostname from the ldap integration.

Set ldap_tls_reqcert to allow in sssd.conf

You can also bypass the issue by setting ldap_tls_reqcert = allow in your domain configuration, however, this isn't advisable as it just tells sssd to ignore the TLS certificate if it's bad and query the LDAP server anyway.

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1280.

This message was autogenerated

[shipperizer]

@NucciTheBoss i might be totally worng here, but have u tried to set the external_hostname on the traefik charm first?

saying that as usually we get the hostname from the ingress charm, then expose it via our own charms
now that works flawlessly in a ingress-per-app case, not sure ingress-per-unit

here we have a bit of a pickle situation in which we have the ldap with StartTLS so both ingress and glauth can ask for a certificates relation, but if we have the ingress set we should probably get the certificate for that external hostname

do i make any sense?cc @wood-push-melon

[wood-push-melon]

This has been resolved by #90