Exchange integration error on HP4120 desktop phones – A CA trust issue

I would like to go through an integration problem between Lync phone edition devices and Exchange 2010 that I worked on a while ago. Since the integration wasn’t working properly, users couldn’t access call logs, recorded voice mails, calendar information etc from their desktop phones (HP4120).


To understand the problem in more details, we asked our customer to collect Exchange side configuration information, phone edition logs from a problem device, network trace from Lync FE server etc.


Note: You can find full details on how to collect and analyze CELog data in the following Microsoft whitepaper: Understanding and Troubleshooting Microsoft Exchange Server Integration




Note: IP addresses, server names, URLs etc are replaced for privacy purposes


1) Lync phone edition device succeeds to obtain autodiscovery information:


0:01:43.203.610 : Raw data  211 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.214 4EC0006:5250012 INFO  :: NAutoDiscover::DnsAutodiscoverTask::ParseSoapResponse: InternalEwsUrl is


0:01:43.204.593 : Raw data  212 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.215 4EC0006:5250012 INFO  :: NAutoDiscover::DnsAutodiscoverTask::ParseSoapResponse: ExternalEwsUrl is



2) But the Lync phone edition device fails to access the EWS site with the following error (the same error is seen in all device logs) so the integration error occurs:


0:01:43.840.224 : Raw data  206 (char), UCD_LOG_ERROR: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.850 4EC0006:5250012 ERROR :: WebServices::CSoapTransport::ExecuteSoapOperation: Insecure server. errorCode=12045, status=014C0220, hr=80f10043

0:01:43.840.617 : Raw data  196 (char), UCD_LOG_ERROR: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.851 4EC0006:5250012 ERROR :: WebServices::CSoapTransport::SendSoapRequest: ExecuteSoapOperation failed. status=014C0220, hr=80f10043

0:01:43.840.963 : Raw data  225 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.851 4EC0006:5250012 INFO  :: WebServices::WebRequestImpl::ExecuteCommon: after SendSoapRequest. hr=0x80f10043, url=

0:01:43.841.216 : Raw data  191 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.851 4EC0006:5250012 INFO  :: WebServices::CSoapTransport::GetHttpHeaderInfoFromHandle: hSoapHandle=014C0220, headerInfo=013E2708

0:01:43.841.548 : Raw data  197 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.852 4EC0006:5250012 INFO  :: WebServices::CSoapTransport::GetCredentialsInfoFromHandle: hSoapHandle=014C0220, credentialsInfo=013E2670

0:01:43.842.135 : Raw data  165 (char), UCD_LOG_INFO: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.852 4EC0006:5250012 INFO  :: WebServices::CSoapTransportStatus::~CSoapTransportStatus: status=014C0220

0:01:43.842.492 : Raw data  182 (char), UCD_LOG_ERROR: 10/19/2012|14:50:27 Aries: 10/19/2012|14:50:27.853 4EC0006:5250012 ERROR :: WebServices::WebRequestImpl::ExecuteCommon: Could not execute SOAP request. hr=0x80f10043



err 014C0220

# as an HRESULT: Severity: SUCCESS (0), Facility: 0x14c, Code 0x220

# for hex 0x220 / decimal 544 :

  SE_AUDITID_IPSEC_AUTH_FAIL_CERT_TRUST                         msaudite.h

# IKE security association establishment failed because peer

# could not authenticate.

# The certificate trust could not be established.%n

# Peer Identity: %n%1%n



err 0x80f10043


# (user-to-user)

  MIDIERR_NOTREADY                                              mmsystem.h

  NMERR_INVALID_PACKET_LENGTH                                   netmon.h

  ERROR_BAD_NET_NAME                                            winerror.h

# The network name cannot be found.

  LDAP_NOT_ALLOWED_ON_RDN                                       winldap.h



So the problem looks like a certificate issue.


=> When I check the certificate assigned to CAS array, I see the following:


AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule}

CertificateDomains : {,}

HasPrivateKey      : True

IsSelfSigned       : False

Issuer             : CN=Issuing-CA for contoso, DC=contoso, DC=com

NotAfter           : 8/8/2014 3:36:18 PM

NotBefore          : 8/8/2012 3:36:18 PM

PublicKeySize      : 1024

RootCAType         : Enterprise

SerialNumber       : 362763723200000000524

Services           : IMAP, POP, IIS

Status             : Valid

Subject            :

Thumbprint         : EF32873628362BDA8326108875301F38504AB


Issuer is Issuing-CA for contoso, DC=contoso, DC=com


=> On the other hand, the CA that issues the Lync frontend certificate is the following: (this is taken from Lync server side network trace)



+ Tcp: Flags=...A...., SrcPort=5061, DstPort=50855, PayloadLen=1460, Seq=2076240595 - 2076242055, Ack=1109389286, Win=256 (scale factor 0x8) = 65536

  TLSSSLData: Transport Layer Security (TLS) Payload Data

- TLS: TLS Rec Layer-1 HandShake: Server Hello. Certificate.

  - TlsRecordLayer: TLS Rec Layer-1 HandShake:

     ContentType: HandShake:

   + Version: TLS 1.0

     Length: 4380 (0x111C)

   - SSLHandshake: SSL HandShake Certificate(0x0B)

      HandShakeType: ServerHello(0x02)

      Length: 77 (0x4D)

    + ServerHello: 0x1

      HandShakeType: Certificate(0x0B)

      Length: 3423 (0xD5F)

    - Cert: 0x1

       CertLength: 3420 (0xD5C)

     - Certificates:

        CertificateLength: 1574 (0x626)


        + Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

        + Issuer: Issuing CA for contoso,com

        + Validity: From: 09/10/12 10:05:05 UTC To: 09/10/14 10:05:05 UTC

        + Subject:

        + SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)

        + Tag3:

        + Extensions:

       + SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

       + Signature:




=> So the issuers of certificates used by Lync server itself and servers are different CAs:


a) CA that issues Lync FE certificate:

Issuing CA for contoso,com


b) CA that issues CAS array certificate:

Issuing-CA for contoso, DC=contoso, DC=com


Apparently two different CAs with similar names issued Lync FE and Exchange CAS array certificates.


Under normal circumstances, if those two CAs are enterprise CAs, they automatically publish their own CA certificates to AD so the clients can download and use them while verifying the certificate chain. But after some internal  research I found out that phone edition devices only trust the same CA that assigned the certificate to Lync FE pool to which phone edition device signs in.  (except public certificates listed in




After issuing a new certificate to CAS array from the same enterprise CA (Issuing CA for contoso,com) that issues Lync FE certificate as well, the integration problem was resolved.


Hope this helps you when dealing with similar problems...




Comments (2)
  1. You can also add the Exchange CAS Certificate to the Trusted Phone Edition Certificate Store by running the following command


  2. You can also add the Exchange CAS Certificate to the Trusted Phone Edition Certificate Store by running the following command


Comments are closed.

Skip to main content