# Web Server URL Domain Name Fails to Resolve **URL:** \ **Category:** Ignition\ **Created:** [January 7, 2026, 11:28pm UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140 "2026-01-07T23:28:41Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![collin.ernst](https://avatars.discourse-cdn.com/v4/letter/c/45deac/32.png) [@collin.ernst](https://forum.inductiveautomation.com/u/collin.ernst)\ **Post date:** [January 7, 2026, 11:28pm UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/1 "2026-01-07T23:28:41Z")
Hello! I have recently worked with my customer’s IT team to obtain a TLS certificate for our Ignition gateway. Applying the certificate was successful, but afterwards I am still unable to use the domain name we setup in the certificate. Is there something I am missing here? I can confirm that the inbound ports on 8088 and 8043 are open. I can access the gateway by navigating to https:server\_name:8043, but receive a certificate error because that does not match the domain name we have setup in the certificate. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 7, 2026, 11:32pm UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/2 "2026-01-07T23:32:41Z")
You have to be able to navigate to `https://full.domain.in.cert:8043`. If your customer hasn't established that name in their DNS infrastructure, the certificate is useless. You need the full name to resolve to the server IP, and you must **use** the full name in all of your links/configurations. (I would also recommend switching your gateway to use ports 80 and 443 like a proper webserver.) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 8, 2026, 12:17am UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/3 "2026-01-08T00:17:16Z")
If you cannot use the full name in your application URLs, there might be some options to consider in the certificate's Subject Alternate Names. **But** , if your cert is from a globally recognized authority, you will only have these options: - Known private IP addresses (10.x.y.z, 172.16.y.z through 172.31.y.z, and 192.168.y.z) can be added to your cert and then you can access the gateway by IP address. - Full domain names that alias to the primary name can be added, with the same proof of control over the names. Really big, old companies that actually own a public subnet can add those, too. With a private certificate authority issuing the cert, you can put just about any names or IPs into the SAN field, including something like the bare `server-name`. (But note that underscores are not valid in domain names--must be dashes.) ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [January 8, 2026, 4:03am UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/4 "2026-01-08T04:03:25Z")
> [@collin.ernst](#): > > navigating to https:server\_name:8043 Try accessing the server using the FQDN for your server by adding the domain name of the company after the aerver name. For example, https://server\_name.company\_domain.com:8043. Hopefully the certificate is valid for your server name (\*.company\_domain.com, etc). ---
**Author:** ![collin.ernst](https://avatars.discourse-cdn.com/v4/letter/c/45deac/32.png) [@collin.ernst](https://forum.inductiveautomation.com/u/collin.ernst)\ **Post date:** [January 8, 2026, 1:48pm UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/5 "2026-01-08T13:48:21Z")
They have registered the domain name in their DNS infrastructure. I am able to use nslookup to see that it matches the IP expected. Now instead of getting “no domain” error we are instead getting “connection refused”. Once again, I can confirm that we do have port 8043 open for inbound traffic. ---
**Author:** ![collin.ernst](https://avatars.discourse-cdn.com/v4/letter/c/45deac/32.png) [@collin.ernst](https://forum.inductiveautomation.com/u/collin.ernst)\ **Post date:** [January 8, 2026, 1:52pm UTC](https://forum.inductiveautomation.com/t/web-server-url-domain-name-fails-to-resolve/113140/6 "2026-01-08T13:52:06Z")
Must be something architecture dependent on the customer side. I changed the port to 443, and suddenly the connection is no longer refused.