My client owns "domain.com". We need to provide friendly application names for internal and external access. Applications are WCF web services and MVC web applications with different levels of authentication (Windows authentication within and between AD domains and plain text authentication). It looks something like this:
UAT environment
- 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
Work environment
- service1.services.domain.com
- service2.services.domain.com
- service3.services.domain.com
- service4.services.domain.com
- application1.apps.domain.com
- application2.apps.domain.com
We will most likely have more subdomains, and everything should be secured with SSL.
We changed our minds how to configure this several times, but now we came across a possible limitation. We thought that the SSL substitution certificate might work, but apparently they only work on one level of the ie * .services.domain.com subdomain.
Due to our budget, we would like to register one substitution SSL certificate and apply it to several servers (belonging to several AD domains, as well as to several servers in our DMZ).
This morning I got an idea, but I don’t know enough about it to make a definite decision. Do any of you foresee any restrictions on using the following naming convention instead of the one above?
Thus, we can register a wildcard for * .domain.com and use the same level subdomain for each application / service, but still allow us to keep everything logically separate. Are there any technical issues that anyone can identify with this setting?
source share