With the typical Azure internal DNS and FQDN, the portal and server assume these machine names and Admin URLs during the install process. When you set up a Web Adaptor on a multimachine deployment, and point the public IP of this VM to an organization URL of the 'myportal.myorg.com' format, this DNS is your common name on the SSL certificate and the same is used to access your /portal and /server. All merry thus far !
If your company has a private cloud and can control the Azure FQDN, you are gold because you can add those FQDN under the Subject Alternate Name field of your SSL. And that enables you to import this certificate chain in your Portal and Server Admins. That in turn makes all admin URLs fully secure too which is awesome. However, if you are just using the Azure offering for the FQDN in the xxxxsomexxmumboxxjumboxx.internal.cloudapp.net format, you cannot add this domain on the SAN because Azure owns these. These become your admin URLs for Portal and Server, you use them for federation and for web adaptors, and they wont be secure.
So my question is two folds -
1) What is the recommendation for such cloud deployments, you just get the SSL with the myportal.myorgdomain.com common name and use that to secure the web adaptor while leaving the portal and server admin end points non-secure ? This is going to cause problems with token generation, hosted services etc etc. I assume.
2) Should you just use self signed certs on the Portal and Server admins instead, while using the web adaptor DNS issued SSL on the IIS (for public access) ?
Keen to know how do you all tackle this ?
