Client app will not connect to service


I am unable to open the v4.1.4 client on Server 2016 (fully updated).

The service is running. The client will not connect to the service.

Browsing to http://localhost:9696/api/system/appversion returns page can’t be displayed.

I’ve tried uninstalling, deleting C:\ProgramData\Certify, and reinstalling.

Nothing is listening on port 9696 whenever the service is not running.

Out of ideas on this one. Any guidance is appreciated.



Double check the service is running and there are no binding errors reporting in c:\programdata\certify\logs\service.exceptions.log (worth checking the session.log as well). If not then refer to and try re-configuring either the port or the host (to the local IP instead of ‘localhost’).

If all appears well there then try browsing to http://localhost:9696/api/system/appversion using the local browser on the server itself.

If you cannot access the API then you likely have a configuration which is actively blocking the service (most commonly a security product like Norton/Kapersky which is doubling as a local firewall).


Thank you for the replay. I’ve looked at the logs and everything looks OK.

[2/11/2019 10:20:25 AM] :: Service API bound OK to http://localhost:9696

2019-02-11 10:20:25.096 -05:00 [INF] Certify Manager Started

I’m unable to bind to like one of the FAQs suggested.

Still unable to browse the api system. :no_mouth:


@wpp - you mentioned you are unable to bind to (which is normally localhost using ip v4)- why is that? Are you running ipv6 only?

If the service binds OK but you can’t browse to it locally (on the server itself) then something you have installed is blocking it. Check what security software you are using and see what blocking it does by default, you may need to add an exception.


Thank you for the assistance. Apparently, Windows 10/Server 2016 prefers IPv6 loopback address.

I was able to connect to the service by doing the following:

  1. Set Windows to prefer IPv4 via registry change.
  2. Change service config to the FQDN of the computer. e.g.
  3. Restart the service and client.


@wpp thanks thats interesting! I think what probably solved it was the FQDN? Certify is developed on Windows 10 Pro 64-bit and tested on Server 2016, on these systems pinging localhost resolves to ::1 (the IPv6 address). It’s probably too late not but it would have been interesting to know what pinging ‘localhost’ on your server resolved to, before your change (was it not ::1?).


I believe the actual fix was changing to FQDN for the service address.

Memory is foggy, but I believe localhost was still unaccessible. Even though it resolved to and the service was started.

In any case, now it works and others have an additional work around in weird edge cases. :sunglasses: