locked
Problem with UAG and SSTP RRS feed

  • Question

  • I'm having a problem with UAG and SSTP and I think it maybe a certificate related problem but I'm not 100% sure. Certificates I know very well, UAG not so much.

    I have a UAG server that is named uag.domain.com and an Exchange 2007 server published through UAG named mail.domain.com. I initially created a trunk using a cert I issued to the UAG box from my internal PKI that had a subject name of uag.domain.com. My Exchange server has an internally issued cert with the subject name of mail.domain.com and the required subject alternate names (I had previously been publishing Exchange through ISA and then TMG so I know that Exchange cert is good). I also published an SSTP connection which worked through the portal, and I was also able to connect by manually creating an SSTP VPN connectoid. The only problem I had was that when I used Outlook Anywhere, I'd get a couple of certificate errors since the subject and subject alternate names on the cert assigned to the trunk (uag.domain.com) didn't match what the Exchange server was expecting.

    I decided to try a new trunk with a copy of the Exchange certificate so I disabled the original trunk and created a new one after importing the existing Exchange certificate from a PFX file. While this corrected the cert errors I was getting with Outlook Anywhere, it appears to have broken my SSTP access. When I attempt to use the SSTP link in the UAG portal (in the new trunk), it starts the connection, the pop-up browser window closes and the status message in the notification area indicated that the connection was ended. Similarly when I attempt the connection using an SSTP VPN connectiod, it verifies my user name and password and then immediately disconnects and prompts me to reconnect.

    I'm guessing that the SSTP problem is caused by the fact that the subject name of the cert that I'm using on the new trunk doesn't match the name of the UAG server but I don't know how to fix it.

    Both uag.domain.com and mail.domain.com resolve to the same public IP.

    I'm kind of stuck here. It appears, at least to me with my limited knowledge here, that I have my choice, either put up with the Exchange cert errors on the orignal trunk and be able to connect via SSTP, or correct the cert errors and not be able to connect via SSTP.

    Any ideas?

    Thanks!


    Paul Adare CTO IdentIT Inc. ILM MVP
    Monday, March 15, 2010 10:07 AM

Answers

  • You could also consider a SAN certificiate with the appropriate entries (like your Exchange cert).

    If you decide to use public certs, this may be slightly cheaper or if you need to use EV certs (which don't support wildcard).

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    • Marked as answer by Paul Adare Tuesday, March 16, 2010 10:48 AM
    Monday, March 15, 2010 10:59 PM
  • Hi Paul,

     

    My understanding was that you resorted to using two different trunks just because you could not make it work flawlessly through one single trunk, and I assumed that you would rather use just one trunk. So my answer was intended to fix that scenario.

     

    When you configure SSTP on the UAG console, you’re requested to select the name of the trunk through which SSTP clients will connect. This setting decides on the SSL certificate that will be used in these connections, and that certificate must be valid in every aspect (Common Name, validity, trusted CA, CRL checking). So, if the trunk you selected has its Public host name setting set to uag.contoso.com, then the CN that the SSL certificate’s CN (wildcard or SAN) must match is that.

     

    On a client on which you’ve already attempted to use SSTP, you can open “Connect to a network” and then take a look at the UAG SSTP dialer properties: you will see the host name that this dialer is configured to connect to (which will be your trunk name)

     

    Now, you’re asking if the SSTP failure is because of the certificate name mismatch. It most probably is. Which, of course, does not mean that once you’ll get that sorted out, you won’t maybe encounter other issues with the SSTP configuration (for example: CRL checking ;-) )

     

    HTH,

    -Ran

    • Marked as answer by Paul Adare Tuesday, March 16, 2010 10:48 AM
    Tuesday, March 16, 2010 7:40 AM

All replies

  • Paul,

    I understand that SSTP is configured to connect to the trunk at uag.domain.com, and OA is configured for mail.domain.com.
    Why not use a *.domain.com certificate on the UAG portal trunk?

    BTW, this should work better even for OA publishing via UAG in itself, since OA is using more than just mail.domain.com for some of its web services, like the autodiscovery service.

    -Ran
    • Marked as answer by Erez Benari Monday, March 15, 2010 7:23 PM
    • Unmarked as answer by Paul Adare Tuesday, March 16, 2010 6:32 AM
    Monday, March 15, 2010 12:29 PM
  • You could also consider a SAN certificiate with the appropriate entries (like your Exchange cert).

    If you decide to use public certs, this may be slightly cheaper or if you need to use EV certs (which don't support wildcard).

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    • Marked as answer by Paul Adare Tuesday, March 16, 2010 10:48 AM
    Monday, March 15, 2010 10:59 PM
  • Ran and Jason,

    First, thanks for the responses, they are greatly appreciated.

    Ran, I'm not sure that you've followed my setup exactly. What I have is two trunks, only one of which is active at any given time (I've only got a single external IP address to work with so I can't have two trunks with the same IP address/port combination active at the same time). Both trunks have exactly the same things in the portal; an SSTP link, a link to OWA, and a pre-defined RDP link. The only difference between the two trunks is in the certificate used by the trunks:

    Trunk1 - has a cert with only a subject name of uag.domain.com. On this trunk, SSTP works as expected and OA works but with certificate errors that need to be acknowledged whenever Outlook is started outside of the network.

    Trunk2 - has a copy of my Exchange certificate which is a Unified Communication Cert (or SAN cert) that has a subject name of mail.domain.com and all of the SAN entries required by Exchange. On this trunk, SSTP does not work but I don't get the certificate errors when launching Outlook.

    I guess my first question is if my problem with SSTP is in fact because neither the subject name, nor any of the SAN names match the host name of the UAG server?

    Second question would be what exactly are the subject name/subject alternate name requirements for UAG, specifically for SSTP? Should SSTP work through UAG with an entry in the SAN of uag.domain.com even if the subject name is mail.domain.com? As I said I have my own internal PKI and I certainly know a thing or two about certificates and Certificate Services so I'm able to create whatever I need in the way of a certificate, my problem is that I'm just not sure what exactly it is that UAG needs for SSTP.

    The reason I stayed away from a wildcard certificate in the first place when setting up Exchange was at the time I was still using Outlook 2003 and Windows Mobile 5.0, neither of which support wildcard certs. Now that I'm using Outlook 2007 (soon to be 2010) and Windows Mobile 6.5 (hopefully Windows Phone 7 soon), I guess I could revisit the use of a wildcard cert.

    Jason, since no one outside of my company needs to access either my UAG server or my Exchange infrastructure, I have no need for public certs so cost isn't an issue here.

    I'm going to play around with some different certs today and see what I can come up but I am curious about the SSTP issue.

    As an aside, I seem to be running into a secondary issue when I disable one trunk and enable another and then apply the configuration. When I do so and then attempt to connect to the UAG box I get an error that listing the directory is not allowed and I have to perform an IISRESET to get things working again.


    Paul Adare CTO IdentIT Inc. ILM MVP
    Tuesday, March 16, 2010 6:55 AM
  • Hi Paul,

     

    My understanding was that you resorted to using two different trunks just because you could not make it work flawlessly through one single trunk, and I assumed that you would rather use just one trunk. So my answer was intended to fix that scenario.

     

    When you configure SSTP on the UAG console, you’re requested to select the name of the trunk through which SSTP clients will connect. This setting decides on the SSL certificate that will be used in these connections, and that certificate must be valid in every aspect (Common Name, validity, trusted CA, CRL checking). So, if the trunk you selected has its Public host name setting set to uag.contoso.com, then the CN that the SSL certificate’s CN (wildcard or SAN) must match is that.

     

    On a client on which you’ve already attempted to use SSTP, you can open “Connect to a network” and then take a look at the UAG SSTP dialer properties: you will see the host name that this dialer is configured to connect to (which will be your trunk name)

     

    Now, you’re asking if the SSTP failure is because of the certificate name mismatch. It most probably is. Which, of course, does not mean that once you’ll get that sorted out, you won’t maybe encounter other issues with the SSTP configuration (for example: CRL checking ;-) )

     

    HTH,

    -Ran

    • Marked as answer by Paul Adare Tuesday, March 16, 2010 10:48 AM
    Tuesday, March 16, 2010 7:40 AM
  • Once again, thanks to Ran and Jason. I now have everything working the way I want it to.

    I wound up generating a wildcard cert for my Exchange server (*.domain.com in both the subject and the SAN), configured Exchange and UAG to use this cert and now everything is working. OutlookAnywhere is happy with the cert, as is SSTP.

    Thanks again to both of you.


    Paul Adare CTO IdentIT Inc. ILM MVP
    Tuesday, March 16, 2010 10:48 AM
  • Cool - out of interest did you explore the SAN option?

    I am interested to know if there are any limitations with SAN certs when combined in the scenario you describe...

    Cheers

    JJ
    Jason Jones | Forefront MVP | Silversands Ltd
    Tuesday, March 16, 2010 1:08 PM
  • I'm not really sure what you mean Jason, though I'm game to try anything.

    Given a UAG box named uag.domain.com and an Exchange server named:

    External FQDN: mail.domain.com
    Internal FQDN: internal.domain.com
    NetBIOS Name: internal

    How would you like me to construct the certificate? Which names do you want to see where?


    Paul Adare CTO IdentIT Inc. ILM MVP
    Tuesday, March 16, 2010 1:20 PM