PureConnect

 View Only
Discussion Thread View
  • 1.  Jan 19 2038 bug in certificate signing (3.0 SU 12)

    Posted 01-19-2018 17:16
    Hello all.. We are running IC 3.0 SU12.. (I know, I know..) As of this morning, none of our soft phones can provision. I've traced this down to a likely 2038 time overflow issue -- the AdminServer fails to sign the certificate due to an exception in a time adjustment function. I've noted that AdminServer signs certificates as good for 20 years -- so as of today, it would be attempting to sign it through Jan 19, 2038. Jan 19 2038 happens to be the limit of a signed integer to hold time (https://en.wikipedia.org/wiki/Year_2038_problem) I've confirmed on a dev platform that if I set the server time back a couple days, the client is able to provision successfully. Are there any levers to tell AdminServer to sign certificates for a shorter time period? Any other thoughts/suggestions, other than upgrade? (Trust me, I want to.) Appreciate your help.. Joe


  • 2.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    Posted 01-20-2018 00:10
    By way of more info... I've turned tracing up to 100 all the way through the chain from SIP Soft Phone to provisioning server to admin server, and this is the relevant issue: I3AdminServer::ReceiveNotification : Caught exception: ErrorCode: error.i3certificates.OpenSSL Description: Failed the OpenSSL X509_time_adj() function call for certificate expiration time. Hostname: CIC1 Function: i3certificates::Certificate::Certificate() File(Line): //depot/qa/core/1.1/int/src/i3certificates/certificate.cpp#5(940) Parameters: while signing user certificate request. userCertificateRequest: MIIBfjCB6AIBADA/MRAwDgYDVQQKEwdTZXJ2ZXJzMRUwEwYDVQQLEwxTZXJ2ZXIg TGluZXMxFDASBgNVBAMTC0pESUNLU09OLURUMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDUoHlKLAxrHe6EeeNBv1AJ/IZK1iIvKqa7HfUnztJI3rpyvqaZfJuv vdS4+1MRI+m/TMl204LbiVSl/OHhSDej+gM7R+C9ODRU4s/HavzHfRNCBmjB7D/R +Ri6yA666ZN8Mlzc8qcKL28BFpOYoyyxRyuTHIXFGhVA1yj3grPleQIDAQABoAAw DQYJKoZIhvcNAQEFBQADgYEAAaG9SkoKbn2mrEB5UyQdd7H/JfZ/3X9cABDXU1wI 9EEVJZKovN5CLYK1sqNICK4bxrDW/vVTvHJlm1TcCB73oI7SOtWxdL/aw3T5fKwb bbavvP4NM+7oht/Ut1aplNR9zP4RNQ16d0qsuB83ASIJFYadkHfbk5YM0XJYkve+ WNc= Does anyone know of a way to convince AdminServer to sign certs for less than 20 years? I'll buy you a pizza and beer...


  • 3.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    Posted 01-22-2018 14:56
    Early indications are that the only solution to this problem is to upgrade to 2016 R1 or higher. I hear you can copy the cert from a phone that is still working to one that isn't but sooner or later that cert will expire and you will be completely stuck.


  • 4.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    GENESYS
    Posted 01-22-2018 15:35
    Based on info from my sources, there is no workaround. You have to upgrade to 2015 R1 at a minimum, preferably to the latest release.


  • 5.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    This message was posted by a user wishing to remain anonymous
    Posted 01-24-2018 12:38
    Hi; As i know, all of the CIC 3.0 users having same issue. Genesys must answer this problem. All the problems started at the same day. Regards


  • 6.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    GENESYS
    Posted 01-24-2018 15:42
    If I may point out, 3.0 was End of Maintenance on Dec 31, 2016: https://my.inin.com/products/Pages/product-version-end-of-life.aspx "CIC 3.0 Last Order Date: 31 December 2013 End of Maintenance:31 December 2016 End of Support: 1 July, 2018" As noted on the EOL policy page https://my.inin.com/products/Pages/product-eol-policy.aspx "New*software change*requests (SCRs) after the End of Maintenance (EOM) period will require you to update to a newer version of the software that contains the change."


  • 7.  RE: Jan 19 2038 bug in certificate signing (3.0 SU 12)

    Posted 01-24-2018 15:39
    Originally posted by GGanahl;36628
    Based on info from my sources, there is no workaround. You have to upgrade to 2015 R1 at a minimum, preferably to the latest release.
    Thank you for the confirmation that there's no work around.. our reseller hadn't been able to give us any confirmation of that (we aren't currently under maintenance, so I guess they were unable to talk to Genesys to get a confirmation). What we are ending up doing is ripping the Soft Phone out of our infrastructure and replacing it with a different softphone app. In our case, we're using MicroSIP for now; seems to work well, although it doesn't support the Alert-Info header method of auto-answer so I'm setting the stations to be persistent connections and having MicroSIP auto-answer ALL calls.. I'm working on modifying the source code for MicroSIP to deal with the Alert-Info header properly, but for now things are working well in our infrastructure (24x7 call-center with generic stations not assigned to a specific user) Fun times ;-)