My goal is to have the routers built in Wireguard application use a proper certificate that allows its users to use the VPN to access subdomains on the network without having to resolve to using IP's...
If we could understand what is happening here, I wouldn't be posting a question on this forum, I'd be posting a solution.
WireGuard does not need any certificate, it's not OpenVPN.
I guess your DNS entry for the internal systems is wrong. They need to point to the internal IPs, not the WAN nor the routers IP.
I see, so we are going to have NPM handle the resolution to the LAN when users are connected and not the Wireguard VPN application.
I'll look into that and report back.
I am not sure if it is the language or the technical understanding.
To access any (sub)domain, a host needs to resolve the name to the IP. That is how networking works.
But this is not an issue for SSL.
A SSL certificate is issued by a CA.
Else you own a CA and have a PKI running, than your client should trust your CA and all issued certificates... A little overkill.
Or you'll get a certificate from a trusted CA that is providing a Root CA at least in the environment where your clients are...
... And that is where Let's Encrypt comes in. A new provider that is offering free certificates, broad accepted. You neither need to provide a CA nor maintain a PKI. But you have to accept the limits they set.
At first you open a website. Than you check what certificate is provided. Some self signed from console.gl-inet.com ... Great. But note the fingerprint!
Now go to the server, take a look at the service that is listening at port 443 (https) ... It should be nginx.
Take a look at the nginx configuration, there you should be able to find a path to a local certificate.
You could provide an own certificate at this place or any other place on the router. The new certificate should be issued from the certificate provider for the FQDN (hostname.domain.tld) and depending on the system other domain names (hostname, alias) or IP...
As long as the CA, that issued the certificate, is trusted and the root certificate is valid, all clients will connect without error.
If your CA is not trusted (root certificate not known client or not valid), the PKI is not available or the domain/IP called is not listed in the certificate details -> you have a warning.
Let's Encrypt does not provide to add IP to the certificate. Even at the wildcard you won't be able to use SSL via IP with LE.
Appreciate the reply... as stated when we ran wireguard in docker on our host we did not have this issue, now that it is running on the router we do.
After responses here it appears we need to work on our NPM settings to traffic to our host on the lan properly using the LE cert for our domain.
NPM is using ports 80 & 443 and listening for *.ourdomain.com and happily serving from our host and associated ports for each of our Docker apps.
The screen shots I posted above through us off... and we were not clear why we're receiving invalid certs from console.gl-inet.com
Because you are connecting to https://192.168.8.1 (or the changed router IP) and this self signed certificate is what is provided by the local nginx at the router.
I would take the effort and change the certificate in the nginx of the router.
Another way would be a reverse proxy in another docker container, that is handling the SSL to the device. But in this case the client will lose the control over the path reverse proxy to server -> it is not End2End anymore.
But all this hat only a little to do with wireguard. As mentioned before, the SSL errors you are describing are just HTTPS issues.
I think this is the way...
It does not make any sense because the router isn't your proxy. You need to adjust your DNS settings.
@admon change the DNS settings of the router? Instructions would be helpful over suggestions.
The router isn't the problem here. Your DNS entries for your NPM repository are broken (or they don't make sense) - you need to check them. I can't help you with that because we don't know about your network nor setup.
We'll look again at DNS, but this does not explain why it was working with Dockerized WG vs Flint2 WG app not working. I was investigating this thread here Router as Wireguard client blocks LAN reachability to same Wireguard server the router is connected to - #18 by hansome
https://forum.gl-inet.com/t/endpoint-wireguard-vpn-over-wireguard-router-client-vpn/37153/14
Many times in other posts you point to DNS issues and not WG or router settings.
I saw this post;
And on the wireguard client side, remove the route to the wireguard server public IP.
ip route del 1.2.3.4It needs to be firmware 4.2.3 and above.
This way the traffic will go via VPN tunnel otherwise it will go via WAN interface which is not allowed by default.
Before we can discuss this further, please create a network diagram containing IP addresses via draw.io
It does not make sense to discuss this without any diagram.
The diagram must contain: VPN devices, router, NPM server
How does docker expose the services? NAT or IP?
The VPN-Devices are missing. Please include them.
Please don't censor internal IP addresses, we need all of them.
@admon I don't think you ever sleep 
I updated the image
The VPN devices are still missing
And please include an arrow to show which device access which.
I guess it will be 1 VPN device -> NPM host, but not for sure.
So the VPN devices connecting from the cloud or LAN cannot resolve to 192.168.11.170 through NPM
We need a fully featured diagram of the network. You need to include the VPN devices and the IP addresses of those devices. Please include as well if they connect by DNS or IP.
I am sorry, but those details are needed. More information = better.
This is the network diagram, it is really this simple. When connecting via VPN devices are provided a 10.x.x.x IP from the Flint2, LAN is 192.168.11.x IP, also provided by the Flint2. VPN is set to allow access to LAN in settings.