none
Exchange 2010 UCC SSL Certificate RRS feed

  • Question

  • Hi,

    About to renew my SSL UCC however wondering if ANY internal domains are required?  I'm fully aware of external ones required, however is internal one required for autodiscover to work.   All my settings are correct for internal and external..

    I'm not 100% how autodiscover internally works, via AD i assume?  I guess one option is to have internal DNS to re-direct external URLs?

    Thx!

    Friday, June 8, 2012 5:11 PM

Answers

  • it is possible to have none of the internal domains listed on the certificate, IF you are running a split DNS system and do not have Unified Communications in use.
    You would need to change all of the URLs to use the external host names and ensure that the external host names resolve internally to the internal IP address.

    You don't need to have the RPC CAS Array on the SSL certificate.

    Internally, autodiscover works on the value of AutodiscoverServiceInternalURI which is set on set-clientaccessserver. By default that host name is the real name of the server holding the Client Access Role.

    You can change it to another URL if you wish, and as long as that resolves and is in the SSL certificate as one of the host names, then it will work correctly.

    http://exchange.sembee.info/2010/cas/autodiscover.asp

    If you are using the UC role, or Lync then you will need to have the server's NETBIOS and FQDN in the certificate, otherwise Exchange will use a self signed SSL certificate.

    The other complication can be internal users who know the internal name, getting SSL prompts after the change.

    When it comes to SSL certificate providers, I use https://certificatesforexchange.com/ because it is cheap. Digicert have a nice wizard for Exchange 2007, that is true, but completely unnecessary for Exchange 2010.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    • Proposed as answer by Fiona_Liao Monday, June 11, 2012 8:45 AM
    • Marked as answer by Fiona_Liao Tuesday, June 26, 2012 7:01 AM
    Friday, June 8, 2012 8:16 PM
  • Hi

    Yes internal is required, I suggest you register the following internally,

    Servername.domain.local

    Autodiscover.domain.local

    and create an internal dns deleagation for autodiscover to your exchange server's IP Address.

    I prefer Digicert, makes it much easier with the SAN names and also simplifies the process of ordering....

    Thanks

    Ahmed

    Praxis Computing

    • Proposed as answer by Fiona_Liao Monday, June 11, 2012 8:45 AM
    • Marked as answer by Fiona_Liao Tuesday, June 26, 2012 7:01 AM
    Friday, June 8, 2012 7:07 PM

All replies

  • Hi

    Yes internal is required, I suggest you register the following internally,

    Servername.domain.local

    Autodiscover.domain.local

    and create an internal dns deleagation for autodiscover to your exchange server's IP Address.

    I prefer Digicert, makes it much easier with the SAN names and also simplifies the process of ordering....

    Thanks

    Ahmed

    Praxis Computing

    • Proposed as answer by Fiona_Liao Monday, June 11, 2012 8:45 AM
    • Marked as answer by Fiona_Liao Tuesday, June 26, 2012 7:01 AM
    Friday, June 8, 2012 7:07 PM
  • oops missed your point about redirecting the internal URL's to the the external URLS, yes that will work, but I suggest you don't it's a mission and its tedious simplest route is just to get the san names for the internal server name
    Friday, June 8, 2012 7:09 PM
  • it is possible to have none of the internal domains listed on the certificate, IF you are running a split DNS system and do not have Unified Communications in use.
    You would need to change all of the URLs to use the external host names and ensure that the external host names resolve internally to the internal IP address.

    You don't need to have the RPC CAS Array on the SSL certificate.

    Internally, autodiscover works on the value of AutodiscoverServiceInternalURI which is set on set-clientaccessserver. By default that host name is the real name of the server holding the Client Access Role.

    You can change it to another URL if you wish, and as long as that resolves and is in the SSL certificate as one of the host names, then it will work correctly.

    http://exchange.sembee.info/2010/cas/autodiscover.asp

    If you are using the UC role, or Lync then you will need to have the server's NETBIOS and FQDN in the certificate, otherwise Exchange will use a self signed SSL certificate.

    The other complication can be internal users who know the internal name, getting SSL prompts after the change.

    When it comes to SSL certificate providers, I use https://certificatesforexchange.com/ because it is cheap. Digicert have a nice wizard for Exchange 2007, that is true, but completely unnecessary for Exchange 2010.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    • Proposed as answer by Fiona_Liao Monday, June 11, 2012 8:45 AM
    • Marked as answer by Fiona_Liao Tuesday, June 26, 2012 7:01 AM
    Friday, June 8, 2012 8:16 PM
  • Please be aware that Certificate Authorities are phasing out the issuance of certs for internal names, and you should not configure internal domain names in the UCC certificate.  See the whole story at http://www.digicert.com/internal-names.htm

    After November 1, 2015 Certificates for Internal Names Will No Longer Be Trusted

    The CA/Browser Forum (CAB) is a collaborative effort between Certificate Authorities (companies like DigiCert® that issue certificates) and web browsers (companies like Mozilla or Microsoft that manage CA trust). In 2011, the CAB introduced new requirements for certificate issuance.

    As part of these new requirements, Certificate Authorities (CAs) must phase out the issuance of certificates for internal server names and reserved IP address by October, 2016. Starting in 2012, all CAs no longer issue internal name certificates that expire after November 1, 2015. Notification of these new requirements must be provided to any customer who attempts to purchase an internal name certificate during the phasing out period (July 2012 - November 2015).

    In short, after 2015 it will be impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as owned by the organization that is requesting the certificate.

    Friday, January 18, 2013 6:31 PM