Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 28676 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Certificates required - WAF for MS Exchange

Ifor Davies
Hi folks

Sorry if this sounds trivial, but this is the first time I've used the Web Application Firewall for a production system using proper certificates, and I want to make sure I'm not about to make an expensive mistake!

I've followed the Sophos document on how to configure the UTM 9.2 WAF for Exchange connectivity, and I've got it to work using private certificates. I now want to replace my home-brew certificates with one(s) from one of the major certificate authorities. My question is - what do I need?

I've got three virtual servers configured:
  autodiscover..com
  outlook..com
  webservices..com

1. Do I just need certificates to cover the above external names, or do I need to worry about the internal DNS names for the exchange server as well?

2. Three separate certificates (which is what I used while testing) or one SAN certificate? Does it matter?

3. If a SAN certificate, does it matter which name goes in the subject field? (as you can guess, I'm not too knowledgeable about SAN certificates...)

Any other problems or "gotcha"s that I should be aware of when buying certificates for use with Sophos UTM?

Thanks for any guidance anyone can give...
Ifor


This thread was automatically locked due to age.
  • 0
    Let me correct myself, you don't need it if you do procedure described in MS KB940726, and I did that procedure so many times with single name Exchange SSL certs.

    But if a client is buying new SAN certificate it is more elegant solution and less chance to misconfigure something, especially if they are not very experienced in Exchange administration.
  • 0
    Every Consultant has his own prefered solution. 

    My prefered solution is "never use internal names in external accessible certificates" [;)]
  • 0 in reply to mod2402
    By the way... Where do you buy your Certificates? I've found https://www.cheapsslshop.com where a Wildcard SSL Certificate can be bought for 316$ for four years. That's so far the cheapest one, I've found. Does anybody allready bought a certificate at cheapsslshop?

    Please send me Spam gueselkuebel@sg-utm.also-solutions.ch

  • 0
    For low cost certificates I use https://www.ssls.com. Single name SSL (COMODO) is 9$/y.
    Similar price for wildcard as in your link.

    Unfortunately they don't issue SAN certificates, for that I use Godaddy (150$/y for up to 5 names).
  • 0
    Thanks mod2402 and vilic - I think I've got it now:

    To get the reverse proxy/Exchange stuff working properly, I just need certificates (SAN or otherwise) that cover the external host names

    However, if I use a SAN certificate that also includes the internal host names:
    - On the plus side, the internal clients won't show certificate errors
    - On the minus side, the internal host names will be on the Internet for all and sundry to see

    Is this a fair summary?
  • 0 in reply to Ifor Davies
    Thanks mod2402 and vilic - I think I've got it now:

    To get the reverse proxy/Exchange stuff working properly, I just need certificates (SAN or otherwise) that cover the external host names

    However, if I use a SAN certificate that also includes the internal host names:
    - On the plus side, the internal clients won't show certificate errors
    - On the minus side, the internal host names will be on the Internet for all and sundry to see

    Is this a fair summary?


    You don't need internal hostnames. Please read the kb article:

    Outlook 2007 security warning: "The name of the security certificate is invalid or does not match the name of the site"

    But, as I mentioned before...
    Every Consultant has his own prefered solution. 

    My prefered solution is "never use internal names in external accessible certificates" [;)]
  • 0
    Ifor, here is the summary of Powershell commands (kb940726) for your reference, that you have to run on your Exchange server if you import certificate which does not contain internal server name.

    If you decide not to import it, educate your users to use different urls when accessing OWA internally and externally. 

    Set-OWAVirtualDirectory EX2010\OWA* -ExternalURL https://mail.company.com/OWA

    

    Set-OWAVirtualDirectory EX2010\OWA* -InternalURL https://mail.company.com/OWA

    

    Set-ClientAccessServer -Identity EX2010 -AutodiscoverServiceInternalUri mail.company.com/.../autodiscover.xml

    

    Set-WebServicesVirtualDirectory -Identity "EX2010\EWS (Default Web Site)" -InternalUrl mail.company.com/.../exchange.asmx

    

    Set-OABVirtualDirectory -Identity "EX2010\oab (Default Web Site)" -InternalUrl https://mail.company.com/oab

    

    Set-ECPVirtualDirectory EX2010\ECP* -ExternalURL https://mail.company.com/ECP

    

    Set-ECPVirtualDirectory EX2010\ECP* -InternalURL https://mail.company.com/ECP

    

    Set-ActiveSyncVirtualDirectory EX2010\Microsoft-Server-Activesync -ExternalURL mail.company.com/Microsoft-Server-Activesync

    

    Set-ActiveSyncVirtualDirectory EX2010\Microsoft-Server-Activesync -InternalURL mail.company.com/Microsoft-Server-Activesync
  • 0 in reply to Ifor Davies
    Thanks mod2402 and vilic - I think I've got it now:

    To get the reverse proxy/Exchange stuff working properly, I just need certificates (SAN or otherwise) that cover the external host names

    However, if I use a SAN certificate that also includes the internal host names:
    - On the plus side, the internal clients won't show certificate errors
    - On the minus side, the internal host names will be on the Internet for all and sundry to see

    Is this a fair summary?


    See this:
    https://www.bluessl.com/en/help/internal-server-names

    1. july 2012 will certificate providers no longer issue internal names. Off course you can do self issued, but as mod2402 and vilic says, you will have to use both name for internal and external setup for Outlook Anywhere a.s.o.

    You setup split-dns internally so EVERYBODY use the external names, here is a script that can do this for you:

    Script for Configuring Exchange 2010 Internal and External URLs | msunified.net

    The above for Exchange 2007 and 2010 [[;)]]

    Split DNS:

    Internally point EXTERNAL names to the INTERNAL MAILSERVER IP on the INTERNAL DNS SERVER

    Externally point EXTERNAL names to the EXTERNAL MAILSERVER IP on the EXTERNAL DNS SERVER. (Your domain provider)

    If you do this and ex. you use Outlook Anywhere, their configuration will work internally AND externally, without the need to change anything [[;)]]

    AND with NO certificate warnings at all...

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v20 Technician

  • 0 in reply to mod2402
    you can use a wildcard cert, a san cert or three different web server certs. Choose one way, that is right for you. All three variations will work. Internal names should not be included.


    There is evidence that wildcard certificates do not play nice with ActiveSync endpoints.  If you have a company policy for just one type of phone, and you test with a self-signed wildcard certificate and it is okay, then okay.   Otherwise I suggest it is wiser to stick to a SAN cert of separate certs.  See following link for details: 
    Exchangepedia | Which name should I use as Common Name for my UC certificate?
     
    *SPLIT BRAIN* 
    Quite separately this is an awesome resource on how to do split brain from an author of tremendous help articles on Exchange:
    http://exchangeserverpro.com/avoiding-exchange-2013-server-names-ssl-certificates/

    I have 22 other URLs all to do with the thorny issue of certificates, exchange and WAF.  Probably worth another thread on "resources useful for deploying WAF on exchange".

    BR Adrien.
Unfiltered HTML