We recently had a customer that had an issue whereby simultaneous call ringing was not working in a very specific situation: when the inbound call was via a SIP trunking gateway to a Lync 2010 Mediation Server that routed the call to a Skype for Business front end server. What would happen is that the caller would be disconnected the moment the SFB client started to ring. The SFB client would ring even though the caller had been disconnected and of course if the callee answered, it would error (because there was no caller on the other end of the line). All other inbound and outbound PSTN calling worked fine. Also, when the simultaneous calling was switch off client-side, inbound calling worked just fine. The CLS Log showed the following:

Various internet suggestion such as rebooting the front end server, applying all the CUs, disabling REFER and normalising to E.164 incoming numbers has all been tried. The clue was in a trace (not message) log:

Doing a search on the Internet revealed two other references: and Both have replaced all SHA256 with SHA1 (and the first link also disabled use of an alternative signature algorithm) certificates. What? SFB doesn’t support SHA1? No CSO is going to tolerate that! Microsoft certainly support SHA2: and RSA signatures are OK. So, what gives?

Looking like a certificate hash or encryption protocol has been used that isn’t supported. Let’s look at the SFB Default certificate:

Unlike the above two solutions, we tried every permutation of signature algorithm and SHA and found that the problem is not the use of SHA256, but the use of RSASSA-PSS. SHA256RSA worked fine:

How to implement this? The issuing CA needs to be configured not the issue certificates using an alternate signature algorithm – hopefully this doesn’t cause your CSO to melt down!:

1.  certutil -setreg csp\alternatesignaturealgorithm 0
2.  Restart certificate services

Then re-issue a new certificate on Default and you are good to go. The lessons?

1.       SFB does work with SHA256 certificates.
2.      SFB does not unfortunately work with the RSASSA-PSS signature algorithm. (I cannot find anything from Microsoft officially to say this.)
3.      The only certificate affected is the Default one. The Internal and External do not seem to have this problem.

NOTE: the problem has existed since a least Lync 2010.