Question HTTPS - Connection is not secure

Currently reading
Question HTTPS - Connection is not secure

I have HTTPS running on a bunch of my internal systems, those systems are accessed by IP only. Firefox and other browser complain about "Connection not secure". I understand that the browser can't verify with it being in IP address.

I'm accessing internal content via the LAN but I do VPN into my router from time to time and want to make sure that connection is secure.

  • What's the best practice?
  • My question is, is the actual connection secure? Is the username and PW being sent encrypted?
Because the browser verifies if the host header matches the fully qualified domain name (FQDN) on the certificate. if it doesn’t (when you use the IP address) it gives a warning.

Do you see the lock sign and it still says https://? If so, you should be ok, your connection is encrypted.

To overcome this, you‘ll need to access your hosts using the FQDN. You can install a DNS to resolve internally.
An easier way is to check if your router supports static domain resolution. Should be under DNS configuration if that option is provided.
The warning has nothing to do with the router. The warning by the browser should be something related to the certificate.

If you mean that your VPN is provided by the router and when you connect you see the padlock, you should be ok.
If you click on that “!” does it give you more info about the warning?
Right- I know it's not the router that was just for context. I have several devices, IPCams, etc that are self-signed and the browser gives the error. I've always wondered if that data transmitted is still encrypted.

My router is set up for Synology VPN using Synology DDNS.


  • 2.JPG
    23.5 KB · Views: 36
Right- I know it's not the router that was just for context.
Sorry. Then I should say that I don’t know anything about the Synology router. I’m still on a clunky old router :D

You should be fine. It’s because you’re using the IP address.
Safari browser (iPad, Mac) gives a better message. Clearly says something about the certificate if I remember correctly. I’ll see if I can provide a screenshot.
Last edited:
Like WST16 wrote, this by no means is related to router functionality.

Its is simply how certificate validation in HTTPS works:
a certificate is created for a Common Name (CN) and zero to n Subject Alternative Name (SAN) - never for an ip. If a service is setup to provide https access using this certificate, clients need to addess the service using an URL that either has the CN or one of the SANs as the fqdn.

Though, before you add an exception for the certificate in your client, you might want to inspect it and be sure that is the certificate you used. If a man in the middle attack should ever happen, your client will warn you about a missmatch of the previous trusted exception and the current one.

What is the advantage of running internal services? Is the network you run them not trustworthy? Is the network you use to access them not trustworthy? Imho, https only adds value if services are exposed to the internet or mutual TLS is required to authenticate services amongst each other.

For internet exposed services, I ended up creating this setup:
- pointing a wildcard domain to my router (I host my own dyndns service that daily updates the dns entry to my current dynamic WAN IP using the dns-api of my provider)
- forward the incomming traffic from my router to my docker cluster's port used to publish Traefik
- use Traefik to handle the TLS lifecylce
| - termination of the TLS traffic and forwarding to the target container based on Docker Labels

Recently I added KeyCloak to the mix, to get some sort of SingleSignOn. When you try to access the first target service, you will be forwarded to a KeyCloak login screen and returned to your target service after a successful login. SSO only works consistant for services that support OIDC/SAMLv2 or the X-FORWARD-USER header ootb... everthing else might require a second login in the target application.
The internal LAN is trust worthy but I wanted to enable it. I got thinking about it more now that I'm playing with VPN and sometimes I'll web into the router.
The internal LAN is trust worthy but I wanted to enable it. I got thinking about it more now that I'm playing with VPN and sometimes I'll web into the router.
Having a DNS server on the LAN (or a static DNS on the router) will benefit the users locally (the’ll be able to use the FQDN to reach hosts).
However, for VPN users, it’s more complicated.

Are you using OpenVPN?
I believe you’re running VPN Plus on your RT2600. But what service are you using?

VPN services supported:
WebVPN, SSL VPN, SSTP, OpenVPN, L2TP over IPSec and PPTP.

I don’t think you’re using OpenVPN– the name didn’t ring a bell! I hope it’s not PPTP. That’s the weakest of them all if I’m not mistaken.

Take a look at this for a quick explanation. If it’s too long, scroll down for a summary.
If you're accessing the web site using HTTPS but the URL is using the IP address (screenshots mention IP) then you need to add those IP to the Subject Alternate Name of your certificates ... but why would you do that because then you are providing information about your internal LAN to anyone that can make a HTTPS connection.

All Firefox and Safari are saying ... IP address isn't listed in the Subject Alternate Name list of the certificate that is being used to secure this web site. You can tell the browser to proceed and add an exception (or whatever they call it) for this IP for this certificate.

If you are making a SSL-VPN connection to the router then all you traffic will be internal once.

Also remember that RFC 1918 provides for reserved IP ranges than cannot be routed across the public Internet. Most LAN/WLANs will use these ranges for their private networks. It looks like you're using them too.

I had a thread describing this same exact scenario.

First, you can’t use local ip’s in the certificate SAN field; the regulating group removed that functionality years ago

Secondly, I was able to resolve this just by using my Synology DDNS name which is link with let’s encrypt certification. In my dns of the router I created a dns entry so that when I entered the Synology DDNS hostname locally or vpn it gets redirected on the router to the local ip and the traffic stays local (traffic doesn’t go out to the internet and then back to you local nas). I was able to test this by command line tracert and only saw the local hop when using the DDNS name locally or vpn. When using the DDNS name remotely then it goes through the internet and tracert would have many hops.

In order for you to get a secure connection locally you have to use the DDNS name that is configured for the certificate. In my case I’m using Synology ddns with lets encrypt. Some routers can detect that you’re local when using the ddns name, however in my case the key was going into the dns server portion of the router so that when it saw it knew to send it locally to

Here is my thread where this was discussed as well. Solved - SSL Certificate Error

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Question
Hi The WebVPN works with other endpoints (but they are all HTTP) , when we try to initiate to the https -...

Welcome to! is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads