Announcement

Collapse
No announcement yet.

SSL Certs for multiple domains

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SSL Certs for multiple domains

    Hello
    We are running an exch2k3 server (win2k3 domain) fully patched.
    We have 3 domains that we're hosting email for on our exchange server. (1 is active, the other 2 are going to be re directed to our exch server within a week) I would like to implement SSL on our exchange server but before I do, i have a question

    If i have emails for domainA, DomainB and DomainC being delievered to our exchange server, would I need 3 different SSL certs or can I purchase 1 SSL cert for all 3 domains?

    thanks
    Jamie

  • #2
    Re: SSL Certs for multiple domains

    You can get a Subject Alternative Name (SAN) certificate if you need to
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    PhD, MSc, FIAP, MIITT
    IT Trainer / Consultant
    Ossian Ltd
    Scotland

    ** Remember to give credit where credit is due and leave reputation points where appropriate **

    Comment


    • #3
      Re: SSL Certs for multiple domains

      Do you have 3 different sets of users or is it all one company but they also receive from other addresses?
      cheers
      Andy

      Please read this before you post:


      Quis custodiet ipsos custodes?

      Comment


      • #4
        Re: SSL Certs for multiple domains

        The domains that you have on the server have nothing to do with IIS on Exchange 2003. IIS doesn't care.

        For multiple domains I usually use a single host name for everything. The same name is used for the MX records, ActiveSync, RPC over HTTPS and OWA. A single certificate with that name on it.

        Multiple certificates etc is a vanity setting, makes no difference at all to the operation of the server.

        Simon.
        --
        Simon Butler
        Exchange MVP

        Blog: http://blog.sembee.co.uk/
        More Exchange Content: http://exchange.sembee.info/
        Exchange Resources List: http://exbpa.com/
        In the UK? Hire me: http://www.sembee.co.uk/

        Sembee is a registered trademark, used here with permission.

        Comment


        • #5
          Re: SSL Certs for multiple domains

          Hmm, i'm a little confused.

          In prior experience working with 1 domain and an exch server - i would normally create mail.domain.com for a company. Then i would purchase an SSL cert for https for owa.

          in this case, i have domainA , domainB and domainC. all 3 companies use one mail server. we have users who have email addy's for domaina, domainb and domainc.

          how can i use 1 host name for all 3 domains ? for example ...
          if i have created mail.domainA.com for OWA, users in that company would go to mail.domainA.com .. users who have email addy's of @domainB.com - i have created an A record for mail.domainB.com and so forth.

          are you suggesting that if i create mail.domain.com on all 3 domains, point it to my exchange server, users would be able to access OWA that way? if thats the case, thats pretty cool - i never thought of it that way. i was under the assumption that each domain had to have its own unique A record for OWA.

          then i would probably only need just 1 ssl cert for https access

          Comment


          • #6
            Re: SSL Certs for multiple domains

            Sembee is right. This is how we do it. We are an ASP/Email Hosting company hosting email for about 100 companies (150 domains) and we use one A record, one MX record, and one SSL certificate: mail.company.com. All of our customers create an MX record in their DNS namespace that points to my mail.company.com A record. IIS and Exchange do not care what the A and MX records are or what name is on the certificate.

            All user connect via OWA, RPC over HTTPS, or Activesync using https://mail.company.com. When they provide their AD credentials Exchange connects them to their mailbox.

            Comment


            • #7
              Re: SSL Certs for multiple domains

              Ahh - very cool. I was not aware you could do that.
              Now here's another question

              We currently have an SSL cert for our web server that we're going to be implementing. (SSL cert is a digicert certificate) can I use the same cert for https access as well??

              Comment


              • #8
                Re: SSL Certs for multiple domains

                Originally posted by joeqwerty View Post
                Sembee is right. This is how we do it. We are an ASP/Email Hosting company hosting email for about 100 companies (150 domains) and we use one A record, one MX record, and one SSL certificate: mail.company.com. All of our customers create an MX record in their DNS namespace that points to my mail.company.com A record. IIS and Exchange do not care what the A and MX records are or what name is on the certificate.

                All user connect via OWA, RPC over HTTPS, or Activesync using https://mail.company.com. When they provide their AD credentials Exchange connects them to their mailbox.
                Glad I found this thread, I've come up with a similar plan myself. I have a highly-related question or two that should add nicely to the knowledge here. I plan on doing exactly as quoted; we are adding a second DNS name for mail that we'll be hosting for our new sister franchise. We too use SSL and RPC over HTTP.

                Q1: I originally purchased the new domain as an alias. I realize now that this is not the same as pointing everything to one A record with the MX record, as explained here. Or is it?

                Q2: My server's domain is different internally on the network vs. externally to the world. To set up the first domain, I used a registry-edit tool that I believe DanielP posted in this forum or the Petri KB, to make the server answer on SMTP for mail coming to the external domain. Because of the MX redirect method suggested in this thread for adding more domains, my original DNS tweak will now also answer for the new mail domain, and I don't need to use the registry edit again to add the new domain, correct?

                Q3. The new sister company has a different company name and e-mail address, naturally. I know it's just a vanity thing... but will all this be transparent to the users? I.e., when they give their e-mail address out to local contacts (hundreds of miles from our franchise) or e-mail each other, will their addies, mailboxes, etc. all say "[email protected]"? As long as I add "@domainB.com" to AD and populate it with the correct users?

                I get the feeling there's a lot more going on in the AD side of things to make this work... different OUs etc.

                Comment


                • #9
                  Re: SSL Certs for multiple domains

                  A1. I'm not sure what an "alias" domain is. Can you explain more? In any event, as long as the MX record points to a valid A record you should be good. The way I like to do it is this:

                  I have an A record and an MX record in my DNS for my Exchange server (hosting email for multiple companies and domain names). All my customers have MX records that point to the A record of my Exchange server using my A record name. For instance my A record is mail.mycompany.com, the customer creates an MX record in their DNS that points to mail.mycompany.com instead of mail.theircompany.com. That way they don't have to create corresponding A records and if I change things such as the ip address of mail.company.com they don't have to change anything.

                  A2. I'm not sure what registry change you made but it's totally unneccessary for Exchange. You should set up Recipient Policies in Exchange for each domain that you host email for. The Recipient Policy tells Exchange to accept email for that domain.

                  A3. When you create your Recipient Policies, you should create a different policy for the sister company if they want to retain their "public identity" in terms of what email addresses they use and what their customer's "see". The Recipient Policy will tell Exchange what email addresses to apply to each user and which address is the primary SMTP address. All emails will go out as the primary SMTP address.

                  Comment


                  • #10
                    Re: SSL Certs for multiple domains

                    Originally posted by joeqwerty View Post
                    A1. I'm not sure what an "alias" domain is. Can you explain more? In any event, as long as the MX record points to a valid A record you should be good.
                    Our ISP is also the company selling the domain, and they let us manage our own external DNS with them, via a web portal. Inside, they have a KB that says this about aliasing:

                    Originally posted by ISP KB
                    Domain aliasing allows you to host a Web site on one domain and point other domain names to the site... For e-mailboxes, you even have the option of re-directing messages sent to an e-mailbox under one alias to different e-mailboxes under your primary domain... Domain aliases are also referred to as domain forwarding or domain pointers.
                    However, I am in our DNS portal now, and it appears that all I did was buy a domain which has it's own MX and A records, etc. Perfect! So all that means is setup is incomplete... I need to assign one of our IPs to the new "alias" domain's A record, but then put in my original mail domain under its MX record.

                    Originally posted by joeqwerty View Post
                    A2. I'm not sure what registry change you made but it's totally unneccessary for Exchange. You should set up Recipient Policies in Exchange for each domain that you host email for. The Recipient Policy tells Exchange to accept email for that domain.
                    This was a couple of years ago now... I've been lurking Petri for a long time. I think the registry change tool may have actually been to make RPC over HTTP connect to the server, even though the internal domain name was different. It may have had something to do with the SSL certificate, which was for the external domain. Or it may have had something to do with the fact that our Exchange server is back-end only; there is no front-end machine. As long as I get the Recipient Policy right (thank you, that's the name I was searching for), it sounds like I don't have to do a single thing to RPC over HTTP, SSL etc. etc.

                    Originally posted by joeqwerty View Post
                    A3. When you create your Recipient Policies, you should create a different policy for the sister company if they want to retain their "public identity" in terms of what email addresses they use and what their customer's "see". The Recipient Policy will tell Exchange what email addresses to apply to each user and which address is the primary SMTP address. All emails will go out as the primary SMTP address.
                    Excellent, thank you! It sounds then like everything needs to be done just in the Exchange system manager. On mine, DomainA is the default policy, so I would be creating a new policy beside that for DomainB if I understand. After that, all I need to do is have them type in their DomainB address when configuring their Outlook client, correct?

                    Comment


                    • #11
                      Re: SSL Certs for multiple domains

                      Originally posted by rprovise View Post
                      Our ISP is also the company selling the domain, and they let us manage our own external DNS with them, via a web portal. Inside, they have a KB that says this about aliasing:

                      Domain forwarding, now that's a term I'm familiar with. Thanks for clearing it up.

                      However, I am in our DNS portal now, and it appears that all I did was buy a domain which has it's own MX and A records, etc. Perfect! So all that means is setup is incomplete... I need to assign one of our IPs to the new "alias" domain's A record, but then put in my original mail domain under its MX record.

                      Without making things more confusing you could have it one of two ways:

                      The old domain is xyz.com and the new domain is 123.com. In the 123.com DNS zone you create an A record for your email server called mail.123.com that resolves to the ip address of your email server and then create an MX record that points to mail.123.com.

                      OR

                      You simply create the MX record in the 123.com domain as mail.xyz.com and forget about the A record. That way MX queries get resolved to mail.xyz.com, which gets resolved to the A record and ip address in the xyz.com DNS zone.

                      This was a couple of years ago now... I've been lurking Petri for a long time. I think the registry change tool may have actually been to make RPC over HTTP connect to the server, even though the internal domain name was different. It may have had something to do with the SSL certificate, which was for the external domain. Or it may have had something to do with the fact that our Exchange server is back-end only; there is no front-end machine. As long as I get the Recipient Policy right (thank you, that's the name I was searching for), it sounds like I don't have to do a single thing to RPC over HTTP, SSL etc. etc.

                      OK, you're talking about the RPC proxy ports for the Exchange server NetBIOS and FQDN names because the server is acting as both the backend and frontend server. I have the same setup.

                      Excellent, thank you! It sounds then like everything needs to be done just in the Exchange system manager. On mine, DomainA is the default policy, so I would be creating a new policy beside that for DomainB if I understand. After that, all I need to do is have them type in their DomainB address when configuring their Outlook client, correct?

                      Correct. The only issue is in creating the correct filter for the Recipient Policy so that it applies only to those users. Take note that Recipient Policies are processed in a "top down" fashion so the first Recipient Policy that matches a user is the one that applies to that user and all others are ignored. This will probably mean creating two Recipient Policies, one for xyz.com and another for 123.com and using the appropriate filters for each.
                      Hopefully I haven't made this confusing to understand.
                      Last edited by joeqwerty; 12th August 2009, 23:32.

                      Comment


                      • #12
                        Re: SSL Certs for multiple domains

                        Originally posted by joeqwerty View Post
                        Hopefully I haven't made this confusing to understand.
                        No, not at all. This may be my first run-through with this exact configuration, but I understand everything you're saying and it's crystal clear. I too was beginning to realize the A record in 123.com was serving no purpose ("Where else is mail.123.com referred to? Nowhere, that's where."), so I axed it and just left the MX record pointing to the first domain's A record where the Exchange mail enters.

                        Yes you're right, I remember that now. I was creating proxy ports for RPC over HTTP.

                        Originally posted by joeqwerty
                        Correct. The only issue is in creating the correct filter for the Recipient Policy so that it applies only to those users. Take note that Recipient Policies are processed in a "top down" fashion so the first Recipient Policy that matches a user is the one that applies to that user and all others are ignored. This will probably mean creating two Recipient Policies, one for xyz.com and another for 123.com and using the appropriate filters for each.
                        Two questions about this:
                        Q1: Can the default policy included in Exchange 2003 standard be one of the policies, or do I have to get rid of that to have 2 side by side?
                        Q2: If I can keep the default policy for the old XYZ.com mail, any chance of me screwing up mail delivery to my original users when I apply a filter to their policy?

                        I've already worked with filters for the GAL address list for this, so I think I can figure out the filter criteria.

                        Comment


                        • #13
                          Re: SSL Certs for multiple domains

                          The problem with the Default policy is that it's kind of a special case. It gets applied to all users no matter what. You don't want to mess with filtering or security on the default policy as it could break things as I believe it's hooked in to the user UPN for each user. My recommendation would be to create a new policy for both the old and the new domains.

                          Comment


                          • #14
                            Re: SSL Certs for multiple domains

                            Ah ok. I understand now, and after I played with the default policy a little, I realized it wasn't going to let me add filter rules anyway.

                            Can I have a default policy with nothing in it? The trouble is, my default policy currently holds old internal domain address @XYZ.local (not set to default), and external domain address @XYZ.com.

                            It seems like I would need to delete @XYZ.com from the default policy to make a new policy with a filter for it. It also seems like I would need to delete @XYZ.local because otherwise it will be the default address in the default policy, taking precedence over the new @123.com domain policy.

                            Finally, I have to figure out a way to to this without disrupting about 25 users whose addresses are attached to the default policy. If I can have two policies for the same addresses at once, maybe I can make a new custom @XYZ.com policy first, then add the filter, then delete @XYZ.com from the default policy.

                            What's the worst that could happen?

                            After that, maybe I can delete the @XYZ.local and add the @123.com policy for the new domain.

                            Comment


                            • #15
                              Re: SSL Certs for multiple domains

                              While it's a fact that the default policy applies to all users, any custom policy takes precedence because it will have a higher priority, so the primary SMTP address in the default policy will not over-rule the primary SMTP address in the custom policy.

                              You can simply remove the xyz.com address from the default policy and add it to your custom policy. The recipient update service runs every 15 minutes (the RUS updates email addresses and populates address lists). This should give you enough time to make the change to the policies. I can't see anything bad happening as you're not removing the email addresses your just changing which policy applies them.

                              This is all assuming that your internal DNS namespace is xyz.local (or something like it) and xyz.com is an additional email domain that you added to the default policy. Is that correct? If that's not correct and xyz.com is the internal DNS namespace then it might be trickier as I've never mucked with the default policy. If that's the case then leave it as it is, create a new policy for 123.com and it will take precedence over the default policy. What this means is that the default policy will give them an xyz.com email address and the custom policy will give them a 123.com email address as the primary address. Sorry, I forgot about the precedence/priority of the policies. The default policy will still apply to all non-123.com users.

                              We host email for about 100 companies which means 100 different domain names, recipient policies, address lists, etc.

                              Comment

                              Working...
                              X