locked
UCC certificates Woes :( RRS feed

  • Question

  • Let me start with a background on our setup...

    We have 2 servers running Office Communications, a standard edition front end and an edge server.

    names:
      standard: samadams
      Edge: duff

    Each service on the edge server has its own network port and its own IP Address and its own name

    Internal: ocsinside
    A/V Edge: avedge
    Access Edge: accessedge
    Web Conference: webconf

    We went ahead and got a UC certificate with subject name sip.domain and all of the other names listed as SANs

    I did this by running the certificate wizard in OCS and then accepting the cert request on the main server. Then I just exported it and applied the exported certificate to the edge server's services

    However, no matter what I do I cant seem to get the stupid thing to work with the new certificates. When I apply it to the edge server is changes all of my FQDNs to sip.domain and all of my connections fail. So I tried changing the subject name to the main server's FQDN and got the same issue with the edge server again. The only way I was able to get anythign to work at all was to give each FQDN its own seperate certificate made special for it.

    Any ideas on what this issue is or how to fix it?
    Wednesday, August 20, 2008 2:16 PM

Answers

  • This is normal behaviour it checks the first entry in the SAN and only uses that one

    You should create a separate Certificate for the Internal Server (but you can use an internal CA)

     

    You should create a public certificate for the Access Edge and another for the WebConferencing EDGE and one for the Reverse Proxy

     

    avedge does not require a certificate

     

    You can use an Internal Certificate for the A/V Authentication service

     

    Wednesday, August 20, 2008 9:30 PM

All replies

  • This is normal behaviour it checks the first entry in the SAN and only uses that one

    You should create a separate Certificate for the Internal Server (but you can use an internal CA)

     

    You should create a public certificate for the Access Edge and another for the WebConferencing EDGE and one for the Reverse Proxy

     

    avedge does not require a certificate

     

    You can use an Internal Certificate for the A/V Authentication service

     

    Wednesday, August 20, 2008 9:30 PM
  • I have re-done my certs now like you said but now it seems to be doing something else odd.

    Every time I try to connect an external user to a live meeting I get a certificate error as if it was still using the old certificates. I have verified that web conferencing and access edge are both using the proper certificate and I have restarted all services that were using it but still no luck...it just keeps saying that it can't verify the certificate from the server.

    I am extremely confused now...as the thing was working just find when I had the internally made certs in the configuration you said. It is extremely weird because the non-domain clients on site work fine but the off site test client gets this error.

    There are no special DNS entries I need to make are there? I have thusfar:

    _sipinternaltls._tcp.domain 600 IN SRV 0 100 5061 samadams
    _sipinternal._tcp.domain 600 IN SRV 0 100 5061 samadams

    _sipfederation._tcp.domain 600 IN SRV 0 100 5061 accessedge
    _sip._tls.domain 600 IN SRV 0 100 433 accessedge


    Am I missing something?
    Saturday, August 23, 2008 2:03 AM
  • Seems that you are still using NETBIOS server names?

    You must use the FQDN of the server names and use them in the certificate

     

    You should have a look at this tool that really helps you with configuration of EDGE Server

    Edge Planning Tool for Office Communications Server 2007

    http://www.microsoft.com/downloads/details.aspx?familyid=149e5dd5-eaae-46b6-afba-01c31e88a275&displaylang=en&tm

     

     

    Monday, August 25, 2008 9:08 AM
  • Nope...I have the FQDN

    Here's my cert:

    SN: accessedge.domain

    SAN:
     sip.domain
     avedge.domain
     webconf.domain
     duff.domain
     samadams.domain (for the web access)
     accessedge
     avedge
     webconf
     samadams


    Only thing I can think of is that it is a GoDaddy cert and I have seen people reporting weird things with GoDaddy certs here.
    Monday, August 25, 2008 1:47 PM
  • Joseph, I think the comment about the NETBIOS names was related to your DNS entries. Your SRV records are pointing at NETBIOS server names instead of the FQDN's. Try changing those external DNS names to point at the FQDN.

    Is your Edge in a workgroup or domain? Have you defined a DNS suffix on the machine or public NICs?

    Assuming your Edge is a workgroup member with no DNS suffix defined and its name is duff do your cert like this:

    SN: sip.domain

    SAN:
    sip.domain
    webconf.domain
    avedge.domain
    duff
    samadams.domain

    Your DNS SRV record for _sip._tls should point to sip.domain

    When asked for the external names in the OCS Wizard:
    Access Edge: sip.domain
    Web Conferencing Edge: webconf.domain
    A/V Edge: avedge.domain



    Monday, August 25, 2008 3:38 PM
  • That was me being lazy on my writing of the SRVs...I should have known better than that.

    These are our exact DNS SRV records (our domain was replaced with domain)

    _sipinternaltls._tcp.domain. 600 IN SRV 0 100 5061 samadams.domain.
    _sipinternal._tcp.domain. 600 IN SRV 0 100 5061 samadams.domain.
    _sipfederationtls._tcp.domin. 600 IN SRV 0 100 5061 accessedge.domain.
    _sip._tls.domain. 600 IN SRV 0 100 443 accessedge.domain.

    Both of these machines are on the domain and use our main Unix DNS server.

    So _sip._tls needs to point to sip.domain. and sip.domain should be resolved to accessedge? Or will I need to actually change the FQDN of accessedge to sip? I dont want to do that unless I absolutly need to becasue I would have to go back through the certificate people and change the SN and that is a lot of red tape.
    Monday, August 25, 2008 4:05 PM
  • You don't really have to. I was suggesting the sip.domain name because it's pretty standard. Pick sip.domain or accessedge.domain but you don't need both. If you want to go with your current cert let's disregard the sip.domain name for the time being. You can keep your DNS records pointing at accessedge.domain and the OCS Access Edge name should be defined as accessedge.domain.

    Is the Edge a domain or workgroup member? DNS suffix? I've seen that make a difference what name you use on the cert. In your case you have duff.domain on the cert. I'd use that only if it was a domain member, you defined a DNS suffix for the machine or you defined a DNS suffix for the public NICs. Usually I leave the machine in a workgroup, avoid setting DNS suffix altogether and just put the NETBIOS name of the machine on the cert. In your case the cert would look like:

    SN: accessedge.domain

    SAN:
    accessedge.domain
    webconf.domain
    avedge.domain
    duff
    (and any CWA names you wanted)


    Monday, August 25, 2008 8:10 PM
  • Going back to your post in the beginning.

    Is this still your problem?

     

    When I apply it to the edge server is changes all of my FQDNs to sip.domain and all of my connections fail. So I tried changing the subject name to the main server's FQDN and got the same issue with the edge server again. The only way I was able to get anythign to work at all was to give each FQDN its own seperate certificate made special for it.

     

    Because that is the was it works you should actually use a different cert for the Access EDGE and the Conferencing EDGE
    Monday, August 25, 2008 9:59 PM
  • Yes this origional issue is resolved. Thank you for helping!


    I am thinking these other issues I'm having are because we are using the cheapo GoDaddy certs.
    I have seen some other people having similar issues with them and I guess that's what we get for trying to go cheap on them.

    If I figure it out I'll be sure to make a post about it


    Thanks for the help guys!
    Tuesday, August 26, 2008 4:20 PM
  •  

    Very well could be the GoDaddy certificate.  OCS/UC is pretty picky about external certificates.   I would suggest one of the following supported External CAs listed here.   http://support.microsoft.com/default.aspx/kb/929395/EN-US/ 

     

    GoDaddy has or at least did when I played with them, a complicated certificate structure.

     

    Good Luck

     

    Friday, August 29, 2008 11:19 PM