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.
Hi,
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 https://docs.certifytheweb.com/docs/backgroundservice.html 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 127.0.0.1 like one of the FAQs suggested.
Still unable to browse the api system. 
@wpp - you mentioned you are unable to bind to 127.0.0.1 (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:
e.g. my-webserver.int.domain.com
@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 127.0.0.1 and the service was started.
In any case, now it works and others have an additional work around in weird edge cases. 
@webprofusion
I got the same exact problem. With no errors in logs. Can I please get a step by step approach to resolving this? I am an experienced dev but with only rudimentary knowledge of server administration.
We have ~10 websites on our server and I need to certify a subset of them, not all.
I did the localhost ping, it did resolve to ::1
After doing the registry edit, I got this message:
The services exceptions log had:
[4/2/2019 1:02:24 PM] :: Service failed to listen on http://localhost:9696. :: System HTTP Service: Running :: Attempting to reallocate port. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Net.HttpListenerException: The format of the specified network name is invalid
at System.Net.HttpListener.AddAllPrefixes()
at System.Net.HttpListener.Start()
at Microsoft.Owin.Host.HttpListener.OwinHttpListener.Start(HttpListener listener, Func2 appFunc, IList1 addresses, IDictionary2 capabilities, Func2 loggerFactory)
at Microsoft.Owin.Host.HttpListener.OwinServerFactory.Create(Func2 app, IDictionary2 properties)
— End of inner exception stack trace —
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Owin.Hosting.ServerFactory.ServerFactoryAdapter.Create(IAppBuilder builder)
at Microsoft.Owin.Hosting.Engine.HostingEngine.Start(StartContext context)
at Microsoft.Owin.Hosting.Starter.HostingStarter.Start(StartOptions options)
at Certify.Service.OwinService.Start() in C:\Work\GIT\certify\src\Certify.Service\Program.cs:line 190
After configuring outbound+inbound rules in windows firewall, the next invocations didn’t throw the above exceptions but threw the first one (the one in the OP) again…
Hi, it has nothing to do with firewall rules and in fact if you allow external incoming connections to your server on this port it’s a security risk, so don’t do that.
The error is stating that something else is using port 9696. Edit your serviceconfig.json and change the value of “host” from localhost to your fully qualified local server name e.g. “myserver.domain.com”. Change the “port” entry to another alternative port such as 19696. Then restart the Certify background service and restart the UI.
While trying to get the FQDN, I get the error that I am not a domain user. I am logged in as root. I tried with this: whoami /FQDN
Well I replaced host with one of the IP addresses instead and it worked.
All you’re really trying to do is get the machine to talk to itself, it can be by IP or name. Try finding out what the local IP (v4) address is and point to that. As you had an error related to binding to port 9696 that may suggest the only issue is you have something else running on port 9696, so you may only have to change the port and could perhaps leave host set to localhost or 127.0.0.1
Even changing only the port didn’t work. Thus I tried with one of the IP addresses assigned to the server.