私のクライアントは「domain.com」を所有しています。内部および外部アクセスのために、さまざまなアプリケーションにわかりやすい名前を付ける必要があります。アプリケーションは、さまざまなレベルの認証（ADドメイン内およびADドメイン間でのWindows認証とプレーンテキスト認証）を備えたWCFWebサービスとMVCWebアプリケーションです。これは少し次のようになります。
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にワイルドカードを登録し、アプリケーション/サービスごとに単一レベルのサブドメインを使用できますが、それでもすべてを論理的に分離することができます。この設定を使用して誰かが特定できる技術的な問題はありますか？