Wednesday, February 25, 2015

Lync Edge: SIP/2.0 488 Compression algorithm refused

***The real issue was that the servers I was working on were... Server 2012 R2 RTM. I never anticipated that the operation system was not updated with OS and Security Updates. I am trying to track down which KB exactly resolved the issue, but no luck so far. If/when i find out, will update this post again.***

I ran to an interesting issue today. Customer replaced Public Edge server certificate (fortunately in lab) and all of a sudden federation broke.

We saw in the edge traces "SIP/2.0 488 Compression algorithm refused". Interesting, isn't it?

Here I have to mention that the customer uses VeriSign as certificate issuer. In the past, the certificates were signed by VeriSign Intermediate Certificate Authority and never had issues with it. The current certificate, however, was signed by "Symantec Class 3 Secure Server CA - G4".


The issuer itself is not a problem. However, this article - https://technet.microsoft.com/en-us/library/gg398066.aspx states: "All certificates must be signed using a signing algorithm supported by the operating system. Lync Server 2013 supports the SHA-1 and SHA-2 suite of digest sizes (224, 256, 384 and 512-bit)... ".

When the certificate was reviewed, we found that it was signed with signature algorithm "sha256RSA".


Federated Lync Edge servers did not liked this Signature Algorithm, resulting "SIP/2.0 488 Compression algorithm refused"

After the certificate was re-issued from Intermediate Authority, where the acceptable (sha1) algoritm was used, federation was re-established.

The moral of the story is - always verify the Signature Algorithm of your public certificates before assigning to Lync services. alway keep OS up to date!



12 comments:

  1. https://en.wikipedia.org/wiki/SHA-2

    SHA256 == SHA2 suite, and among those in that suite, this is the one that produces 256bit long values as a result

    these 2 things are literally the same, just written in different format

    So I dont understand why you made the conclusion, that the issue was the SHA256 algorithm.

    ReplyDelete
  2. The conclusion we made is based on result we got :-). Replacing the certificate with one signed with sha1RSA immediately resolved the federation issue.

    To go further, I installed second CA in my lab and signed internal Edge certificate with sha256RSA. This broke the communication between internal Lync infrastructure and Edge as well.

    I suspect Edge (either a bug, or by design) requires the federated partner to offer the EXACT same algorithm the we use.

    ReplyDelete
  3. @Drago:

    Yes I know if something gets fixed, the thing that fixed it was the issue. But dont you think that what Technet says does not make sense, if in fact the Edge has an issue with SHA2 certificates? If that turns out to be a bug or -even worse- Lync 2013 (and probably 2010 as well) product limitation, soon we will see major issues worldwide, as MS already started to deprecate SHA1:

    http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

    ReplyDelete
  4. I plan to configure second environment and have the two edges use certificates with the same algorithm, just to see what happens.

    The federation is "one way" - federated partner accepts our certificate and handshake succeeds. However, when federated partner initiate connection, our edge resets the connection and reports "488 Compression algorithm refused".

    Indeed there will be a period in near future where some still be on SHA1 and some - on SHA2 which, if this is not resolved, will create big issue.

    ReplyDelete
  5. Good to see that it has been sorted out finally! Patching, patching, patching! Print it on your wall :)

    ReplyDelete
  6. Drago - did you ever get to the bottom of the patch that was required? I have the same issue yet my servers are fully patched and SHA1 certificates are no longer available from my CA.

    ReplyDelete
  7. Okay in my case
    My Internal CA issued the certificate SHA1 and SHA1RSA however by SAN SSL certificate from Go daddy was issued using sha256RSA and sha256.
    So do I ask them that I need a new certificate issue using SHA1 ?

    ReplyDelete
  8. Any assistance will be greatly appreciated.

    ReplyDelete
  9. good day to all !
    i have thesame issue

    but in bracket some different errror

    TL_INFO(TF_PROTOCOL) [0]1790.13BC::08/10/2017-21:36:57.982.00002c9b (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[959253342] $$begin_record
    Trace-Correlation-Id: 959253342
    Instance-Id: 274B
    Direction: incoming;source=»external edge»;destination=»internal edge»
    Peer: federation.messenger.msn.com:5061
    Message-Type: response
    Start-Line: SIP/2.0 488 Compression algorithm refused
    From: sip:sip.altarix.ru;tag=1B60F59B4D65CC1D8F5ED7B50AC93F5B
    To: sip:federation.messenger.msn.com;tag=61E59B807C21F9EE65F285A64281F844
    Call-ID: 343B245B045CEF7FFFB8
    CSeq: 1 NEGOTIATE
    Via: SIP/2.0/TLS 172.29.100.92:49257;branch=z9hG4bK75FB3A73.FDB11CE76FAA08A9;branched=FALSE;received=131.253.130.254;ms-received-port=49257;ms-received-cid=41B66600
    Content-Length: 0
    ms-diagnostics: 2;reason=»See response code and reason phrase»;HRESULT=»0xC3E93C77(SIPPROXY_E_COMPRESSION_ALGORITHM_NOT_ENABLED)»;source=»federation.messenger.msn.com»
    ms-telemetry-id: 3A01322D-2518-553C-A8F1-7283448C6BBD
    Server: RTC/7.0
    $$end_record


    what it suppose to be - SIPPROXY_E_COMPRESSION_ALGORITHM_NOT_ENABLED

    ReplyDelete
  10. Drago - did you ever get to the bottom of the patch that was required? I have the same issue yet my servers are fully patched and SHA1 certificates are no longer available from my CA. دانلود آهنگ های پرطرفدار جدید

    ReplyDelete
  11. Caesars Palace Hotel Casino and Spa Review & Ratings - Dr.
    Casino. 이천 출장안마 Hotel 이천 출장샵 Overview. Casino. Hotel Description. As part of the 안양 출장안마 Caesars Entertainment Corporation, this casino 밀양 출장샵 is 나주 출장마사지 known for more than

    ReplyDelete