locked
Proper Portal setup with pre-existing certs and multiple web apps. RRS feed

  • Question

  • I am testing a migration from ISA 06 to UAG 2010 SP1. I have been able to create separate trunks for each of my previous applications, OWA, SharePoint etc. using their preexisting certificates and making each the default application for the trunk.

    New to me is the portal idea. I setup an internal cert for testing called portal.domain.com and am able to login to the portal with no issues. I then added RDP as a test and that worked as I expected. I then tried to add OWA access to the portal. When adding this application using its public hostname I get and error when activated saying my certificates don’t match. My portal is “portal.domain.com” and my OWA is “webmail.domain.com” The error makes sense as the public names are different. I then tried to access OWA in the portal at it fails unless I setup another  seperate trunk for OWA using the public hostname at the same time, which then redirects and re-authenticates. I then tried using the portal public hostname for OWA, the error then goes away on activation and access works. But then what do you do if you are trying to use multiple web apps in your portal? I can’t keep using the portal public hostname…..

    So long story short, how do you properly set this up? I would like to setup separate trunks for each app so end users have a closer end user experience to ISA. I also want to setup a portal for more advanced users that have the same apps as the separate trunks and more.

    Monday, December 19, 2011 4:55 PM

Answers

  • Hi Techguy18,

    Yes it is meant to be sharepoint.domain.com... the error you described in your original post stems from the fact that when you use RDP, UAG is doing address translation and the portal is used to initiate and manage the connection. With web applications such as OWA and Sharepoint, then these can be directly published as individual applications with their own public name, as published applications under the trunk. In your case, you had an internally created certificate defined for your trunk (portal.domain.com) which when it was used for OWA (webmail.domain.com) and SP2010 (sharepoint.domain.com) produced a certificate mismatch error on the SSL Certificate.

    You should use a wildcard certificate on the trunk or a certificate with subject alternative names (SAN) for all of  the intended web applications that you plan on publishing (including the portal URL).

    So a wildcard cert of *.domain.com on the trunk should suffice. Then create (A) records in DNS for:

    • portal.domain.com at 1.2.3.4
    • webmail.domain.com at 1.2.3.4
    • sharepoint.domain.com at 1.2.3.4

    If this is not clear then please post back

    Regards,

    Mylo

     

    • Marked as answer by TechGuy18 Wednesday, December 21, 2011 12:50 AM
    Wednesday, December 21, 2011 12:25 AM

All replies

  • Hi Techguy 18,

    You don't need a trunk for each separate web app and you can make this work like ISA by directly publishing the web application using a wildcard cert on the trunk. Let's say that you have a single portal trunk (*.domain.com) and then publish each web application through that trunk directly (using their original names). For example:

    portal.domain.com (1.2.3.4) is the trunk

    webmail.domain.com is application (1) with a DNS (A) record for the above IP address of the trunk: with a web application configured with a public hostname of webmail.domain.com

    sharepoint.domain.com is application (2) with a DNS (A) record for the above IP address of the trunk: with a web application configured with a public hostname of webmail.domain.com

    So, users may opt to use the portal to logon to UAG and then access the app or perhaps they'll bookmark it in their favourites.  I have customers using it in the old "ISA" way for webmail, whereas Sharepoint users go thru the portal to access multiple SP web applications (they can still bookmark of course).

    Regards,

    Mylo

    Tuesday, December 20, 2011 8:39 AM
  • Did you mean to type "SharePoint.domain.com" for the public hostname for application 2?

    It sounds to me that my issues with the portal and the HTTPS trunk is tied to the certificate and that I have to run a wildcard cert on the portal itself in order to run different SSL applications inside of the same portal.

    Anyway to get around using the wildcard cert and just use the preexisting ones I already own?

     

    Tuesday, December 20, 2011 5:20 PM
  • Hi Techguy18,

    Yes it is meant to be sharepoint.domain.com... the error you described in your original post stems from the fact that when you use RDP, UAG is doing address translation and the portal is used to initiate and manage the connection. With web applications such as OWA and Sharepoint, then these can be directly published as individual applications with their own public name, as published applications under the trunk. In your case, you had an internally created certificate defined for your trunk (portal.domain.com) which when it was used for OWA (webmail.domain.com) and SP2010 (sharepoint.domain.com) produced a certificate mismatch error on the SSL Certificate.

    You should use a wildcard certificate on the trunk or a certificate with subject alternative names (SAN) for all of  the intended web applications that you plan on publishing (including the portal URL).

    So a wildcard cert of *.domain.com on the trunk should suffice. Then create (A) records in DNS for:

    • portal.domain.com at 1.2.3.4
    • webmail.domain.com at 1.2.3.4
    • sharepoint.domain.com at 1.2.3.4

    If this is not clear then please post back

    Regards,

    Mylo

     

    • Marked as answer by TechGuy18 Wednesday, December 21, 2011 12:50 AM
    Wednesday, December 21, 2011 12:25 AM
  • Mylo,

     

    This makes perfect sense and I apprecate your help and feedback. I will test a wildcard cert with my internal CA and see how it goes, however I am sure it will work. If I run into problems I will post back.

    I was hoping I could use one cert for the trunk and use different certs for the applicaions. It sounds like a wildcard cert is the way to go as the applicaions I start with now maybe added to in the future not knowing the new URL's. Not all 3rd party cert providors allow you to update subject alternative names down the road. 

    Wednesday, December 21, 2011 12:54 AM