我们的网络服务器很少由外包合作伙伴管理，他们与我们在同一个办公室工作，使用连接到我们公司网络的笔记本电脑，并在我们的 AD 中拥有用户帐户。他们请求并应用了通配符证书以使某些 IIS 站点（全部面向内部）https。
IT 中的某个人提出了一个担忧，即从安全的角度来看，外包管理员在网站上请求和应用证书是不可取的。这是论据：
使用通配符证书，您可以“模拟”任何服务，即使是那些不是由特定团队在他们同意管理的特定服务器上管理的服务。如果证书在我们公司之外泄露，它可能会带来安全风险，例如，可能会被用于设置假装由我们拥有/验证的服务，而实际上这些服务并非由我们拥有/验证。我们可能有 NDA，但恕我直言，限制有权访问证书的手数（我想说甚至是内部手！）仍然是一个很好的做法，并且考虑到我们甚至使用了基于伪角色的用户名，正如我们所期望的那样人们可能比内部员工更频繁地轮换。
这是一个内部证书，无法在 Internet 上解析。其他人对此有何看法？
我将用一些技术细节来补充@schoeder 的答案。
我对您的情况的理解是您有这样的服务器应用程序：
intranet.xyz.abc.com
documents.xyz.abc.com
applications.xyz.abc.com
...
并且您的合作伙伴也有一些应用程序在同一台服务器上运行：
partner1.xyz.abc.com
partner2.xyz.abc.com
以上所有内容都是面向内部的（无法从互联网访问）。现在，合作伙伴懒得为他们的每个 IIS 应用程序制作单独的证书，所以他们制作并安装了一个全局 a 证书：
*.xyz.abc.com
凉爽的。这涵盖了他们所有的应用程序。但它也涵盖了你的所有。假设他们可以访问属于此通配符证书的私钥，那么他们可以在您的 Intranet 或文档服务器中进行中间人操作并读取所有流量。
此外，如果您的公司（或您的合作伙伴的恶意管理员决定站起来）任何与通配符匹配的面向公众的网站，例如：
www.xyz.abc.com
那么，由于它是一个私有的内部 CA，公众不会被他们的欺骗所愚弄，但是您从内部连接的任何员工（将该 CA 安装到他们的操作系统中）都会信任www.xyz.abc.com.
正如@schroeder 指出的那样，这里存在内部威胁的可能性是巨大的。
内部威胁是一个没有足够多的组织考虑的主要问题。IT 人员提出这个问题是正确的。
但争论只是一个因素。提出了“威胁”，现在需要进行“威胁分析”。如果恶意内部人员（无论是否外包）可以冒充服务，会有什么影响？如果这种影响很小，那么您可以选择忽略这种威胁。
仅仅因为可能发生的事情并不意味着我们需要吓坏。我们需要考虑影响和可能性，并确定这是否是我们需要处理的事情。
如果没有关于您的环境、服务、数据流等的更多详细信息（您可能不应该在此处披露），这就是我们可以做出的回应。