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

  • Article

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:

https://www.microsoft.com/en-us/download/details.aspx?id=15668 Understanding and Troubleshooting Microsoft Exchange Server Integration

 

Troubleshooting:

===============

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 https://casarray.contoso.com/EWS/Exchange.asmx

               

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 https://autodiscover.contoso.com/EWS/Exchange.asmx

...

 

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=https://casarray.contoso.com/EWS/Exchange.asmx

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 : {casarray.contoso.com, cas01.contoso.com}

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 : CN=casarray.contoso.com

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: casarray.contoso.com

        + SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)

        + Tag3:

        + Extensions:

       + SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

       + Signature:

       Certificates:

 

 

=> So the issuers of certificates used by Lync server itself and casarray.contoso.com 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 https://technet.microsoft.com/en-us/library/gg398270(OCS.14).aspx)

 

RESULTS:

========

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...

 

Thanks,

Murat