Doing dev work on several sites on my local (Windows 10) PC when out of the blue this morning one site refuses to load in Microsoft Edge (Version 89.0.774.45 (Official build) (64-bit)). Other local sites are working fine.
I removed the redirect to SSL from web.config and issued a fresh self-signed certificate: NET::ERR_CERT_COMMON_NAME_INVALID - You can't visit local-prodject.mydomain.com right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
There is no HSTS in web.config. I removed the HTTPS redirect from web.config and it's still trying to force HTTPS. I've done the edge://net-internals/#hsts to delete for local-prodject.mydomain.com and localhost, no change.
I'd prefer to have self-signed working as it was yesterday, and on other sites on my local PC so when they get pushed to a production environment they're ready to go.
I should also note that Chrome and Firefox (Dev and regular) work fine.
Chrome, Opera and Edge have a safe word you can use to bypass this SSL issue for local development. Click anywhere within the browser window and type: thisisunsafe
Related
In VS Code, I'm trying to host an ASP.NET MVC app. I hit "F5" in order to run the debugger, and VS Code automatically opens my default browser, which is Brave. I get the following error on Chrome and Brave:
Vague Browser Error I know that hosting is taking place, because of this debugger info from VS Code.
The local site hosting works well on Firefox, but not on Chrome and Brave. When it worked on Firefox, it prompted me to continue to the site despite the danger. I told it "I understand the risks, please continue", and boom, it worked on Firefox.
I noticed that http://localhost:5000 redirects to https://localhost:5001, which made me think that there was a certificate error. I deleted the default SSL certificate for localhost in Brave, and then in VS Code, I restored it using:
dotnet dev-certs https dotnet dev-certs https --trust
In Chrome and Brave, I tried https://127.0.0.1:5001, and I was given the same prompt that I was given in Firefox, and then it worked after I told the browser "I understand the risks, please continue".
So though I found a workaround, it's very annoying to have to type in the loopback address rather than just let VS Code automatically open the browser. Can someone tell me how I can use localhost on Brave and Chrome?
I've recently completely switched to Firefox Developer Edition but I have a problem I've not been able to handle yet on FF.
I'm a web developer so it happened to me to have several subdomains which corresponds to a test env of a live website.
exemple : http://local.example.com is my local for https://www.example.com
As it's a common problem to have modules licensed for a domain and its subdomains, I have to process this way to have a correct development environment (with the same modules than the live env).
My problem is the following : if I go to https://www.example.com Firefox will remember that it accessed it in https and will force my local to https://local.example.com instead of http://local.example.com (and of course the https on my local is not configured)
Cleaning the browser cache does not help (it solved the problem on chrome).
Changing the ttl of the dns to 0 in Firefox config did not help.
Restarting the browser does not help neither.
In the developer panel settings, i checked "disable http cache when dev tools is open", it did not worked.
At the moment, I have to work on my local in a private window, which is not very practical.
Does anybody knows how I can flush this cache in Firefox ?
Even better : is there a way to disable this cache ? As I'm using the developer edition, that would be awesome to be able to disable it at least on this version.
Thanks!
Since the root domain seems to affect the other domains, it may seem you are using HSTS to make sure all requests are https.
You have 3 solutions to fix this:
Exclude subdomains on the main HTST header
The simplest solution for you and all other developers working on your site may be removing the includeSubDomains on the HTST header on your main domain. (But beware that this decreases security if you actually use other subdomains)
Use a private window
HTST domains are not shared by to a private window for privacy reasons
Get an free SSL certificate for local.example.com
Temporary redirect the global local.example.com domain to your computer, and use letsencrypt to get a certificate for your pc
We built a passbook server on ASP.NET and it worked perfect in Dev. environment (without SSL certificate).
Passes that were generated could be seen on iPhone (in dev. mode) and on Mac.
Then we bought an SSL from Thawte (just for the domain) and added the certificate to IIS.
Of course, domain name is associated with the same IP address.
So now, when a link to the pass is generated on our server, normal iPhone can't download it, saying "Can't download the file".
If I click the same link in Safari on Mac, it is opened, when click it from Chrome - file is downloaded.
We've tried whatever was possible - enabling SSL 2.0, then SSL 3.0 on the server. We also trued disabling all SSL and enabling all TLS instead - no luck.
The aspnet passbook server is configured using the following.
SSL 2 (disabled)
SSL 3 (disabled)
TLS 1.0 (enabled)
TLS 1.1 (enabled)
TLS 1.2 (enabled)
here is the ssl test result: http://clip2net.com/s/3lUpIiq
seems pretty configured correctly.
the pass can be viewed/run to any mac safari browsers, downloads pretty well on non-safari browsers, but not on iphones.
it just says, cannot download the file. we have been trying to search the internet for possible answers but no luck.
the thing is that the browsers including mac safari recognizes well the certificate installed on the aspnet passbook server. but it seems iphones does not recognize the certificate.
Please advise what else could be done?
Thanks!
Does the webServiceUrl have 'https'? If not, it needs to (see https://developer.apple.com/library/ios/documentation/UserExperience/Reference/PassKit_Bundle/Chapters/TopLevel.html#//apple_ref/doc/uid/TP40012026-CH2-SW3).
Other than that, you should be able to view the error from Passbook in the console window in XCode.
We found out what the error was, when we tried to debug it on a MAC with XCode. What it showed was the pass was missing some required fields, in our case, the icon/logo image, and second was the pass registration endpoint had some errors.
We tried to fix these issues including our pass registration endpoint. After that, all went well and has been working smoothly.
Depending on the pass type, there must be required fields that must be met, else, the pass won't install correctly on production mode.
Many thanks!
We have forced the LIVE site to use SSL (for authentication reasons) and now the site won't get past the Login page.
The Login page displays fine, but after entering Username/Password and hitting Login, the page reloads.
Looking at the Developer Tools in Chrome reveals a 404 error loading
https://myapplication.com/login.aspx/WebResource.axd
Research on internet suggests a web.config setting - but I can't find what setting to use.
The site works absolutely fine when not in SSL mode - and has been working for a while until forcing IIS to run site over SSL at all times.
Any ideas?
Check that you have bindings on 443 for all the URI's possible. For example, you have myapplication.com. You probably have a binding on 80 to that URI, but what about 443? What about www.myapplication.com on 80 and 443? IIS will only respond if told to. It will not infer URLs from the application that it should serve up. You have to specifically allow them on all ports.
In Brief:
My company is currently working on a small asp.net website to be used by a set of our customers. The site fails to load in only IE8 in our production environment, instead displaying a general page-not-found error (not a 404 from our server).
Details:
The website is deployed on two servers, QA and Prod. Both servers were cloned from the same image and should have identical settings. They have identical hardware and software. Both servers are outside of our company firewalls, accessible from the internet, as well as our company intranet. The website itself was deployed on both servers from the same build; the only difference is a single line in each site's web.config file pointing the site on Prod to the production database and the site on QA to a test database (whose data is cloned from Prod on a regular basis). I'll refer to our site on the QA server as site.qa.com and our site on the Prod server as site.prod.com.
When site.prod.com is accessed from the company intranet in any browser the site loads and behaves correctly (this includes accessing it in IE8). When site.prod.com is accessed from the internet (as our end users will be accessing it), site.prod.com loads and behaves correctly in Chrome, Firefox, Safari, and IE9. When we attempt to access it in IE8, IE8 returns a page-not-found error, as if the computer accessing site.prod.com is disconnected from the internet.
site.qa.com is accessible on both our intranet and the internet in every browser (including IE8).
I should also note that accessing site.prod.com from both the internet and our intranet uses the same URL and should pass through the same security checks; there's not a special intranet-only way of accessing either site.prod.com or site.qa.com.
More about the servers:
Both QA and Prod are running Windows Server 2008 R2 Standard, Service Pack 1. We are running the website through IIS 7.5, and IIS settings are identical between the two servers (exporting their config files and comparing shows them matching down to the line).
Closing:
At this point we are stumped about why our website fails to load in IE8. It's not an option for us to drop support for IE8, and cloning QA and using that clone as Prod is a temporary solution we're considering, but won't answer our core question, which is: why will IE8 completely fail to load the production site, and only the production site, only when accessed from the internet?
EDIT:
The website magically started working (it looks to be one of those errors). I'll post here anything we're able to uncover about this behavior and how it was fixed, in case others are experiencing similar problems.