outgoing TLS negotiation failed; HRESULT=-2146893022 RRS feed

  • Question

  • OK, so im really going crazy now. We have set up everything :

    - 4 NICS 
        - 1 Internal 
        - 2 DMZ (Access and Conference)
        - 1 Public (Direct external IP)

    - 1 NIC

    Now we couldnt get A/V to work. Everytime we run a Wireshark trace all we see is that the clients are using their own local IP addresses. So i went back to the EDGE server and ran the validation. Now im stuck with this error:

    Failed to register user: User sip:dennis@domain.nl @ Server sscedge09
    Failed to send SIP request: outgoing TLS negotiation failed; HRESULT=-2146893022

    Now i know this is probably just another certificat error, but i can not get it to work! What i have used is:
    Internal certificate with subject names:

    sscedge09 (name of the EDGE)
    sscedge09.domain.local (No, its not in the domain...)
    vsap022.domain.local (The SE server)
    sip.domain.nl (external IP)

    3rd party certificate:
    signed to av.domain.nl

    What am i doing wrong ? I really am comletely lost on these things...


    Well after some further testing and sniffing the following occured:

    sip.domain.nl -
    av.iquna.nl -

    Both also setup like this in the EDGE configuration, but when sniffing the traffic, there is never any traffic going
    to the .28... (and yes, i did click the video and/or communicator call button :-))

    Friday, January 2, 2009 3:02 PM

All replies

  • Hi,

    What do you mean with "internal certificate"? Is this the certificate on your internal interface or is this a certificate assigned on your access edge but signed with an internal CA ?

    If the first then what do you have configured on the access edge interface ?
    If the second do you actually trust the internal CA Root on your client where the tests are done? Did you import the root CA on the EDGE server as well ?

    The error you get is when your client tries to connect to a FQDN which is not listed in the certificate that is presented by the server. Let's say the client connects to sip.domain.nl but the certificate on interface is configured with only av.domain.nl. This will get you a mismatch and the above error..

    Tonino Bruno | Belgian Pro-Exchange Community | http://www.pro-exchange.be
    Tuesday, January 6, 2009 9:27 PM
  • I'm having this exact same problem on a new 2007 R2 installation. I've got the following:

    2 interfaces on the edge, 1 allocated to the internal network on a network address, and three address (one for each of IM, AV and Web Conf) on a network address. These are NAT'ed as follows: IM using public cert Webconf using public cert AV using INTERNAL cert

    The 'internal' address on the .4 network uses an internal cert.

    IM works absolutely fine, irrespective of the users location (i.e. office, home, wherever). Its AV and Webconf that are the issue. When I do a validation check on the edge I get the same error posted by DennisIT. When I try connecting from a a location other than the same network as he person I'm trying to contact it doesn't work. The connection fails (talking AV here) with a message saying the recipient stopped receiving audio.

    I've done some wireshark captures from my PC (I am at home sitting behind a router using When I try and contact my colleague over AV wireshark tells me that its trying to talk to his network address, which of course it can't do. I would have expected to see it trying to talk to the public IP of the network i'm trying to reach?

    We don't have a concept of an 'internal' user, as this is a hosted service, so all users are external and therefore access via the edge server. Incidentally, this is a single edge erver deployment at the moment with single enterprise pool server in the background.

    Also, when monitoring the firewall log at the time I try to setup the AV connection I see no traffic at all on the interface. I gues this is because its trying to do the peer-to-per connection, but would have still expected something

    Finlly, on more thns that seems very unclear is exactly what kind of cert should be used on the AV public interface. The MMC states 'none required' under the AV section. I have also read various posts from various people, and some say public should be used, some say it doesn't matter and internal will do. All very confusing.

    Sorry to hijack DennisIT's post, but thought as we have the same issue, might as wellkeep it all together.


    Friday, October 16, 2009 3:20 PM
  • Just to follow up on this, I have managed to resolve the issue with help from Experts Exchange. For those that have Experts Exchange access, the link is here:


    Bascially everything bout my setup was right (port used for AV authentication, could telnet to the right ports externally, etc etc). The only thing that could me out was certificates on the internal interface and teh AV interface. On each of these I used an internal cert (external cert not required o AV interface even though it is public), and on those certs I had one SAN name on each that matched the subject name of the respective cert. I was advised that SAN names shouldn't be used ideally. Turns out that removing the SAN name completely with re-issued certs, then restarting services worked. Hope it helps someone that was as frustrated as me.
    Monday, October 19, 2009 3:45 PM