Maybe I am dense, and maybe I just did not know before this. Or maybe I forgot. No matter.
The scenario is multi-label domains inside of a single forest. And using one of them to log in, and having the SIP domain be something other than that login.
So, we have a forest/domain of domain.org, and another name on the same domain as second.com. We want the FQDN of the server (an SE in this case) to be on the certificate, but we also need to have the second domain listed as well; otherwise the client gets confused. We will ignore the other SAN entries in hopes of keeping this simple.
Our certificate looks like this:
CN= fqdn.domain.org, SAN=fqdn.domain.org,sip.second.com
We put the (we thought) proper DNS records in place: SRV and A records in each zone. Except that we had the second.com zone point the SRV to the A record in the zone for domain.org. Our logic was imperfect in expecting the client to accept the certificate because of the re-direct would end up with a cert that had a name that rooted in the SIP domain (sip.second.com). Ooops. Cert errors. You can click through them, or accept them forever, but that is clunky.
The proper method is to have a full _sipinternaltls._tcp.domain.org SRV record pointing to an A record for each affected domain, SIP or server. In our case the SIP domain SRV record pointed at the fqdn.domain.org server. While technically the names matched, root certs were in AD and chained properly, the client did not like not having a clean track. After all, the client started the session looking at firstname.lastname@example.org and got pointed to fqdn.domain.org. The bottom line is that the client expected to show up at a server that was, or at least reported itself as, somethingorother.second.com.