When declaring ssl on the server ip, many subdomains receive an error warning (Invalid certificate name. One of the two names is not in the allowed list, or is excluded).
Thanks.
When declaring ssl on the server ip, many subdomains receive an error warning (Invalid certificate name. One of the two names is not in the allowed list, or is excluded).
Thanks.
On Windows (and most other operating systems), if a certificate is bound to a specific IP address on port 443 then only that certificate can be used for https. In most cases this is not what you want to happen.
Years ago, the solution to this was to add multiple IP addresses to machines so that a certificate could be assigned to each one. Then, SNI (Server Name Indication) was introduced as a technique for the web server to select the correct certificate depending on the requested site. Using Certificates in Windows | Certify The Web Docs
The ideal way to use our app is:
Once the certificate has been acquired, the app will deploy to all matching IIS sites on the machine that have an http (or https) binding matching the domain(s) on the certificate. It will automatically add/update https bindings with SNI enabled, IP Set to All Unassigned and hostname set to the domain.
If an existing https binding is present with the hostname set but SNI not checked or a specific IP used, the app will reuse the settings currently being used for that binding under the assumption that you have setup the binding like this intentionally.
So the solution for you is to either let the app create HTTPS bindings for you, or update your existing https bindings to use IP All Unassigned, SNI checked and hostname set.