我的客户拥有“domain.com”。我们需要为内部和外部访问提供各种应用程序友好的名称。这些应用程序是具有不同身份验证级别的 WCF Web 服务和 MVC Web 应用程序（在 AD 域内和跨 AD 域的 Windows 身份验证以及纯文本身份验证）。它看起来有点像这样：
UAT 环境
- service1.uat.services.domain.com
- service2.uat.services.domain.com
- service3.uat.services.domain.com
- service4.uat.services.domain.com
- application1.uat.apps.domain.com
- application2.uat.apps.domain.com
生产环境
- service1.services.domain.com
- service2.services.domain.com
- service3.services.domain.com
- service4.services.domain.com
- application1.apps.domain.com
- application2.apps.domain.com
我们可能有更多的子域，并且一切都需要使用 SSL 保护。
我们已经多次改变了如何配置它的想法，但现在我们遇到了一个可能的限制。我们认为通配符 SSL 证书可能有效，但显然它们仅适用于单个级别的子域，即 *.services.domain.com。
由于预算原因，我们想注册一个通配符 SSL 证书并将其应用于多个服务器（属于多个 AD 域，以及我们 DMZ 中的一些服务器）。
今天早上我有了一个想法，但我对这件事的了解还不够，无法做出明确的决定。你们中是否有人预见到使用以下命名约定而不是上述命名约定的任何限制？
- service1-uat-services.domain.com
- service2-uat-services.domain.com
- service3-uat-services.domain.com
- service4-uat-services.domain.com
- application1-uat-apps.domain.com
application2-uat-apps.domain.com
service1-services.domain.com
- service2-services.domain.com
- service3-services.domain.com
- service4-services.domain.com
- application1-apps.domain.com
- application2-apps.domain.com
这样，我们可以为 *.domain.com 注册一个通配符，并为每个应用程序/服务使用一个单级子域，但仍然允许我们在逻辑上保持一切独立。使用此设置是否有任何人可以识别的任何技术问题？