locked
Exchange 2010 and Multiple SSL Certificates RRS feed

  • Question

  • With the new rules for SSL certificates coming, we can no longer add alternate names for local domain names. For example:

    An exchange server has mail.mydomain.com and then an alternate of mail.mydomain.local.

    Certificates that go beyond 2014 will not accept alternate addresses like that anymore. Has anyone at Microsoft addressed this with Exchange? I cannot setup SSL with any SSL certs beyond 2014 because of this. It is clear that there must be a way to have TWO certificates. One for the true www address (mail.mydomain.com) AND one for mail.mydomain.local... the local intranet domain. My in-house certificate authority should be able to issue a certificate for this intranet domain and exchange should recognize both.

    NOTE: This is making exchange unusable. What can I do?

    Tuesday, July 24, 2012 4:46 PM

Answers

  • Exactly.  Then add all your external DNS entries for mydomain.com to it, substituting local IP addresses for Internet IP addresses where appropriate because DNS won't go looking to the Internet-based DNS if it can't find an entry for mydomain.com.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    • Proposed as answer by Fiona_Liao Wednesday, July 25, 2012 6:17 AM
    • Marked as answer by Fiona_Liao Friday, August 3, 2012 9:10 AM
    Tuesday, July 24, 2012 8:01 PM
  • With the new Cert rules taking effect in a few years, I cannot use a UCC cert that has localized domain names (not truly a real www domain). That is how the issue started.

    You would think the rules don't take place for a few years, so go ahead now, but the rules take affect NOW if you buy a multi-year cert that goes beyond the switch for the new rules (I.e. a 4 year UCC cert).

    Let me make that clear: alternate names that will not pass an authority chain to a recognized root authority are NOT ALLOWED in (I believe) 2014-15. If I bought a 2 year UCC cert, I could do that. If I buy a 3 or more years cert, I cannot. In other words, a four year UCC cert with mail.mydomain.com can no longer use mail.mydomain.local as an alternate address.

    Why?

    Because the "local" part, in reality, is an intranet name not internet and cannot be verified via a recognized root authority. So, your idea for alternate names will not work but temporarily for short-lived certs.

    Ed (and others). please NOTE: it was much more complicated than just a DNS issue because Exchange, by default, uses the local name for internal use (I.e. mail.mydomain.local). So, even though a used the DNS trick successfully, Outlook clients in the domain were getting invalid certificate errors because the names did not match.

    This CANNOT be corrected via the GUI and requires running an Exchange Powershell command-let to force exchange to use the public facing URL. Here is a web link with instructions:

    http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/

    I also ran into issues with Exchanges default IIS setup. I really don;t understand why nobody at Microsoft thinks that the most desired or most common configuration would be that an end-user should be able to type mail.mydomain.com from any browser and then be redirected to the exchange login page. That is NOT the case.

    The default is mail.mydomain.com/owa

    Why? Who wants to remember that obscure "owa" and have to teach everyone that?

    So, I also had to majorly fiddle with IIS to change the default redirect behavior as well as SSL Required settings to get the redirections to work, as I think, most end-users would want exchange to be configured.

    Anyway, Ed you sent me on the right track. It was a major pain, but it is working now.

    Thanks



    Wednesday, July 25, 2012 5:37 PM

All replies

  • It is absolutely not an Exchange problem, and there's nothing for Microsoft to do to "fix" it because it's completely in your hands.

    Simply deploy split-brain DNS.  Enter local IP addresses for your services in your internal DNS like mail.mydomain.com and quit using mail.mydomain.local or any other domain.local URLs for Exchange.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, July 24, 2012 4:53 PM
  • Sometimes the obvious solution is not noticed. Let me give that a try. And I will reply with the result. That seems like it should work just fine.

    Thanks

    Tuesday, July 24, 2012 5:04 PM
  • Okay, how do I add that in AD? I have a zone mydomain.local, but no zone for mydomain.com. Should I add a new zone mydomain.com and add the entry there? Or is there another way?
    Tuesday, July 24, 2012 5:10 PM
  • Exactly.  Then add all your external DNS entries for mydomain.com to it, substituting local IP addresses for Internet IP addresses where appropriate because DNS won't go looking to the Internet-based DNS if it can't find an entry for mydomain.com.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    • Proposed as answer by Fiona_Liao Wednesday, July 25, 2012 6:17 AM
    • Marked as answer by Fiona_Liao Friday, August 3, 2012 9:10 AM
    Tuesday, July 24, 2012 8:01 PM
  • I'd suggest you change another SAN certificate which contains all the alternate names you  need.

    Fiona Liao

    TechNet Community Support

    • Proposed as answer by Fiona_Liao Wednesday, July 25, 2012 6:18 AM
    Wednesday, July 25, 2012 6:18 AM
  • With the new Cert rules taking effect in a few years, I cannot use a UCC cert that has localized domain names (not truly a real www domain). That is how the issue started.

    You would think the rules don't take place for a few years, so go ahead now, but the rules take affect NOW if you buy a multi-year cert that goes beyond the switch for the new rules (I.e. a 4 year UCC cert).

    Let me make that clear: alternate names that will not pass an authority chain to a recognized root authority are NOT ALLOWED in (I believe) 2014-15. If I bought a 2 year UCC cert, I could do that. If I buy a 3 or more years cert, I cannot. In other words, a four year UCC cert with mail.mydomain.com can no longer use mail.mydomain.local as an alternate address.

    Why?

    Because the "local" part, in reality, is an intranet name not internet and cannot be verified via a recognized root authority. So, your idea for alternate names will not work but temporarily for short-lived certs.

    Ed (and others). please NOTE: it was much more complicated than just a DNS issue because Exchange, by default, uses the local name for internal use (I.e. mail.mydomain.local). So, even though a used the DNS trick successfully, Outlook clients in the domain were getting invalid certificate errors because the names did not match.

    This CANNOT be corrected via the GUI and requires running an Exchange Powershell command-let to force exchange to use the public facing URL. Here is a web link with instructions:

    http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/

    I also ran into issues with Exchanges default IIS setup. I really don;t understand why nobody at Microsoft thinks that the most desired or most common configuration would be that an end-user should be able to type mail.mydomain.com from any browser and then be redirected to the exchange login page. That is NOT the case.

    The default is mail.mydomain.com/owa

    Why? Who wants to remember that obscure "owa" and have to teach everyone that?

    So, I also had to majorly fiddle with IIS to change the default redirect behavior as well as SSL Required settings to get the redirections to work, as I think, most end-users would want exchange to be configured.

    Anyway, Ed you sent me on the right track. It was a major pain, but it is working now.

    Thanks



    Wednesday, July 25, 2012 5:37 PM
  • You're welcome.  Happy to have helped.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, July 25, 2012 6:55 PM
  • It is absolutely not an Exchange problem, and there's nothing for Microsoft to do to "fix" it because it's completely in your hands.

    Simply deploy split-brain DNS.  Enter local IP addresses for your services in your internal DNS like mail.mydomain.com and quit using mail.mydomain.local or any other domain.local URLs for Exchange.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Correct. It's an Outlook issue. Instead of replying on the trust in place between domain members via AD, Outlook is requesting validation of domain via an external method. One would assume that since Exchange creates a self-signed cert upon install is built upon it's knowledge of what currently exists in AD, Outlook should accept it since it uses this method to automatically build the user's profile, instead of suddenly falling back on the https/rpc method of connecting from outside the domain.

    Changing the OA's InternalUrl to match the ExternalUrl so a trusted 3rd party CA works seems counter-intuitive when the EMC defaults to internal/external for you and recommends saying with it. Using domain.local names has been a no-no for years, but going through something like this if you're in a closed network, i.e. banks, that only allows intra-company email it's a serious PITA especially when there seems to be no clear step-by-step provided. 

    Monday, October 12, 2015 3:42 PM