The scripts at $DAYJOB have been using the unqualified domain-name instead of the FQDN just fine for years.
So if the outsourced netadmin team mistakenly removes the unqualified domain-name from a TLS cert (replacing it with garbage), those scripts will all suddenly fail catastrophically because they rightfully refuse to trust the connection.
Sigh. 😑
@drscriptt DNSy aspects find the "dbserver" machine correctly appending the .foocorp.local search domain to find "dbserver.foocorp.local". However once the TCP connection was made, the MS SQL Server/ODBC driver TLS negotiation rejected the cert because the server only vouched for "dbserver.foocorp.local" not "dbserver", not auto-appending.
The solution was pretty straightforward, to have them replace the garbage SAN entry with the unqualified name (in addition to the FQDN in the SAN field), it just happened to be something outside my scope of permissions, so I had to raise a stink to get it done quickly enough to bring everything back online. Fortunately I bill by the hour 😉
@drscriptt It was likely a semi-innocent hiccup since I knew changes were coming down the pike—they were adding a fronting load-balancer, so they were duplicating the dbserver1.foocorp.local to a dbserver2.foocorp.local, and then fronting it was the failover server, so they needed to add the failover server's name to the SAN. But instead of adding it, the removed the one in use, and failed to add the new one.
Tim Chase
DrScriptt