Windowsserverdocs: "If you use your own certificate, make sure to specify the name provided in the certificate"

[jaypatrick]

There is no option to specify the name provided in the certificate, e.g. a custom domain name? This is necessary for us since our local domain suffix is .local. So it defaults to being accessible via localhost:<portNumber>, which then screws up registering in Azure as well, since the appUrl is localhost.

Are we missing something during the installation process? We would like the url to be admin.<ourDomainName>.com so that we can purchase a certificate with this SPN (or SAN).

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: fe84fb4b-3420-bc1e-6a1d-b64ecc56fc5e
• Version Independent ID: f089767e-4613-d595-a0ee-0dab012724a1
• Content: Install Windows Admin Center
• Content Source: WindowsServerDocs/manage/windows-admin-center/deploy/install.md
• Product: windows-server-threshold
• GitHub Login: @nwashburn-ms
• Microsoft Alias: niwashbu

[jakemarston]

Any updates on this?

[jaypatrick]

Waiting as well. Cannot deploy this until clarification is provided as to how to work around this, or this is fixed.

[jakemarston]

I'm in the exact same situation @jaypatrick.

It looks to be related to this issue on the User Voice Forum https://windowsserver.uservoice.com/forums/295071-management-tools/suggestions/33990187--security-certificate-wildcard-certificate

[jaypatrick]

I've played around with the preview bits, and now it defaults to the name specified in the cert...but that still doesn't work, because we're using a wildcard cert *.domainname.com, so now if I specify port 443, the default URL is simply domainname.com:443, which of course is our production website!

Being able to specify a host header would fix this problem, would make DNS entries very easy (just use a CNAME record)...this product is essentially worthless for anyone who wants to use split dns to map records to their public domain (and registration in Azure is still broken, it uses the computer NETBIOS name for the URL hostname).

We're about to move on and just give up on this half-baked product.

[jakemarston]

I've played around with the preview bits, and now it defaults to the name specified in the cert...but that still doesn't work, because we're using a wildcard cert *.domainname.com, so now if I specify port 443, the default URL is simply domainname.com:443, which of course is our production website!

Being able to specify a host header would fix this problem, would make DNS entries very easy (just use a CNAME record)...this product is essentially worthless for anyone who wants to use split dns to map records to their public domain (and registration in Azure is still broken, it uses the computer NETBIOS name for the URL hostname).

We're about to move on and just give up on this half-baked product.

I feel your pain, it's decent product with some huge design flaws.

[KasJensen]

I have a similar issue.
I wanted to use Azure AD Application Proxy, point admincenter.mydomain.com to it and off to the races, but it doesn't work very well.
Since it all relates to hostnames and certificates, I'll post my own UserVoice issue: https://windowsserver.uservoice.com/forums/295071-management-tools/suggestions/37137811--feature-request-url-bindings-for-application-pro
(go vote for it, because apparantly the WAC community is dry as a desert).