I am experiencing the issue as well… can’t access web-app securely, insecure works fine. My local devices have no issue, nor do remote users.
@Froberg said:
I am experiencing the issue as well… can’t access web-app securely, insecure works fine. My local devices have no issue, nor do remote users.
What results do you get with the DNS queries as instructed by schuyler?
Use Terminal in Linux, Start->Run->Cmd in Windows, to run them
For me, sometimes it is working and sometimes it is not working. I guess, depends on the weather.
I finally decided to disable “secure” connections on my server.
In the end, I want to watch a movie not debug this problematic .direct dns. I appreciate the gesture from Plex, but the solution is far from stable.
Hey I was told to bring my current post over here to help aid the on going investigation into these problems. I’m having a similar issue after the most recent plex updates. I’ll post my original post below hopefully someone might be able to help me out or learn something from my problem.
After the most recent plex server updates I am unable to connect to my plex server securely.
When I try to connect through plex.tv I get the message "The selected server cannot be reached securely. An insecure connection may be possible. I can “reload app insecurely” and I am able to connect and view my library. Currently Remote Access is fully accessible outside of my network and Secure Connections is preferred.
However if I attempt to access my plex server through https://192.168.1.39:32400/web I get a browser error saying your connection is not private and goes on to say:
NET::ERR_CERT_COMMON_NAME_INVALID This server could not prove that it is 192.168.1.39; its security certificate is from *.45f22349c1e64d9db59cc0f7f6def650.plex.direct. This may be caused by a misconfiguration or an attacker intercepting your connection.
I can click proceed anyway in which case I’m brought back to the original plex error that I described of having to reload app insecurely.
If I attempt to go to this url in my browser
https://192-168-1-39.45f22349c1e64d9db59cc0f7f6def650.plex.direct
I get the browser error The site can’t be reached.
https://192-168-1-39.45f22349c1e64d9db59cc0f7f6def650.plex.direct's server DNS address could not be found. ERR_NAME_NOT_RESOLVED.
Upon doing an NSLOOKUP on 192-168-1-39.45f22349c1e64d9db59cc0f7f6def650.plex.direct
it returns:
server: vdnssec1.srv.hc1ny.cv.net address: 167.206.13.180
To my knowledge this is my ISP’s DNS server address.
My server has Centos 7 installed on it with apache and Bind DNS, I use webmin to manage and configure the two servers. I have a Linksys AE4200. On which all the proper ports are forwarded. I have read into the DNS rebinding issue and I am not aware of any settings on this router for that. I don’t know much about how plex’s whole system works now with all this but if I had to assume I would say there is some sort of conflict between my web/dns server and plex. I run plex on this server because it is always on in order to host my websites. Has anyone had any issues similar to this? Is there something I need to configure in bind in order to get this to work properly? I understand that the server currently works if I refresh the app insecurely but I would like to get it working without having to do that. Any help you guys could provide would be appreciated.
@K_Seymour said:
However if I attempt to access my plex server through https://192.168.1.39:32400/web I get a browser error saying your connection is not private and goes on to say:
NET::ERR_CERT_COMMON_NAME_INVALID This server could not prove that it is 192.168.1.39; its security certificate is from *.45f22349c1e64d9db59cc0f7f6def650.plex.direct. This may be caused by a misconfiguration or an attacker intercepting your connection.
This is normally indicative of a certificate mismatch. Signing the server off and in within the settings/server screen should generate a new certificate which you can then see reflected by having a new certificate hash string within the plex.direct url showing in xml from https://plex.tv/pms/resources.xml?includeHttps=1
The nslookup response you gave is not complete. There would be another line or two. The 167.206.13.180 is probably your ISP’s DNS Server.
Try to go through sign out and sign in within settings / server page and check plex.tv for the xml and then do the nslookups.
@sa2000 said:
This is normally indicative of a certificate mismatch. Signing the server off and in within the settings/server screen should generate a new certificate which you can then see reflected by having a new certificate hash string within the plex.direct url showing in xml fromhttps://plex.tv/pms/resources.xml?includeHttps=1
I signed the server off as you said and you are correct it gave me a new certificate hash which I’ll post below:
<MediaContainer size="1">
<Device name="nassautechnologies.com" product="Plex Media Server" productVersion="0.9.16.4.1911-ee6e505" platform="Linux" platformVersion="3.10.0-327.13.1.el7.x86_64 (#1 SMP Thu Mar 31 16:04:38 UTC 2016)" device="PC" clientIdentifier="2bdd5195be691df9d80d604cfa588cc2b0724396" createdAt="1449498865" lastSeenAt="1461096483" provides="server" owned="1" httpsRequired="0" synced="0" publicAddressMatches="1" presence="1">
<Connection protocol="https" address="192.168.1.39" port="32400" uri="https://192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct:32400" local="1"/>
<Connection protocol="https" address="69.116.xxx.xxx" port="32400" uri="https://69-116-xxx-xxx.c1144aa6c6ff46f9afd139297f18649a.plex.direct:32400" local="0"/>
</Device>
</MediaContainer>
However all of the original problems still persists, I’ve just been using command prompt to run nslookup with this command: nslookup 192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct
Am I doing that right? this is what it returns:
Server: vdnssec1.srv.hcv1ny.cv.net
Address: 167.206.13.180
vdnssec1.srv.hcv1ny.cv.net can't find 192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct: non-existent domain
Edited by sa2000 to mask out public ip
Could you do the nslookup again - adding 8.8.8.8 at the end
nslookup 192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct 8.8.8.8
And then repeat for the public ip url for plex.direct without 8.8.8.8
nslookup 69-116-xxx-xxx.c1144aa6c6ff46f9afd139297f18649a.plex.direct
substitute full public ip string
If that succeeds and the one local ip url translates through 8.8.8.8 then it is simply DNS Rebinding protection in your router
C:\Users\Kurt9>nslookup 192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: 192-168-1-39.c1144aa6c6ff46f9afd139297f18649a.plex.direct
Address: 192.168.1.39
C:\Users\Kurt9>nslookup 69-116-xxx-xxx.c1144aa6c6ff46f9afd139297f18649a.plex.direct
Server: vdnssec1.srv.hcvlny.cv.net
Address: 167.206.13.180
*** vdnssec1.srv.hcvlny.cv.net can't find 69-116-xxx-xxx.c1144aa6c6ff46f9afd139297f18649a.plex.direct: Non-existent domain
C:\Users\Kurt9>nslookup 69-116-40-35.c1144aa6c6ff46f9afd139297f18649a.plex.direct
Server: vdnssec1.srv.hcvlny.cv.net
Address: 167.206.13.180
*** vdnssec1.srv.hcvlny.cv.net can't find 69-116-40-35.c1144aa6c6ff46f9afd139297f18649a.plex.direct: Non-existent domain`
So does that mean its dns rebinding on my router? Is there anything I can do about that? I have a linksys E4200.
As i understand it, if you get an answer other than what the query looks like, that’s rebinding. Meaning if 69-116-40-35 came back as 1.2.3.4 you would be experiencing rebinding by your ISP.
what you get is a ‘nothing found on our server’ message (meaning they don’t even know what plex.direct is).
Another type it might be: a Failure (as you see), then a wrong result, then something else entirely where it appears the ISP is being deliberately misleading / ‘protecting’ you.
@ChuckPa said:
As i understand it, if you get an answer other than what the query looks like, that’s rebinding. Meaning if 69-116-40-35 came back as 1.2.3.4 you would be experiencing rebinding by your ISP.what you get is a ‘nothing found on our server’ message (meaning they don’t even know what plex.direct is).
If the public IP plex.direct succeeds in nslookup returing the public IP and the local IP plex.direct fails saying unknown or does not exist then this is DNS Rebinding
If both fail saying unknown then the DNS Server does not appear to know about plex.direct
@K_Seymour said:
So does that mean its dns rebinding on my router? Is there anything I can do about that? I have a linksys E4200.
No - because the public IP also failed with your default DNS
Did you enter the actual public IP Address string or the version i put here with xxx-xxx ? I only put xxx here to hide your actual public IP address. The tests need to be for the actual string from the https://plex.tv/pms/resources.xml?includeHttps=1
Could you also do these tests - copying each as they appear
nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8
nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8
Thanks SA.
So any news on this? Did we allready got a root cause?
I mean this domain stopped using the rebinding right? When I check my https://plex.tv/pms/resources.xml?includeHttps=1 list I get two addresses for my server and one is internal and one is my public. Using a provider that works or googles dns I get the proper ip responses and they never change, so they are not using rebinding right?
Since the site info pages still talk about rebinding the provider support claims you are using rebinding. So I need to be sure.
@Kaoh said:
So any news on this? Did we allready got a root cause?
I mean this domain stopped using the rebinding right? When I check my https://plex.tv/pms/resources.xml?includeHttps=1 list I get two addresses for my server and one is internal and one is my public. Using a provider that works or googles dns I get the proper ip responses and they never change, so they are not using rebinding right?
Since the site info pages still talk about rebinding the provider support claims you are using rebinding. So I need to be sure.
Do both URLs from the connection info in the resources xml fail to translate when doing nslookup with your default DNS?
Yes both fail to resolve giving a non existing domain. While both resolve fine using the 8.8.8.8 dns server.
In the forum of KPN I see someone also complaining about the same system not working for his 37-48-67-5.cloud.leaseweb.net domain. So it seems related to the dynamic IP part of the domains.
@sa2000 said:
@K_Seymour said:
So does that mean its dns rebinding on my router? Is there anything I can do about that? I have a linksys E4200.No - because the public IP also failed with your default DNS
Did you enter the actual public IP Address string or the version i put here with xxx-xxx ? I only put xxx here to hide your actual public IP address. The tests need to be for the actual string from the
https://plex.tv/pms/resources.xml?includeHttps=1Could you also do these tests - copying each as they appear
nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8 nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8
I did both after realizing the first instance had xxx.xxx. However after reading what you said I changed my computers ipv4 settings from dynamic to static and made my dns servers 8.8.8.8 and 8.8.4.4. And I can now through plex.tv connect to my server and its all green. Does this mean that my ISP’s dns servers are the issue? I also changed my servers dns servers to google. If someone else whom I share my libraries with tries to connect who also has the same ISP I do will they be able to connect securely?
If you both have the same ISP, before using your DNS settings blindly, give those same tests a quick run. Granted, you’ll probably get the same results but better safe than sorry.
Once concluded you have the same issue, make the switch.
To answer your question: Since your ISP’s DNS didn’t know who ‘plex.direct’ is but Google does, your ISP isn’t supporting ‘.direct’ correctly / at all.
Given the options and headaches. OpenDNS or Google are your two best options. OpenDNS is less ‘ominous’ than the Google-machine in the eyes of many.
The problem is that the nslookup to plex.direct does give results just not to the dynamic part (when the ip is in the dns name) I also notice that your plex.direct domain is not being able to list the a records since they are dynamic. So I think that is the problem, they tried to solve some security issue and it is breaking the support of these dynamic ip-dns name mappings. So the conclussion is that the provider is at “fault” here and they can hide behind the security argument. And switching our DNS server is only going to solve a part of the problem and causing others. If we have a LAN with other machines your DNS resolving will fail to those names.
Also my Phone provider has the same (its the same provider) problem so getting a secure connection from the outside (you know when it really matters) is still not possible.
Can I ask for an option in the apps to allow us to overrule the DNS server used by the app to resolve the names? You know that I can ask my Plex app to use the OpenDNS or Google. Since I can not manage that for the 4G connection using Phone settings.
The results we’re seeing are two-fold.
- the non-population of the .direct domain by the ISP (hence the no-records error)
- the rebinding / rebinding-protection with incorrect results being returned.
You are correct, switching the server’s DNS only solves one part of the problem.
The issue is being worked on as we converse here. I only know, from things said to me, efforts / changes are ‘in production’… What that means has no context to me yet (been a Ninja less than a month).
It might mean part of the solution is already in the PlexPass version as there is mention of ‘Services’ and DNS is a Service
@ChuckPa said:
@Froberg said:
I am experiencing the issue as well… can’t access web-app securely, insecure works fine. My local devices have no issue, nor do remote users.What results do you get with the DNS queries as instructed by schuyler?
Use Terminal in Linux, Start->Run->Cmd in Windows, to run them
nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
Server: myhome.mynet
Address: fd29:ec85:ba38:0:202:61ff:feab:be2e
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
C:\Users\Bjørn>nslookup 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: 192-168-0-10.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
Address: 192.168.0.10
C:\Users\Bjørn>nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
Server: myhome.mynet
Address: fd29:ec85:ba38:0:202:61ff:feab:be2e
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
C:\Users\Bjørn>nslookup 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: 1-2-3-4.aaaaaaaabbbbbbbbccccccccdddddddd.plex.direct
Address: 1.2.3.4
It’s been working fine for months and months… suddenly this happens. I think I may have to disable secure access until this can be resolved.
