Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 28673 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
    hi Ifor,

    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.

    regards
    mod
  • 0
    Hi,

    1. Put also the internal name in your certificate, otherwise your internal Outlook clients will report "The name of the security certificate is invalid or does not match the name of the site". There is workaround, of course (MS KB 940726), but is more elegant this way.

    2. One SAN cert with up to 5 names would be enough. Look at Goddady, last time I bought one it cost 150$.

    3. It doesn't matter, I usually put webmail FQDN and other names in Subject Alternative Names.
  • 0
    hi vilic,

    this is just for internal clients and internal certificates. I've never used internal server names for certificates that are accessible just from external.

    There is no reason to publish internal names to external Clients if you use any reverseproxy.

    regards
    mod
  • 0
    I assumed that the same certificate will be imported also to internal Exchange server to replace default self-signed one. I always do that in my Exchange implementations.
  • 0 in reply to vilic
    I assumed that the same certificate will be imported also to internal Exchange server to replace default self-signed one. I always do that in my Exchange implementations.


    This is working but it's a security risk. You just need this, if you use a nat rule instead of a reverse Proxy.

    But, just a nat rule, is a bigger security risk as publishing internal server names [;)]
  • 0
    Most of my clients wants to use the same FQDN for internal as external OWA access, in that case split DNS and import certificate on Exchange server must be used.
  • 0
    Split dns don't need internal server names. With split dns you can use the external server names for internal resources.
  • 0
    Yes, but in order to avoid security warnings in internal client browsers certificate with public FQDN should be uploaded to Exchange server...[;)]
  • 0 in reply to vilic
    Yes, but in order to avoid security warnings in internal client browsers certificate with public FQDN should be uploaded to Exchange server...[[;)]]


    That's right. But you don't need the internal server names in this external san cert  [[;)]]
  • 0
    You need it...[[;)]]

    Because once you upload certificate to Exchange server, your Outlook clients will start to report "The name of the security certificate is invalid or does not match the name of the site" because Client Access Service is published in AD with internal Exchange name.

    Now we are back to beggining..[[;)]]
Unfiltered HTML