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!



11 comments:

soder said...

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.

Drago said...

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.

Anonymous said...

@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

Drago said...

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.

soder said...

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

Anonymous said...

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.

Unknown said...

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 ?

Unknown said...

Any assistance will be greatly appreciated.

Unknown said...

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

John said...

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. دانلود آهنگ های پرطرفدار جدید

egidelavalla said...

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