locked
Planning for certificates RRS feed

  • Question

  •  

    Hi,

    I'm planning a deployment of a standard edition with a consolidated edge topology.

     

    The pool i namned with the default FQDN of the server and active directory domain. And the sip domain is company.com

    Is it correct that the certificate for the ocs server should look like this:

     

    Common name = FQDN of the pool

    SAN = sip.companyname.com

     

    For the addressbook url the names are as follows:

     

    internal url FQDN : same as pool

    External url FQDN : content.companyname.com (this is the dns record pointing to the reverse proxy)

     

    For the above I create a certificate with the poolname as the common name and the external name as the SAN. This certifcate is assigned to the default web in the IIS. It is also exported and installed on the ISA server for the publishing rule.

     

     

    Edge:

     

    1 certificate with internal name of the edge server interface

    1 certificate with the name of external sip FQDN

    1 certificate with the name of the webconference external FQDN

     

    Does any of this make any sense at all or am I complication things?

    Sunday, November 11, 2007 7:17 PM

All replies

  • It looks like you are on the right path, but keep an eye out for a few snags along the way if you plan to use ISA Server 2006 for the Address Book reverse HTTP proxy, which does not correctly support the Subject Alternative Name field.  When certificates are used for SSL bridging with Web and Client Access publishing rules, the FIRST entry in the multi-valued SAN field must match the FQDN used for the internal portion of the bridging connection.  ISA 2006 will ignore the Subject Name value if the SAN is populated, so the recommendation is to set the first SAN value equal to the Subject Name and then ISA will appear to behave correctly.

     

    When you use the OCS Certificate Wizard you cannot manually configure the end result of the Subject Alterntive Name field as the wizard will insert your SIP domain FQDN first. The internally issued certificate bound to the front-end service and IIS site cannot be changed to match the external web farm name, but must retain the server (or pool) FQDN for secure internal Office Communicator connections using TLS.

     

    Here’s more details regarding this issue from the ISA team:

    http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspx

     

    What I have done is setup SSL bridging using two seperate certificates.  The first certificate that was originally configured and assigned to the IIS Web Site on the OCS front-end was copied (along with the internal CA Root cert) to my ISA server.  Then I issued a second certificate to the ISA server with the Subject Name of abs.domain.com with a blank SAN and bound this certificate to my web listener.
    Sunday, November 11, 2007 8:08 PM
    Moderator
  • Hi Jeff!

    Thanks for the reply and tips on the ISA configuration!!

     

    Rgrds

    Henrik

     

    Monday, November 12, 2007 5:27 PM
  • Hello Jeff,

     

    I am in process of configuring certificate for my reverse proxy server ISA 2006 to setup ssl bridging using two separate certificates.

     

    Please Note: This is a test environment.

     

    Front-End Server:

     

    Front-end server is member of domain testing.local.

    The subject name and subject alternative name on my certificate which I am using for my front-end and IIS server are as follow:

    Subject Name:

    Pool1.testing.local

    Subject Alternative Name:

    sip.testing.local
    OCS2007.testing.local
    Pool1.testing.local 

     

    Reverse Proxy Server: ISA 2006

     

    ISA Server is member of a workgroup WORKGROUP. I am using same IP network for both Workgroup and Domain to avoid IP routing issues.

     

    abs.testing.local (External name, the users will use to connect to the IIS website which is running on the internal OCS Front-end server).  

     

    This is what I am thinking, please correct me if I am going to the wrong direction.

     

    1. I need to issue a certificate to the ISA server with the subject name of abs.testing.local. 

    2. I also need to export the root CA certificate from my internal CA and import it into the Trusted Root Certification Authorities store on the ISA computer. 

     

    Now as per your statement "ISA 2006 will ignore the Subject Name value if the SAN is populated, so the recommendation is to set the first SAN value equal to the Subject Name and then ISA will appear to behave correctly."

     

    Question A: As I mentioned above my internal certificate which is issued to front-end has SAN and the first SAN value is equal to sip.testing.local. Do you think ISA will behave correctly with the above mentioned configuration?

     

    Also as per your statement "The first certificate that was originally configured and assigned to the IIS Web Site on the OCS front-end was copied (along with the internal CA Root cert) to my ISA server." 

     

    Question B: Why we need to copy the certificate that was originally configured and assigned to the IIS Web Site on the OCS front-end was copied to ISA server.?

     

    With best regards,

     

    Muhammad

    Wednesday, February 13, 2008 6:40 PM