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


soder said...

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


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:

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.

Rich Ojeleye 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 ?

Rich Ojeleye said...

Any assistance will be greatly appreciated.