Hoping some of smart people here may know a fix for this. The lets encrypt certificate for PBX uses a FQDN which is slightly different than our internal Windows DNS server issues as internal and external references are different. Cert is issued for PBX.xxxx.com whereas internal DNS is PBX.yyyy.xxxx.com.
So I can link the internal IP to PBX.xxxx.com in the hosts file of a local Windows machine and be directed to the correct IP and access the PBX secure without error. But on a machine with no such linkage I am resolved to mail.yyyy.xxxx.com by every browser (which is not at all the correct IP).
I have no clue what the issue is, as pinging to PBX.yyyy.xxxx.com and mail.yyyy.xxxx.com each bring the correct IP for each independent web interface. It is just in browsers. I am wondering if browsers are ignoring local DNS and unknown to me searching some browser based DNS for security? But can’t figure it out. Happens in Chrome, Firefox, Brave, Edge. Not sure why browsers check hosts, but not local DNS. Interestly, on an old Windows using iExplorer going to https://PBX.yyyy.xxxx.com resolves to the correct IP, but just shows a cert error.
For security purposes, browsers (and IP phones) should not use DNS at all. They should validate the certificate against the name provided by the human.
Your browsers don’t have any method to resolve IP’s or FQDN’s, that is done by the underlying OS, where commonly a local ‘hosts’ cache is first consulted and if no resolution then the OS will use DNS which then uses the OS’ ‘routing table’ to forward the connection, the DNS server used might be either ‘statically assigned’ (locally explicit) or the ‘Dynamically Assigned’ one sent in the original DHCP request for an IP.
The HTTP-01 protocol used by FreePBX’ certificate manager needs whatever is answering on http://PBX.xxxx.com:80 as determined by the ‘Certificate Authority’ in use (in this case LetsEncrypt) to respond to a write request to a ‘well-known’ location in an orderly fashion.
So the user account of the browser in question MUST have PBX.xxxx.com resolve to the PBX server and that again is not done by the browser but the local OS of the host on which the browser in question is running 
.
Given that you have a Windows DNS server internally under your control this couldn’t be easier to resolve. Just create a new Forward Lookup Zone that corresponds to the external fqdn of the system that you are issuing the certificate for (so presumably pbx.xxxx.com) and then once the zone is created add a new A record inside of it with leaving the name field empty and setting the IP address to the internal IP of your PBX.
Now any internal host that uses your Windows DNS server will resolve the external FQDN to the internal IP of the phone system.
Thanks. This seems to work.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.