danielv wrote:
>
This is a common problem with certs, webpages, and current browsers.... the problem is the cert was created for a named domain and not an IP range, in this case the IANA reserved home network ranges. The browser has to be told to allow this cert and ignore the error about the ip being used in place of the name. All common current browsers seem to have this ERROR message ( chrome, Firefox, edge(ms chrome), opera, and others ), but the error is just the named cert fails to match ip given and domain because it's using *.domain in the cert.
METHOD #1 (Basic Fix) : add an exception to this page in the browser it should load without issue. see your browsers documentation for the steps to allow and by pass the error. most common Advanced Except or Allow.
it's not a bug on the TNAS side, but the cert subject alternative names being specified. The web interface cert has these two entries :
DNS Name=*.tnas.link
DNS Name=tnas.link
NO IP addresses listed - thus causing your problems.
METHOD #2 (Advanced Fix) : use local dns and hostname to resolve the TNAS.tnas.link name to your ip.
Steps:
use putty and ssh to the tnas console ( login is the same as your web page admin name and password)
enter hostname (hit enter) on that command to get the host name for the NAS on your network
make a dns change to add the pointer to resolve the name like this
my host name in linux is : TNAS-F5-422
we know the domain is : tnas.link
now to add a corrective record (CNAME) or authority name (ANAME) record
hostname : TNAS-F5-422.tnas.link
DNS NAME : TNAS-F5-422.tnas.link A record on local dns (192.168.xxx.xxx where xxx is your network segments)
cert : auto from Tnas
URL :
https://TNAS-F5-422.tnas.link:1234/tos/#/ ( where 1234 are the ports you choose, in place of defaults 8080 or 8181)
In this method you are going to poison the dns on the local network to redirect any traffic from the local lan to your TNAS for a hostname and domain TNAS-F5-422.tnas.link.
I personally use a pfsence firewall for dns, So in my case I go to the Admin home page -> ServicesDNS -> Resolver -> General Settings -> Host Overrides -> "+"
Enter host name from putty as TNAS-F5-422
Domain as tnas.link
IP as 192.168.100.218 (this being the ip assigned to my TNAS)
apply the dns change and wait 2 mins for propagation.
When anything on the lan network interface attached to my firewall looks for the dns name TNAS-F5-422.tnas.link it gets the local lan address of 192.168.100.218, so it resolves correctly.
DNS Lookup from windows will show this
C:\Users\username> nslookup TNAS-F5-422.tnas.link
Server: pfSense.domainnamehere ..... (host that is being used for dns lookup)
Address: 192.168.100.1 .................. (address of the fireall and dns host being used to lookup)
Name: TNAS-F5-422.tnas.link .......... ( named url entered to lookup )
Address: 192.168.100.218 ------------- (ip address that dns returned, address i needed)
the url used in chrome has no error and works with the cert :
https://tnas-f5-422.tnas.link:1234/tos/#/ (Problem solved)
FOR REF. the Public/OPEN Internet resolution of the name TNAS-F5-422.tnas.link
Name: tnas-f5-422.tnas.link
Address 1: 119.28.31.72
As you can see the issue is the cert not the software, you can overcome this error by adding your Tnas system to dns and using the hostname to resolve the url.
METHOD #2 (Expert Fix) : Use your own cert and join the system to your own domain. I will not explain this method as its overkill but should be noted that you can inject your own cert and join a domain. Just create the cert with the static IP in the Subject Alternative Names.... so that the hostname(s) & static IP(s) for a server or cluster all resolve correctly and are covered in the custom cert.
Hope this helps explain the issue with certs subject alternative names being used. The browser is just complaining about the IP not being named in the cert, the best method to fix is use DNS to repoint the traffic to the hostname to resolve the issue.
Cheers Mates :)