SAN names and Multiple sip domains issue RRS feed

  • Question

  • We are experiencing issues with our current OCS deployment and think we may be onto something, but just want to verify we're on the right path.


    We have a Standard Edition Server called StandardServer

    Edge Server called EdgeServer

    We use a split DNS infrastructure, so we have two sip domains, Internal.company.com and external.company.com


    Currently we are experiencing TLS Connect Issues on the Validation wizard on both the Edge and Front End server, the error is Connection TIme Out.


    We just noticed that while our Edge Server cert has a SAN of both Sip domains, our Front End Server does not, it only has the internal Sip domain name in the SAN field. 


    We think that this may be the problem here, that we need a new cert for the Front End Server with sip.internalcompany.com and sip.externalcompany.com in the SAN field to make TLS function between the servers.

    If not, does anyone else have any other ideas to try?





    Wednesday, November 14, 2007 6:14 PM

All replies

  • Are you attempting to bind a single certificate to all 4 Edge roles: Internal, Access, Webconf, and A/V?


    Typically you can assign an internally-requested certificate to the Internal Interface using the FQDN of the Edge server as the Subject Name, then assign certificates issued by a trusted third-party to the remaining three roles for external client connectivity.


    Wednesday, November 14, 2007 7:11 PM
  • Currently we are only attempting the Access Edge Server for Public IM. We are using a self signed cert with known outside clients who trust our Internal CA for a proof of concept.


    It looks to me like the TLS encryption is not working now as one certificate has Subject Alternative names for both sip domains (our edge server) and our Front End Server only has the Internal sip domain listed as a san.


    We just wanted to make sure this is teh case before replacing a cert from a prodction machine to potentially impact users unnecessarily.

    Wednesday, November 14, 2007 7:36 PM