I have a blocklist for my internal network that reroutes the user to another IP address should there be a match. This is managed via SimpleDNS and a tool within that program. The rerouting works and it goes to the IP address.
Code on the IP website then logs the hit and reroutes to a fully qualified domain and shows the user a message.
Except I now have an issue inbetween SimpleDNS rerouting to the IP and the friendly page being showen
Your connection is not private
Attackers might be trying to steal your information from www.starbucks.co.uk (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
Automatically send some system information and page content to Google to help detect dangerous apps and sites. Privacy policy
(starbucks.co.uk is just a test site in the blocklist)
I can then click on the Advanced > Proceed and it goes to the correct location but is there anyway I can bypass that. I'm guessing it's an ssl issue somewhere somehow.
Setup is Windows Server 2016 running IIS. I have an SSL on the end domain which is installed and works correctly.
Thanks
Paul
Related
When accessing https://mcgillcrm.com some users are seeing this in chrome: ERR_SSL_PROTOCOL and this is firefox: SSL_ERROR_RX_RECORD_TOO_LONG
But it only happens when they access the site through a specific ISP (Videotron).
When the site is accessed via a hotspot or when connected to a different ISP it works fine and it also works if the user is using Windows machine instead of a Mac.
I verified SSL labs, checked port 443 and compared against another site where it doesn't throw this error and everything seems fine.
We have a 301 redirect towards https and I double checked that users really type https:// when accessing the web-site, but it still doesn't work.
How is the connection done to the ISP vs. how is the connection done to a different ISP or mobile network
Mac user connects to the wireless modem: SSL errors come up
Mac user connects to the wireless mobile hotspot: No error comes up
Update 12 Oct 2022
We re-installed a new certificate from scratch and this one is not showing 'self signed' anywhere. Will see if it helps.
HTTPS is end to end encryption and integrity protection. It should not depend on the ISP used by the client. If it is specific only to the ISP or specific clients then something is messed up at their end, like some middleboxes or antivirus interfering with the connection, a captive portal asking the client to acknowledge some rules first, DNS resolution pointing to a different IP then yours etc. There is nothing you can do from the server end against this, since maybe the server is not even reached by the client.
Problem turned out to be with safebrowse.io which was somehow caching the incorrect certificate (clearing SSL cert in chrome didn't help).
It in turn affected other browsers also like Firefox. So once the incorrect cert was cached it flagged it globally as an unsafe site..
It looks like it was cached inside the logged in users chrome profile (Google Workspace account).
Solution was to login as Guest > Go to web-site > Click 'Proceed anyway' > Restart Chrome
This looks like a serious design flaw with safebrowse.io, why/how it caches SSL certificates in Chrome profile is unclear. This should have worked while accessing the web-site in Chrome incognito but it didn't..
I've run into a strange problem. If I put a site name in the site bindings, the Default Web Site on ISS is not recognizing it. Suppose I leave it blank, then I'm able to get the pages but they show up with the server IP address.
This is a problem because with SSL, it will either not serve pages or it will give me a site warning.
Note that I have the DNS working of GoDaddy with forwarding and masking to the public IP of my EC2 instance on AWS.
All of this started overnight when the SSL cert expired. I have since put a new certificate that's valid but I cannot get the site working again.
I've done a lot of debugging including diffing the old configuration that was working with the new one and I'm not able to understand why this happens.
Setting the site name causes both http and https to not work.
Much appreciate any help in solving this - Thanks in advance!
This appears to be a problem with masking with forwarding provided by the domain host Go-Daddy. For some reason, with masking with forwarding, the response is enclosed in a frame and that frame says the src is the public IP address of the server rather than the domain name.
I also think that there is a problem with https forwarding with masking. While the reason this problem happened is not clear, for now, the fix has been to change the domain from masking with forwarding for http requests alone to point at the http server public IP address.
This is not the ideal solution but at least has the website back up and running. I'll post an update once I know more about masking with forwarding and why that suddenly stopped working.
I've been trying all day to set up my instance of TFS2017 to work with HTTPS.
I've read the official setup guide, but it didn't help much.
My instance is attached to a domain and configuration has been made with an Administrators group user. The domain account is referenced as an administration console user properly.
The setup has been made with default 8080 port and domain account user can access the website as expected (hosted at http://machine-name:8080/tfs)
Now, when I change the IIS website settings binding to use HTTPS on port 443 with a valid wildchar certificate + set the hostname to be tfs.mydomain.com + ask for SSL require, I cannot have my user to authenticate anymore.
I make TFS Public Url point to https://tfs.mydomain.com/tfs.
I get prompted for the authentication box, but after many attempts, the site would just fail with 401.
The tests are made into the server environment to avoid Firewall confusions.
My instance has two network cards with 2 separate networks. First resolves to public IP, second resolves to private IP. I noticed the configuration works with the machine names, while it fails with the DNS resolution on the public IP. Could this be a reason ?
Thanks for your help
To perform the procedures in your requirements, you must first meet some prerequisites such as required Permissions and so on. Please double check this first. Also please make sure you have set up the corresponding ports such as below prompted.
Important:
The default port number for SSL connections is 443, but you
must assign a unique port number for each of the following
sites: Default Website, Team Foundation Server, Microsoft Team
Foundation Server Proxy (if your deployment uses it), and SharePoint
Central Administration (if your deployment uses SharePoint).
You should record the SSL port number for each website that you
configure. You will need to specify these numbers in the
administration console for Team Foundation.
There is a very detail tutorial about configuring HTTPS with SSL, please refer Setting up HTTPS with Secure Sockets Layer (SSL) for Team Foundation Server
To narrow down the issue with IP, you could disable one of your two network cards. Give a test with only using one network card each time.
When there genuinely is no web server installed on a machine, and the user types in the machine's IP address or FQDN into the web browser, the user will get a genuine "can't connect to the server" message from the web browser.
However, after installing the Apache web server, the direct IP address and the FQDN (i.e. archimedes.example.com) will now show the default "It works!" page. How can I make my server act as if there is no server in these places (for the IP and the FQDN)?
Note that a 404 error does not qualify, because that makes it clear that a web server is available.
Is this even possible to do in the first place?
The goal of this is that I just want my regular websites, say genuinewebsite.com, that is genuinely supposed to be on this server to be recognized. All the other "default" addresses (the IP address and FQDN) that really have no connection to any websites should just act as if there is no web server there in the first place.
No, it is not possible, because to get the hostname the browser used for the request, the browser first has to connect successfully and send it in the request. By that time, you can't really refuse the connection; the best you can do is close it on them which will appear as a connection reset error.
First URL stands for Uniform Resource Locator. It will be very difficult to remember an IP address. Instead of remembering the IP addresses URL came like www.intrepidkarthi.com. Url normally contains three parts. For example http://intrepidkarthi.com/index.php. Here "http" refers to the protocol it uses. Then the server name and then the requested file name.
Here I have enlisted the flow of working mechanism behind your browser
The flow of work
Your browser communicates with a name server to translate the server name "www.intrepidkarthi.com" into an IP Address, which it uses to connect to the server machine. * So your browser will see if it already has the appropriate IP address cached away from previous visits to the site. If not, it will make a DNS query to your DNS server (might be your router or your ISP's DNS server). DNS stands for Domain Name Server - For exapmle if you want to get karthik's phone number then you will look into your telephone directory. Likewise your computer doesn't know intrepidkarthi.com's IP address . So it looks into DNS.
The browser then formed a connection to the server at that IP address on port 80. HTTP protocol uses port number 80
The browser sends a GET request to the server, asking for the file "http://www.google.com/karthikeyan.htm". The webserver then returns the requested page and your browser renders it to the screen.
The firewall will control connections to & from your computer. For the most part it will just be controlling who can connect to your computer and on what ports. For web browsing your firewall generally won't be doing a whole lot.
Your router essentially guides your request through the network, helping the packets get from computer to computer and potentially doing some NAT (Network Address Tranlator) to translate IP addresses along the way (so your internat LAN request can be transitioned onto the wider internet and back).
I don't know what I understood is correct or not. I need to understand it completely till the hardware level at the back.
browser has no DNS cache. your operating system's tcp stack has.
the server name in DNS may have many IP addresses. the browsers usually choose one at random.
DNS is a tree. to get www.google.com, you go to google.com name service and get IP of the computer www.
returned HTML page is a small part of the information. In turn, it points your browser to establish many connections to other servers, to bring scripts, pictures, etc.
otherwise okay.