locked
Do we need SANs for Web Conferencing and Reverse Proxy Certs? We have 2 SIP domains.... RRS feed

  • Question

  • We are getting conflicting information. We are trying to migrate to OCS 2007 R2. We want both SIP domains to be able to use web conferencing.

    We currently use OCS 2007 R1, and when built that last year, we had set it up for both SIP domains to use Remote Access. However we only set up one domain to use web conferencing externally. 

    We understand that we need SANS for the Access Edge Cert. 
    Based on our testing it seems like you need SANs for both the Web Conf cert and the Reverse proxy cert too when you have multiple SIP domains. 

    In our external Live Meeting tests, we can see that if domain2 user sends an external web conferencing invite, that external user's client is looking for webconf.domain2.com. The Web Conf cert only has webconf.domain1.com. Wouldn't you need a SAN entry of webconf.domain2.com in your Web Conf certificate to allow this to work for the domain2 user? Also then would you apply the same principle for the Reverse Proxy cert?

    Wednesday, September 23, 2009 12:34 PM

Answers

  • Based on this blog entry it appears we don't need SANS on Webconf or RevProxy certs even with multiple domains. It uses the Access Edge Cert for authentication first (which needs the SANs) and then the app hand the FQDN of the WebConf and RevProxy back to the client.

    We test this and it works. 


    Additional SIP Domains

    But if an organization is required to support more than one SIP domain with Automatic Sign-In for external user access or for anonymous external Live Meeting access then the above cost savings comparisons are not as relevant.  Following is a brief review of why these two requirements might impact certificate costs.

    Assume the above configuration is in place with a single supported SIP domain of contoso.com.  Once a second SIP domain (fabrikam.com) is required for external access, then a whole chain of dependencies is put into place:

    1. If a user with a sign-in name in the additional SIP domain (jeff@fabrikam.com) needs to login externally via Edge using Automatic Configuration with Office Communicator then there will need to be a publicly-resolvable SRV record (_sip._tls.fabrikam.com) in the same domain as the OCS user’s sign-in domain.
    2. That SRV record must point to an A record in the same domain (sip.fabrikam.com), it cannot point to an A record in another domain (like sip.contoso.com) as then the Automatic Configuration process would fail.
    3. Because the OC client is given (via DNS) the hostname of sip.fabrikam.com to connect to for Access Edge services, the assigned certificate on that Edge server must include that hostname.  If it is currently only configured with a Common Name of sip.contoso.com then the OC client will fail to connect with a certificate name mismatch error.
    4. Additionally if that same user sends a Live Meeting initiation to a foreign party with the intention of having them join the meeting anonymously over the Internet, the sending user’s SIP domain (fabrikam.com) is what the anonymous user’s Live Meeting client will perform an SRV record lookup against.  This puts the anonymous Live Meeting client into the same scenario as the Office Communicator client using Automatic Configuration.

    This means that the Access Edge certificate needs to have entries for both SIP domains (sip.contoso.com and sip.fabrikam.com) moving it up into the more expensive SAN-certificate category.  But for the same reasons as shown in the process above the Web Conferencing Certificate does NOT require modification.  Only the Access Edge FQDN needs to be resolved in some way by clients and once a connection is made from the client, all other service FQDN values (Web Conferencing, A/V Conferencing, External Web Farm, etc) are passed in-band to the OC or LM client.  Regardless of what SIP domain a user signs in with (@fabrikam.com) the other services are all still configured with a single FQDN value using the original primary SIP domain (webconf.contoso.com,av.contoso.com).

    Wednesday, September 23, 2009 8:02 PM
  • Yes, that is correct.  Only the Access Edge certifcate uses additional SIP domains, and even then that certificate doesn't 100% 'require' them based on desired feature coverage.

    Based on your original scenario the Live Meeting client does not look for webconf.domain2.com, but looks for an SRV record in the domain2.com pointing to the Access Edge.  Once the LM client connects it is passed the webconf.domain.com FQDN.  There is no need to create external DNS records for the additional domains except for the standard 'sip.' records.

    FYI, The correct link for that article is: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=79
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, September 23, 2009 10:14 PM
    Moderator

All replies

  • From what I understand, Yes, you will require the second SIP domain on your certificates if you want to use it for WebConf.

    However, you may use your ISA reverse proxy as a HTTPS-HTTP bridge, and have certificates just for the ISA server (or your reverse proxy)
    Wednesday, September 23, 2009 7:40 PM
  • Based on this blog entry it appears we don't need SANS on Webconf or RevProxy certs even with multiple domains. It uses the Access Edge Cert for authentication first (which needs the SANs) and then the app hand the FQDN of the WebConf and RevProxy back to the client.

    We test this and it works. 


    Additional SIP Domains

    But if an organization is required to support more than one SIP domain with Automatic Sign-In for external user access or for anonymous external Live Meeting access then the above cost savings comparisons are not as relevant.  Following is a brief review of why these two requirements might impact certificate costs.

    Assume the above configuration is in place with a single supported SIP domain of contoso.com.  Once a second SIP domain (fabrikam.com) is required for external access, then a whole chain of dependencies is put into place:

    1. If a user with a sign-in name in the additional SIP domain (jeff@fabrikam.com) needs to login externally via Edge using Automatic Configuration with Office Communicator then there will need to be a publicly-resolvable SRV record (_sip._tls.fabrikam.com) in the same domain as the OCS user’s sign-in domain.
    2. That SRV record must point to an A record in the same domain (sip.fabrikam.com), it cannot point to an A record in another domain (like sip.contoso.com) as then the Automatic Configuration process would fail.
    3. Because the OC client is given (via DNS) the hostname of sip.fabrikam.com to connect to for Access Edge services, the assigned certificate on that Edge server must include that hostname.  If it is currently only configured with a Common Name of sip.contoso.com then the OC client will fail to connect with a certificate name mismatch error.
    4. Additionally if that same user sends a Live Meeting initiation to a foreign party with the intention of having them join the meeting anonymously over the Internet, the sending user’s SIP domain (fabrikam.com) is what the anonymous user’s Live Meeting client will perform an SRV record lookup against.  This puts the anonymous Live Meeting client into the same scenario as the Office Communicator client using Automatic Configuration.

    This means that the Access Edge certificate needs to have entries for both SIP domains (sip.contoso.com and sip.fabrikam.com) moving it up into the more expensive SAN-certificate category.  But for the same reasons as shown in the process above the Web Conferencing Certificate does NOT require modification.  Only the Access Edge FQDN needs to be resolved in some way by clients and once a connection is made from the client, all other service FQDN values (Web Conferencing, A/V Conferencing, External Web Farm, etc) are passed in-band to the OC or LM client.  Regardless of what SIP domain a user signs in with (@fabrikam.com) the other services are all still configured with a single FQDN value using the original primary SIP domain (webconf.contoso.com,av.contoso.com).

    Wednesday, September 23, 2009 8:02 PM
  • Yes, that is correct.  Only the Access Edge certifcate uses additional SIP domains, and even then that certificate doesn't 100% 'require' them based on desired feature coverage.

    Based on your original scenario the Live Meeting client does not look for webconf.domain2.com, but looks for an SRV record in the domain2.com pointing to the Access Edge.  Once the LM client connects it is passed the webconf.domain.com FQDN.  There is no need to create external DNS records for the additional domains except for the standard 'sip.' records.

    FYI, The correct link for that article is: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=79
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, September 23, 2009 10:14 PM
    Moderator