We use a DNS alias for a domain controller so applications don't need a new server name when the controller changes. We're moving those applications to LDAPS on port 636, but the certificate doesn't include the alias.
Adding the alias during enrollment didn't work with our current domain controller template. A separate web server certificate containing both names cleared the warning, but is that a good way to handle it?
First check whether the AD domain name itself would work for these clients instead of the custom alias. Certificates issued from the Kerberos Authentication template commonly include the domain name as a DNS SAN. If your clients can use that name and trust the issuing CA, it may avoid a custom SAN altogether.
Check the actual certificates on every controller the domain name can resolve to, not just one. Also test how the applications handle multiple addresses and failover. Changing the connection name is only useful if the clients behave as needed.
The separate certificate can be a workable solution, but clearing the warning doesn't prove every client is getting the intended certificate. Check what the DC actually presents on port 636 and verify the alias, trust chain, validity and revocation checks from the applications' side.
Having the controller's name on two certificates isn't necessarily the problem by itself. The practical concern is certificate selection and renewal. Test again after renewal and whenever certificates are added or removed, especially if the two certificates have different purposes or lifetimes.
The SAN you supplied was likely ignored because that template builds names from Active Directory rather than accepting them from the request. That's different from a broken enrollment.
You could evaluate a separate template that allows the subject to be supplied in the request, but keep enrollment tightly restricted and review the certificate's intended uses. Arbitrary subject names can enable impersonation if the wrong principal can enroll. Be especially cautious about CA-wide settings that allow arbitrary SANs across templates, since those have a much broader security impact.
picklejar+philosophy!:
Keep the normal domain controller certificate requirements in mind too. A certificate that works for LDAPS isn't automatically a replacement for every certificate the controller needs.
If you make a dedicated template, base its settings on the requirements for your environment rather than just copying a generic web server template. Review key strength, enrollment permissions and certificate lifetime, and make sure revocation information is published and reachable by the systems that need to check it.
Answers are reviewed before publication.
+fumble!then~recover:
Some clients can also discover domain controllers through AD service records. Whether that's an option depends on the application, so it's worth checking rather than assuming it follows the domain's DNS records.