Changed server provider. Not getting notification callback

Hey Fernando, There are no settings on our side for this. Have you white listed the IP addresses for eSignLive on the new server? https://community.onespan.com/documentation/onespan-sign/guides/quick-start-guides/developer/environment-urls-ip-addresses#aanchor88

I'm pretty sure our API is open for any IP but I'll make sure. Can you confirm which IP address it would come from? The answer on that ticket doesn't cover the version we're using. We're using "apps.e-signlive.com". Fernando

Take a look at this page: http://docs.esignlive.com/content/d_esignlive_connectors_guides/salesforce/salesforce_v4.0/deployment_guide/esignlive_for_salesforce_deployment_guide.htm#Prerequi If you're using SSL, do you have the certificate installed? http://docs.esignlive.com/content/c_integrator_s_guide/introduction/system_requirements.htm Can you visit apps.e-signlive.com from a browser on the new server?

Michael, I checked with our server provider and I was told that the IP is already whitelisted for inbound traffic. I asked them to also allow for outbound but I don't think this will change anything since it seems like the issue is that eSignLive can't hit our API. Regarding using SSL, I don't think we do, but how can I make sure? I know that we can communicate with eSignLive from our application, like creating packages, signing, etc. And yes, I can visit apps.e-signlive.com from a browser on the new server.

Yeah, allowing outbound traffic didn't work. Is there nothing you guys can check from your servers to see what's going on when it's trying to reach our API? Maybe you guys need to allow outbout traffic to our new IP?

Okay. If you can communicate in all other ways with eSignLive and it's only callback specific, it wouldn't be SSL cert or IP. Let me check into this a bit more and I'll get back to you.

Thanks Michael. I set up an email.callbackfailure and got the following message: Failed to communicate with the callback server. URL: https://api.boardbookit.com/api/esignlive_notification/events Payload: {"@class":"com.silanis.esl.packages.event.ESLProcessEvent","name":"PACKAGE_CREATE","sessionUser":"2MsyYXEfLY0E","packageId":"b66bb128-2e63-4fd5-acdc-318241a590b7","message":null,"documentId":null}

Hey Fernando, Can you try subbing the new IP in for the host portion of the callback URL in your callback settings to see if it works when you do that?

Michael, Got this email right after: Failed to communicate with the callback server. URL: https://209.166.133.108/api/esignlive_notification/events Payload: {"@class":"com.silanis.esl.packages.event.ESLProcessEvent","name":"PACKAGE_CREATE","sessionUser":"2MsyYXEfLY0E","packageId":"fb426d96-d285-46da-b13e-9fac69194e05","message":null,"documentId":null} I expected it not to work because this doesn't even work with Postman: we have multiple websites that are pointing to the same IP so IIS uses the host to figure out which website to go to.

Thank you for testing. We got the same on our side. The next test I'd like for you to try is to try with just http:// instead of https://. We had success with this. This would tell me that you likely need to install the certificate on the new server that I referenced in my second post (or simply point to http since you aren't strictly limiting traffic to https). Let me know.

Michael, Changing to http doesn't seem to solve it. I don't get the email, but I also don't get the notification. I believe this is because we redirect all http requests to https on our load balancer. So I'm assuming it's successfully hitting the load balancer's IP, then it is trying to redirect to https and is failing. So maybe the issue is with the lack of certificate. I'm curious though: why do we need a certificate for this? We have one for our domain, "boardbookit.com". The url is from that domain so isn't this all we need? I can hit our api using https from basically any computer and we don't have any extra certificate. Fernando

Also, coming back to one of your responses: "Okay. If you can communicate in all other ways with eSignLive and it’s only callback specific, it wouldn’t be SSL cert or IP. Let me check into this a bit more and I’ll get back to you." Is this not true anymore? Because we can definitely do everything else successfully. Just not getting the callback.

Okay. I just received more info about SSL communication with eSignLive. 2 way SSL communication isn't supported on callback notifications, so we're back to that not likely being it. The callback will fail if eSignLive doesn’t like the cert on your endpoint (for example, it’s expired, self-signed, etc.). I'm assuming that's not it, so I'll investigate further with R&D to see if we can figure out what's happening from logs.

Thanks Michael. Please let me know what the R&D team finds. Our certificate for "boardbookit.com" is definitely still good. Fernando

Hey Fernando, From the logs, it's saying you're not configured properly with the callback key. So, you likely have a callback key set up in your eSignLive config but aren't handling it on your side? Or your listener is expecting a callback key but it's not configured in eSignLive. Please let me know if you find either of these to be the case. The callback key would be the value that comes through the auth header of the POST request that comes from eSignLive.

Michael, We never had a callback key configured. I just got a call and was told to create a callback key and test again. I updated our account and put a new key (previously we had nothing) in there. After testing, I got the same "callback failed' email. I don't believe this is the issue, since we moved the exact same website from one server to the other and didn't change any configuration whatsoever. Also, if the issue was the callback key configuration, wouldn't the request at least hit our servers? If it was an authentication problem, I would be able to see the request from the IIS logs right? I just deleted the Callback Key again from https://apps.e-signlive.com/account, and it still doesn't work. Fernando

Did you guys confirm that the IP that the callback is trying to reach is the correct one? The issue has to be related to our DNS change since the application is the exact same. Again, our new IP is 209.166.133.108 Fernando

Hey Fernando, That's why I suggested testing with the IP directly vs the host name (https://209.xxx.xxx.xxx/api...) so that we could be sure it's going to the proper IP. The same error seems to happen when doing that. When we tried http and you didn't get the error but also didn't get the notification, did you IIS logs show anything coming in? The causes of the error that was found for these transactions: Callback Test was failed. : javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated All seem to be around the SSL certificate and insecure ciphers. So, looking into what has changed in environments, any problems with SSL certs, etc. between your last server and your new would be helpful information. Here is a pretty good article on the error above and some of the causes: https://dzone.com/articles/how-analyze-java-ssl-errors

Michael, After some testing, I don't think the certificate is the issue. I set up a new website in IIS in one of our hosts, then pointed directly to the IP of that server instead of going through the load balancer (in order to bypass the https enforcement). This new website is pointing to our API as well. Here is the email I got right after trying: Failed to communicate with the callback server. URL: http://209.166.133.106:81/api/esignlive_notification/events Payload: {"@class":"com.silanis.esl.packages.event.ESLProcessEvent","name":"PACKAGE_CREATE","sessionUser":"2MsyYXEfLY0E","packageId":"d16a30cc-f351-4940-88a6-4eab3efcbf96","message":null,"documentId":null} I also validated that it never reached the server because I see no IIS logs. However, when I do it from my local machine on Postman, it works. If you guys want to check the packageId, there's also this other one that I did a little bit earlier: 0ed5642c-727d-439b-925e-fae456320b3b Fernando

Hey Fernando, It sounds like they locked down what the issue was. It did have to do with my last post, only in the opposite manner... It's that you're using the TLS extension SNI (Server Name Indication), which is not supported on the older platform e-signlive.com (10.13.x). However, the 11.x+ applications do have support for this, so when e-signlive.com apps are migrated to the new platform, this setup will work. I believe support already let you know about this, but I'm posting this here to close out this thread and for anyone else that may run into this issue before the migration takes place.

Hey Michael, Did you see my last post? I'm completely bypassing the load balancer (which uses SNI) and going straight to one of our servers using http. It's working on my local machine in Postman, but I'm still having issues with the callback. If the system doesn't support SNI, then that was definitely the issue for previous calls, but now I'm confused as to why this workaround isn't working. Can you check with R&D? To reiterate, the two package id's for those calls are as follows: d16a30cc-f351-4940-88a6-4eab3efcbf96 0ed5642c-727d-439b-925e-fae456320b3b

I also just confirmed with our server provider that any IP is being allowed to the server.

Support has pushed this back to R&D, including the packages indicated for log check and your URL so they can do some testing against it since they control the application logs. Hopefully something will be figured out, soon, but nobody else has reported any issues, so it's unique to something with your callbacks. It's just a matter of determining what that is. Thank you for your patience.

Thanks Michael!

You're welcome. Still waiting on an update from the last two referenced packages. Hopefully we'll have an update tomorrow.

Michael, Thanks for all of your help throughout this process. We have finally reached a conclusion: it seems like my workaround wasn't working because the callback can only be either through ports 80 or 443. So after we corrected that, everything started working as expected. Fernando

Oh. That's fantastic news! Did you notify eSignLive support of this? If not, I can do that for you.

Yes I did. Fernando

Awesome! Thank you! And, of course, let us know whenever you run into any issues! :) Have a great weekend!