Ssl – Chrome displays SSL error due to use of .local top level domain

I just replaced the SSL cert on a few of our servers (all hosted on
IIS7). At the suggestion of our IT manager, we're using a Subject
Alternative Name certificate instead of individual certs for each
server. We bought this cert from Digicert (it's not self-signed.) I
have installed the certificate on our servers and the sites load
without warning and show good locks in Firefox and Internet Explorer.
However, Chrome displays a red "x" through the lock icon and
strikethrough font for the "https" portion of the URL. The Connection
tab displays the following error:

"The identity of this website has not been verified. The identity of
the server you are connected to cannot be fully validated. You are
connected to a server using a name only valid within your network,
which an external certificate authority has no way to validate
ownership of. As some certificate authorities will issue certificates
for these names regardless, there is no way to ensure you are
connected to the intended website and not an attacker."

Clicking on "Certificate Information" shows me the full chain of certs
(our cert, Digicert's intermediate cert and Digicert's CA cert) and
the certificate status for all three shows as "This certificate is
OK.". I have quadruple checked that the hostname I am using in the
URL is an exact match for either the common name or one of the subject
alternative names in the cert. The previous cert we had on these
sites was a wildcard cert for *.mycompany.local, while the new common
name and SAN names are for specific hosts within the mycompany.local
domain (i.e. eng-wiki.mycompany.local).

The explanation from Chrome almost sounds as though it has detected
that an internal DNS server was used to resolve the IP of the server,
but that was the case with the old wildcard cert as well, and if that
were a valid reason to claim that the identity couldn't be verified,
it should have failed the same way with the old wildcard cert (but it
did not.) Moreover, that explanation would imply that no company
internal servers can have their identity verified, which does a lot
more harm to security than good, since we'll all have to teach our
users to ignore the security warnings in Chrome despite having dropped
hundreds of dollars on a legit cert specifically to avoid that.

I'd be grateful for any help.

Thanks!

–edit–

Digging further today, I searched the Chromium source for the text of
the error message and found that the issue is caused by Chrome
concluding that the hostname is not unique. There are other posts
reporting this issue like this one with SAN certificates when
using a shortname for their URL. But I'm using a fully qualified
server name, for example wiki.mycompany.local

The code that determines my hostname as non-unique is here, and I see some comments discussing gTLDs which I suspect is the root cause. I
don't know much about global top level domains, but my company uses
the .local pseudo-TLD. Wikipedia seems to say that this is no longer a
good idea (I can't make 3 links b/c my reputation is too low on server
fault, please feel free to edit this and make it a link
en.wikipedia.org/wiki/.local), though it was a recommended
practice many years ago when our IT team set up our network. Not an
easy thing to ask them to change now

I'm tempted to edit my question to remove the SAN element from the
equation, except that I did not have this issue when using a wildcard
cert for mycompany.local. So I still suspect the use of a SAN cert is
part of the issue. Still grateful for any help.