none
Regression introduced in CU2 (and possibly not fixed in CU3 either)?

    Question

  • I see the following error message in Lync FE eventlog everytime a user signs in with the Lync client:

    Event log:

    Log Name: Lync Server
    Source: LS UserPin Service
    Date: 09/06/2011 19:46:21
    Event ID: 47055
    Task Category: (1044)
    Level: Warning
    Keywords: Classic
    User: N/A
    Computer: LYNCFE01.DOMAIN.com
    Description:
    GetAndPublish web service failed due to an internal error

    Request Details - Entity: [user1@DOMAIN.com], Device Id: [{A7C394D3-99CB-5D24-A361-4865A9D4421B}], Authenticated User: [sip:user1@DOMAIN.com].
    Cause: This is an unexpected failure
    Resolution:
    Re-start the web server. If you see this error continuously, examine the server traces and contact product support.
    Event Xml:
    ">http://schemas.microsoft.com/win/2004/08/events/event">
    47055
    3
    1044
    0x80000000000000
    1084112
    Lync Server
    LYNCFE01.DOMAIN.com
    user1@DOMAIN.com
    {A7C394D3-99CB-5D24-A361-4865A9D4421B}
    sip:user1@DOMAIN.com

     

    The "get-csclientcertificate" command does not return any certificate for any of the enabled users.

    "Test-csclientauth" also fails in the environment.

    I made a complete rollback from CU3 (and CU2) to RTM version of Lync, and the error message did not come back. I re-applied CU3, and the error message appears again in the log.

    Monday, August 15, 2011 12:24 PM

Answers

  • After 4 months of troubleshooting it turned out to be an ugly and sneaky certificate issue. MS product support confirmed it, after contacting the developer responsible for that piece of code. After the certificate has been re-issued all the issues (including this one and several other PSTN conferencing related ones) just magically disappeared. I was fighting with MS product support to issue at least a proper documentation of the crazy strict requirements of Lync, as the current product documentation is cinycally silent about this.

    Just in short: in your certificate dont ever dare to use any exotic signature algorithm other than "sha1RSA". I really mean literally "sha1RSA", no other permutation of RSA must be allowed here. Otherwise you will go into an endless pit of hell with all kind of impossible to resolve. Turned out Lync is sensitive if communicates with the EXUM and EXUM provides such an exotic signature algorithm in the certificate, like "RSASSA-PSS".

    After both Lync FE and EXUM certificate has been replaced with a simple sha1RSA, everything started to be working. The root CA also had such an exotic RSASSA-PSS certificate, but luckily we didnt have to change this, as fortunately Lync was not looking at the whole cert chain. On the other hand it was a live production Root CA. I would start arguing that if Microsoft offers all these exotic algorithms in its Certificate Authority product, it must be accepted by all of its products, and not cause such weird headaches.

    But if MS doesnt support all these exotic crypto-nightmares in Lync, at least doucment this properly! If you have a look at the current Lync documentation, its a joke what they have been written about certificate requirements. This should have been written much more professionally!


    Monday, November 14, 2011 3:54 PM

All replies

  • Hi,Richard,

    LS User Pin service event is mostly related to the Lync phone edition service,have you also installed the latest update package for Lync Phone edition?

    Lync 2010 Phone Edition (Polycom CX500, CX600 & CX3000) – KB2577594

    Lync 2010 Phone Edition (Aastra 6721ip & 6725ip) – KB2577595

    Lync 2010 Phone Edition (Polycom CX700 & LG Nortel 8540) – KB2577593

    In case you omit some update packages for Lync,here is  the latest update packages listed below:

    http://blogs.technet.com/b/cs2010/archive/2011/07/26/lync-july-2011-update.aspx

    Please do let us know if these works.Thanks!

    Regards,

    Sharon


    Wednesday, August 17, 2011 6:39 AM
    Moderator
  • No IP phones were connected to this environment, only Lync 2010 clients.
    Wednesday, August 17, 2011 9:05 AM
  • After 4 months of troubleshooting it turned out to be an ugly and sneaky certificate issue. MS product support confirmed it, after contacting the developer responsible for that piece of code. After the certificate has been re-issued all the issues (including this one and several other PSTN conferencing related ones) just magically disappeared. I was fighting with MS product support to issue at least a proper documentation of the crazy strict requirements of Lync, as the current product documentation is cinycally silent about this.

    Just in short: in your certificate dont ever dare to use any exotic signature algorithm other than "sha1RSA". I really mean literally "sha1RSA", no other permutation of RSA must be allowed here. Otherwise you will go into an endless pit of hell with all kind of impossible to resolve. Turned out Lync is sensitive if communicates with the EXUM and EXUM provides such an exotic signature algorithm in the certificate, like "RSASSA-PSS".

    After both Lync FE and EXUM certificate has been replaced with a simple sha1RSA, everything started to be working. The root CA also had such an exotic RSASSA-PSS certificate, but luckily we didnt have to change this, as fortunately Lync was not looking at the whole cert chain. On the other hand it was a live production Root CA. I would start arguing that if Microsoft offers all these exotic algorithms in its Certificate Authority product, it must be accepted by all of its products, and not cause such weird headaches.

    But if MS doesnt support all these exotic crypto-nightmares in Lync, at least doucment this properly! If you have a look at the current Lync documentation, its a joke what they have been written about certificate requirements. This should have been written much more professionally!


    Monday, November 14, 2011 3:54 PM
  • Richard,

    Thank you VERY much !!!

    I killed a lot of time searching for this error. But thanks to your information, I found the solution !

    Konstantin

     

    Friday, December 23, 2011 11:34 AM
  • Richard,

    Thank you VERY much !!!

    I killed a lot of time searching for this error. But thanks to your information, I found the solution !

    Konstantin

     

    Did you have a similar crazy exotic certificate, like in my case?
    Friday, December 23, 2011 3:00 PM
  • Sorry for the long silence ..
    Yes, we use the win 2008 r2 PKI infrastructure and use the type of signature SHA256-RSASSA-PSS. Now communicate with the PSS, we want to open a design change request.

    Wednesday, January 18, 2012 7:46 AM
  • Richard,

    Do you know if this issues is still outstanding with CU6?

    Thanks,
    Frank

    Monday, July 16, 2012 2:25 PM
  • If you read my post -above- describing the real situation, you will see this is not really a bug, but a limitation of the Lync software. And most probably it will not be fixed in any CU release, but MAYBE in the next major version. But only in case you and other victims of this problem keep continuously banging the walls at the Redmond MS HQ, otherwise the mammoth wont make any move towards fixing this painfull limitation.
    Wednesday, July 18, 2012 6:43 PM
  • The problem is solved. There is a huge Microsoft mistake in documentation for MS Lync. I don't know why but I can't find any information about exact PKI requiments for MS Lync. In my case all my certificates use RSASSA-PSS algorythm instead of RSAsha1. I changed the registry key on my Enterprise CA server.    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\Your Cert Authority\CSP

    value AlternateSignatureAlgorithm from 1 to 0 and restart CA service.

    After this request a new certificate from Lync deployment withard and everything become OK.

    It take me about 3 month to find out this!!!!


    RFT

    • Proposed as answer by Rufat Aliyev Monday, December 10, 2012 7:02 PM
    Monday, December 10, 2012 7:02 PM
  • Thanks both Richard and Rufat. Oddly, my Lync deployment seemed to be OK apart from these errors mentioned above (both internal and remote connectivity for users and federated partners was OK). However, I was seeing some odd error on the Remote Connectivity Analyser (RCA - https://testconnectivity.microsoft.com/) so I thought I would run through these steps to see if it resolved my issue.

    Indeed, I had recently setup and two tier PKI with Windows 2012 and enabled the subordinate to use "Alternate Signature Algorithm", which seemed like a reasonable assumption to make after reading umpteen documents and web sites. However, resetting this, then re-issuing the Lync FE and Edge certificates via the CA, the "LS UserPin Service" error disappeared.

    I should say that the signature algorithm used is SHA256RSA, so it doesn't seem necessary to go right back to SHA1 (which is now seen to be insecure).

    However, it still didn't resolve my RCA error, which I just can't figure out as the information provided by RCA is too woolly:

        Couldn't sign in. Error: Error Message: The operation failed after several attempts..
        Error Type: RegisterException.
        Deregister Reason: None.

    Still, I appreciate your efforts both to track down the certificate issue. Certificates and all their intricacies confuse the hell out of me, however, I would have thought that the encryption layer would be abstracted away from the main Lync application, so it shouldn't care how the encryption is done.

    I suppose it just goes to show....


    Chris

    Thursday, February 12, 2015 3:53 PM
  • MS still owes the community a "Lync certificates" guide whitepaper!

    Tuesday, March 10, 2015 3:59 PM
  • Thank you Rufat!

    I would like to say that in Skype for Business Server 2015 with march CU nothing has changed - issue still persist. Solution from Rufat works for me.



    Friday, May 27, 2016 4:10 AM
  • Quote: "I should say that the signature algorithm used is SHA256RSA, so it doesn't seem necessary to go right back to SHA1 (which is now seen to be insecure)."

    Answer: At the time of opening this thread, SHA1 was considered to be secure. That's the joy of working on (as of today) 5-year old issues: the whole ecosystem around the issue is in constant motion, its just the original issue that remains unresolved by Microsoft.


    Friday, May 27, 2016 11:06 AM
  • After I have changed our internal PKI infra, LPE's started to fail. Did some debugging and stumbled onto this topic. Now my certificate installed on the FE server has the following properties:

    signature algorithm: sha256rsa
    signature hash algorithm: sha256
    Thumbprint algorithm:sha1
    Keysize: 4096

    As far as I can read no issues here when on firmware after december 2015 CU (https://support.microsoft.com/en-us/kb/3107804 )

    On the other hand the offline root and issuing CA have the following properties:

    signature algorithm: RSASSA-PSS
    signature hash algorithm: sha256
    Thumbprint algorithm:sha1
    Keysize: 4096

    Could this cause the phone to be unable to login? Even trying to connect using USB fails with crash of the phone!

    Tuesday, July 12, 2016 3:22 PM