none
Same cert for Edge and Front End RRS feed

  • General discussion

  • Couldn't tell if my first post submitted properly, here's hoping I'm not repeating myself...

    Hello everyone,

    I know this question has been asked in other threads but I can't find a solution in any of them so hopefully starting another one (and, by doing that, having others review my particular scenario) will help.  I've got a single Standard Edition server with a single Edge server deployed.  I've tested everything using an internal CA, cert including Mobility and everything works just fine.  Now I've purchased a SAN cert from GoDaddy and installed it on both the Edge and Front End servers.  When using the GoDaddy cert I can't connect with the mobility client and 3-way IM conversations don't work.  When I switch the Front End server back to the internal cert everything works again.

    I've read through lync client logs and done some log file analysis on the servers but it appears to boil down to the following...

    Lync Client Log (when attempting 3-way IM)

     SIP_URL::ParseUrlBase ParseSipUrlParams failed 80004005

    Front End server log (when attempting 3-way IM)

     SIP/2.0 400 Malformed Edge Proxy header
     ms-diagnostics: 1018;reason="Parsing failure";source="FRONTEND.local.mydomain.com"

    The GoDaddy certificate is as follows:

     Subject = edge.local.mydomain.com
     
     SANs=

     DNS Name=edge.local.mydomain.com
     DNS Name=www.edge.local.mydomain.com
     DNS Name=lync.mydomain.com
     DNS Name=sip.mydomain.com
     DNS Name=edge.mydomain.com
     DNS Name=dialin.mydomain.com
     DNS Name=meet.mydomain.com
     DNS Name=frontend.mydomain.com
     DNS Name=lyncdiscover.mydomain.com
     DNS Name=lyncdiscoverinternal.mydomain.com
     DNS Name=frontend.local.mydomain.com

    According to MS (http://technet.microsoft.com/en-us/library/gg398920.aspx) this certificate should work.  I've also ensured that the certificate chain is enabled for "all uses" on both servers.

    The Internal cert is configured as follows:
     
     Subject = frontend.local.mydomain.com
     
     SANs=

     DNS Name=sip.mydomain.com
     DNS Name=frontend.local.mydomain.com
     DNS Name=dialin.mydomain.com
     DNS Name=meet.mydomain.com
     DNS Name=LyncdiscoverInternal.mydomain.com
     DNS Name=frontend.mydomain.com
     DNS Name=Lyncdiscover.mydomain.com

    The major difference I can see is the Subject, although, according to MS it's not an issue:

     Note:
     Even though the certificate subject name is equal to the access Edge FQDN, the subject alternative name must also  contain the access Edge FQDN because Transport Layer Security (TLS) ignores the subject name and uses the subject  alternative name entries for validation.

    Anyone have any suggestions?

    Wednesday, March 28, 2012 5:54 PM

All replies

  • Have you also installed the intermediate certificate from godaddy?


    regards Holger Technical Specialist UC

    Wednesday, March 28, 2012 9:13 PM
  • Yes, or at least I believe so.  They refer to it as a 'bundle', there are 3 certs in the path:

    Go Daddy Class 2 Certification Authority

            Go Daddy Secure Certification Authority

                    Lync UC/SAN Cert

    Wednesday, March 28, 2012 9:36 PM
  • You mention you topology is: EXTERNAL <--> EDGE <--> FRONTEND <--> INTERNAL

    and you probably have read http://technet.microsoft.com/en-us/library/bb964037%28v=office.12%29.aspx

    [CERTIFICATE]
    Do you have a reverse proxy (TMG/ISA/) or hardware load balancer
    add the edge into the outbound proxy as sip.mydomain.com:443;transport=tls
    see the setting description here.

    You may want to ensure the cert chain (intermediate up to root) is ok. kindly refer to link below especially Step 4
    https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO15284

    Also, you may also want to give the RUCT tool a try to help troubleshoot your certificates -
    The Remote UC Troubleshooting Tool (RUCT) | Inside Lync

    [DNS]
    Kindly rechecked your SRV record (the RUCT tool should assist) especially _sip._tls , _sip._tcp

    There is a possibility your records are not updated with the GoDaddy's
    The RUCT might assist with what port your GoDaddy cert is bound to

    [EDGE]
    When the cert was change to goDaddy's, was the internal remove across board (Edge, FrontEnd, Reverse Proxy)
    Is the GoDaddy's the only cert "Assign" to the Edge's Ext

    What type of firewal do you have. See Noya Lau
    >>> In addition, please also check if there is any firewall such as Juniper firewall. Please note, the Juniper setting "SIP ALG" should not be enabled.

    http://qa.social.technet.microsoft.com/Forums/en-US/ocsedge/thread/f8b33869-1e32-4ae7-9872-af5c240733dd

    Kindly feedback and hopefully we should be able to assist

     

    If this post has been useful please click the green arrow to the left or click "Propose as answer"

    Thursday, March 29, 2012 11:26 AM
  • Although this approach technically can work it's not recommended as (1) it's not best-practice to use a third party certificate on the internal Front End servers and (2) it's not advisable to publish your internal server FQDNs and general namespace into an external certificate. 

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Thursday, March 29, 2012 2:55 PM
    Moderator
  • My topology is:

    EXTERNAL<-->FIREWALL<-->EDGE<-->FRONTEND<-->INTERNAL

    The firewall is Linux and it does port forwarding from a public IP address back to the Edge server and forwarding from another public IP address back to the Front End (for lyncdiscover, mobility access).  Aside from the firewall's port forwarding there is no reverse proxy of any sort.

    Thursday, March 29, 2012 4:23 PM
  • Found the below entry in the event log when restarting the access edge service.  This is probably the cause, along with my own misinterpretation of the Microsoft's certificate requirements.  It's safe to assume that even though TLS ignores the subject name of the cert, that subject name must still be equal to the access edge external FQDN (for SIP purposes).  The technet article does make both of those statements so.... off I go to try to get GoDaddy to re-issue my cert. :(

    Log Name:      Lync Server
    Source:        LS Protocol Stack
    Date:          3/29/2012 10:18:57 AM
    Event ID:      14581
    Task Category: (1001)
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      edge.local.mydomain.com
    Description:
    Access Edge Server external edge FQDN cannot be located in the certificate configured for its external edge.

    External FQDN: 'lync.mydomain.com'.
    Cause: This is a configuration problem.
    Resolution:
    Make sure the certificate configured on the external edge of Access Edge Server matches its external FQDN.
    Event Xml:

    Thursday, March 29, 2012 4:30 PM
  • The Event log confirm some of the fear about your Lync topology hence deployment
    Seems you should have a quick resolve now!

    Thus, i would still recommended you check the following (blinding your eye to "assumptions")

    1. [CERT]
    Check your Lync topology in Mgt concole (or mgt shell)
    confirm the FQDN of the Edge
    If not matching, correct and republish topology (remember to copy to Edge)
    I dont expect Edge to be on the same "Network" as your internal FrontEnd Network

    More so, try re-keying the GoDaddy cert
    (logged into godaddy and clicked re-key certificate, then re-downloaded the certs. Ensure intermediate cert from goDaddy in the trusted root certs on your server.)

    And you have propose yourself ... you can go try get GoDaddy to re-issue my cert with identical Cert

    Remember your Edge Ext cert isn't same as your Int cert ... "Assign Cert to Edge"
    Kindly read through - http://www.ocspedia.com/Certificates/AccessEdge/AccessEdge_Cert.htm

    [EDGE]

    When the cert was change to goDaddy's, was the internal remove across board (Edge, FrontEnd, Reverse Proxy)
    Is the GoDaddy's the only cert "Assign" to the Edge's Ext Cert
    The RUCT might assist with what port your GoDaddy cert is bound to
    The Remote UC Troubleshooting Tool (RUCT) | Inside Lync

    Re-check the Lync control panel, in external user access --> Access edge configuration and edit the global configuration, ensure "enable remote user access".

    [DNS]
    Kindly rechecked your SRV record (the RUCT tool should assist) especially _sip._tls , _sip._tcp

    There is a possibility your records are not updated with the GoDaddy's
     

     


    If this post has been useful please click the green arrow to the left or if assist you to resolve, click "Propose as answer"



    • Edited by Semmyk Friday, March 30, 2012 3:30 PM Cert re-keying, re-issue, re-assign
    Friday, March 30, 2012 3:06 PM
  • As I suspected the subject name of my certificate was the root of the problem.  For anyone interested in using a single certificate for a Lync deployment I'd say generate your CSR by hitting the "Request" button in the Lync Server Deployment Wizard's "Request, Install or Assign Certificates" dialog - while the "External Edge certificate (public internet)" item is selected.  Or generate your CSR manually using openssl and make sure to use your edge server's public FQDN for the subject.

    Thankfully, GoDaddy re-issued the cert at no cost.

    Monday, April 2, 2012 7:59 PM
  • Good to know this has been resolved:

    Quick Ones:

    Although this approach technically can work it's not recommended as (1) it's not best-practice to use a third party certificate on the internal Front End servers and (2) it's not advisable to publish your internal server FQDNs and general namespace into an external certificate.

    bsapach
    Check the event log 

    [CERT]

    Check your Lync topology in Mgt concole (or mgt shell)
    confirm the FQDN of the Edge
    Use tool (if need be) The Remote UC Troubleshooting Tool (RUCT) | Inside Lync

    [DNS]
    Kindly rechecked your SRV record (the RUCT tool should assist) especially _sip._tls , _sip._tcp

    Confirm Cert subject name and SAN entries against edge FQDN.

     

     

    If this post has been useful please click the green arrow to the left or click "Propose as answer"

    Tuesday, April 3, 2012 1:25 PM