I am having a strange problem. When you view one of our websites under IE8 XP it pulls the wrong security certificate from the server.
When I view the same website in IE8 on Windows 7 it pulls the correct security certificate.
Same exact url: https://aframe.insurancehelper.com/
I am not sure how to debug this. Does XP identify itself differently than Win7 and every other OS?
Let me know if I can supply any additional information that would be helpful.
The sever is using Apache 2.2.
It's likely caused by using multiple SSLs on one IP via Apache. From what I've seen the only way to overcome this is via a unique IP per SSL. More detail can be found below.
This is only an issue for IE in XP too. If you're willing to ignore that minor segment of users you could continue as normal, place a warning on the site that IE8 and below users, that they should switch to a more up to date and secure browser.
http://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm
Related
I've download Visual Studio 2022 and tested the default Blazor Server template (Home/Counter/FetchData). In Visual Studio, IIS Express I can open as many tabs / instances of the application as I want.
When I host the default Blazor Server template in local IIS (Windows 10 Home 21H2, IIS 10) I can only open three instance of the application. The fourth will hang until the first is closed. I see someone has ran into nearly the exact same issue but there is no solution provided.
Anyone know whats going on? I don't understand why IIS Express can handle multiple instnaces but IIS 10 can not. Even Conveyor by Keyoti can support many many tabs compared to IIS 10.
Note: I notice SignalR has limitations on Windows / IIS of 10 concurrent connections, but I'm not even getting two.
Updates
Out of curiosity I tested it on Windows Server 2016 Standard and I can open hundreds of tabs.
I re-installed IIS on Windows 10 to make sure something wasn't wacky.
I've ensured WebSocket Protocol is enabled.
Windows 10 Home supports 3 concurrent connections at the same time, according to Microsoft.
Normal HTTP requests to IIS get process and response returned. So even if you manage to achieve 4 or more at the same time, IIS will work through the request queue and you may not have noticed that your request was slightly delayed unless your individual requests take a while to process.
However with SignalR, a persistent connection is maintained to the server. So if you open one connection per browser tab, and you have 4 tabs open, that 4th tab is going to hang indefinitely until one of the other page has its connection ended (by closing the tab, manually disconnecting via code, or refreshing the page).
I can't reproduce the issue, and I have tried to search some way to solve it.I will summarize a few ways below that you can try.
Try to install Websocket Protocol in your Win10. You can find it in Windows features.
Workaround: install IIS Express in Web Platform Installer.
Workaround: Try to deploy it in windows server, and check whether have same issue. I found some posts also mentioned it may related with OS version.
The solution was incredibly simple (maybe too simple?). Don't use IIS at all.
In Program.cs just before building the app I override Kestrel ports to listen on any ip (for now).
(Optional) I provide a custom SSL certificate in the UseHttps constructor so that it can be emailed and installed on iOS and Android devices.
(Required) Then I publish the applications to a folder and just run the .exe on the hosting machines.
Program.cs
builder.WebHost.ConfigureKestrel(opt =>
{
opt.ListenAnyIP(8000);
opt.ListenAnyIP(8001, listOpt =>
{
listOpt.UseHttps(#"Path to.pfx file", "password for pfx file");
});
});
Now Windows 10 Home can support as many connections as the hardware can handle at https://192.168.0.XXX:8001. Is this how Blazor Server is expected to be deployed within a local network? I don't understand how this overcomes the connection limit pointed out in masons answer. Please let me know in the comments if I'm missing something.
Can someone please explain to me why I get two different results when running the same software? I've got a .NET Core application running with IIS.
When I access it as http://localhost/foo it all works as expected. I authenticate properly.
When I access it as http://machine.domain.com/foo I get a credentials dialog appear, asking me to enter a username/password and no matter what I type in I can't get it to authenticate.
It's the same piece of software running on the same box. The only difference is the URL I'm using to access it. My guess is that it must be something on the network causing this problem.
Btw, this machine is just being accessed across a corporate lan. Not the internet.
We are encountering Kerberos and/or NTLM authentication failures in custom application packages orinally designed for Windows 7 using the WISE packaging Installer. On Windows 7 they work fine but they now fail on Windows 10. They fail both during installations on Windows 10 using the Microsoft SCCM tool, and they fail specifically when using Kerberos authentication to an SMB Share on the network durign the installation process. We can see inside the network trace that the client application fails over to NTLM from Kerberos durign the authentcation transaction. We are unsure why. We have a large scale Active Directory environment. Because the WISE package is comiled we cannot look into it. On successful Windows 7 machines, it appears the computer requires access to the Share while the package is being executed and the loggged-in user must have read and execute access on the SMB Share. We are able to access the same SMB Share using the Windows 7 system account but not when using the Windows 10 system account. Very odd! Is this a code issue inside the package? This may be important: The SMB share is using an DNS alias, not sure if this makes any difference. The real name of the host is different. When using the real name of the host instead of the alias the access issue appears to be resolved.
The network share wouldn't happen to be hosted by a non-Windows server by any chance, would it? If so, see if this article applies:
SMB file server share access is unsuccessful through DNS CNAME alias
Basically there was a change in the security model of Windows 10. Windows 10 by default won't request a Kerberos ticket for a DNS alias, but Windows 7 will. The SMB server is basically saying since you're not using my actual name (as shown by the service ticket), I won't allow the connection. Create a new SPN using the name that the successful Windows 7 machines are connecting with, but in SPN form. For example, if a Windows 7 is using something like this:
\servername.domain.com\sharename
..then find that name of the AD computer object representing the host and add a secondary SPN to that AD object like so:
HOST/servername.domain.com
Having an issue with my SSL certificate. Often it seems to work fine, but sometimes the user's browser throws up a warning that it is not trusted.
I know very little about SSL certificates, but here is some information that may or may not be relevant:
URL: demo.EnterpriseJazz.com
It is a wild card certificate because
the application uses subdomains (one subdomain per registered organization Example: BobsLawnCare.EnterpriseJazz.com)
The certificate was cheap for a wild card certificate, I paid around $50 for it if I remember correctly. I believe I got it from a cheap re-seller.
The server is located in my house on a Verizon FIOS business internet connection. It is not in a data center.
Seems to work fine with:
Safari on my new Macbook Pro
Chrome on my new Macbook Pro
Firefox on my windows machine
Microsoft Edge on my windows machine
Internet Explorer on my windows machine
Opera on my windows machine
Firefox on my Linux machine (CentOS)
Not trusted with:
Chrome on my iPhone 6s
Safari on my iPhone 6s (screen shots below)
Have a look at the SSLLabs report for this site. Apart from a shockingly insecure setup you will notice:
This server's certificate chain is incomplete.
This means that the client has not enough information to build the trust path to the root certificate and thus can not accept the certificate as trusted.
However a desktop browser will attempt to work around such setup problems by trying to fill in the missing chain certificates, i.e. downloading these from the web or using cached certificates from earlier connections to other clients. But apart from the desktop browsers most other clients will not do it and thus fail.
I had the exact same issue.
After futzing with every nook and cranny of my SSL and http setups, I finally realized "How silly I was to not check the URL first!"
My browser had been connecting to the regular non-trusted site (http://example.com) and I had blindly assumed that the broken lock icon meant something was wrong with my cert installation. Duh!
Modern browsers hiding the actual protocol letters behind a pretty icon or user-friendly message that conflates two issues into one - that didn't help.
My suggestion would be to first make sure you're hitting the https version of your site. If not, your first step to the solution is to create an automatic redirect of all http to https.
I hope getting to this post first helps at least 1% of those who had this problem. I'm in that 1%
I need to know of a solution to run a local test server through a virtual guest. I am able to use Virtual PC as well as most the other solutions. My current workaround is to deploy to Tomcat on Windows 7 and test the main current browsers there. I am also able to mount share my Tomcat instance to Ubuntu so am able to run the same app without redeploying.
Currently I just invested on a Windows upgrade to be able to try out Microsofts ie8 and down VHDs but the best I am able to do with this is deploy to production server and then run the ie6, ie7 and ie8 browsers which is very time consuming.
Any suggestions or pointers for me? Ultimately a working solution to run these VHds or browsers in VirtualBox would be ideal for me, as I am familiar with it.
Related to my question I have come across some useful tutorials that may help others who find this question:
Virtual PC solution for legacy IE browsers in Windows 7
VmWare solution
You can just use one Windows version (XP, Win7 will be fine) and install IETester:
http://www.my-debugbar.com/wiki/IETester/HomePage
My solution is as follows & will only work with upgraded Windows 7 (not home premium).
Uninstall IE9 update to bring back IE8, IE9 seems to support css3 well, so testing in FF7 should be good enough for IE9.
Then follow this tutorial and repeat the process for as many virtual browsers you want. Note
I did include IE8 but don't use it as it's slower to run a virtual PC than native IE8 just in case I wish to reinstall IE9.
I use quirks mode in IE8 to test for IE7 and IE6 can go to Davy Jones Locker :D
When using xpmode, you must copy the xp disk each time without any updates and start process from scratch.
I also use VirtualBox to test Linux browsers as it's faster than Virtual PC and I share test server (Tomcat) so am able to run same instance without redeploying.
Hope this helps...