我们最近设置了一个两层内部证书颁发机构。我们还通过 Active Directory 传播根 CA，因此来自我们内部 CA 的证书会自动被我们网络中的每个 (Windows) 系统信任。
我们的开发人员需要为其本地工作站提供 SSL 证书。一种选择是为他们生成通配符证书，例如*.foo.bar.com.
好处是易于实施和面向未来（如果我们将来创建新的子域，它会自动覆盖它们）。
但是，另一方面，如果我们要颁发通配符证书，您如何确定恶意员工不会滥用它？
想象一下，一个恶意开发者在他们的本地工作站 (mail.foo.bar.com) 上建立了一个网站，并且可以以某种方式毒害 DNS 或修改用户的本地host文件。该通配符证书为他们的恶意网站提供了可信度，使其看起来更真实。
我是不是太偏执了？我们应该发布通配符并简化证书维护，还是应该为每个 DNS 名称生成唯一证书以限制使用范围？
有人有什么想法吗？经验？
编辑
在我看来，这里发布了两个非常好的解决方案：
按照@Kotzu的建议，将开发/测试和生产分成独立的 CA。对于我们个人而言，我不能证明为此目的而设置第二个 CA 是合理的。对于我们拥有的证书数量（总共 40 个，其中 10-20 个是开发者）来说，这太过分了。也就是说，我完全认为这是最好的答案。
按照@immbis的建议修改 DNS 命名结构，以便名称的“dev”部分是子域而不是子子域。从而使通配符更明显地成为开发域。这将在很大程度上减轻我对颁发通配符证书的担忧。然后模仿只能发生
*.dev.ourdomain.com- 我可以接受。也就是说，我们只是对太多地方进行了硬编码以使其实用。
我认为我们最终要做的是继续向每个开发人员颁发完全合格的 SSL 证书。这感觉更安全，因为它为恶意人员滥用/冒充合法资源留下了更少的回旋余地。无论如何，这整个情况有点拖尾。我希望我们的开发人员一般不会恶意行事并试图建立虚假网站。我只是不想分发像免费糖果这样的受信任的通配符证书，只是为了以后让它们以某种意想不到的方式被使用/使用。
如果我们需要越来越多的证书并且颁发单个证书变得难以管理，那么我们将考虑设置仅受开发工作站（而不是整个公司）信任的第二个 CA 并颁发新的通配符证书。