Contents tagged with IIS
I ran into an interesting issue with a site that I’m involved with. This week we started to receive reports of a warning in Chrome that says “Identity not verified”. This is for a site that has been running happily for quite some time. I’m writing this in November 2014.
At first the warning only happened for some users, and only in Chrome, making it more difficult to track down. Furthermore, the warning message in Chrome didn’t give many clues as to the real issue.
I theorized that it had something to do with a recent update from Chrome, but at first I wasn’t able to prove that. Here’s what the message looked like:
You can tell that something is wrong, but you can’t really tell what it is. After some research and eventually becoming suspect that it was Chrome 39 that introduce the issue, we were able to find out the authoritative answer for this.
A blog post from the Chrome team in September provides the story:
That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
Notice that the certificate expires September 2017 and that it is signed and hashed with SHA-1.
Well, it’s November, we’ve just received the Chrome 39 update, and we have a SHA-1 certificate that is valid past January 1, 2017. That’s us!
SHA-1 (secure hash algorithm) has been used for years to sign and hash various objects, including SSL certificates. In 2005 it was determined to be insecure.
As a result, Microsoft and Mozilla have both announced plans to stop supporting SHA-1 certificates in 2017. Google has announced that it will do the same in a phased way leading up to 2017. And, that’s exactly what happened here.
Chrome has started by showing warnings for SHA-1 certificates which have an expiration date that is past January 1st 2017. So, those with a SHA-1 certificate, who purchased it for a few years in advance, should see this warning in Chrome now.
I do appreciate Chrome being proactive in pushing for a more secure internet, but I’m not a fan of them dinging those with longer running certificates well in advance of the 2017 date. I’m currently in the processing of asking our certificate authority to replace our certificate, and I assume that they will do so, but those with longer running certificates also have the most invested into them with the most to lose. They could have waited at least another year before turning on this warning. In any case, it is good to update to SHA-2 and it’s a good end result.
This month is the beginning of when this should start to occur, but you should see more of these over the next couple years. Longer running certificates will be hit first, and then as we get closer, other certificates will receive the warnings. IE, Firefox, Safari and other browsers may start to issue warnings leading up to 2017.
So, if you have been impacted by this, and you’re a site owner, you should contact your certificate authority and ask for them to reissue your certificate using SHA-2 instead.
If you are a web user and you see this warning, you can contact the site owner to make sure that they are aware of the warning. The site is no less secure today than it was last month, but Google is starting to bring awareness to the less secure SHA-1 signed certificates.
I had a question asked me recently regarding Windows auth and NTFS permissions. Here’s the question:
IIS URL Rewrite has five different types of actions. They are: Rewrite, Redirect, Custom Response, Abort Request, and None. And if you have ARR (Application Request Routing) installed, then at the server level you’ll also see Route to Server Farm. The two most common actions are the Rewrite and the Redirect.
There are times when you need to reverse proxy through a server. The most common example is when you have an internal web server that isn’t exposed to the internet, and you have a public web server accessible to the internet. If you want to serve up traffic from the internal web server, you can do this through the public web server by creating a tunnel (aka reverse proxy).
A fairly common request for URL Rewrite is to prepend a www to all 2nd level domains, regardless of the domain name. Consider the following domain names:
Microsoft IIS Server has what appears to be an odd default for the application pool recycle time. It defaults to 1740 minutes, which is exactly 29 hours. I’ve always been a bit curious where that default came from. If you’re like me, you may have wondered too.
Application Request Routing (ARR) is a great solution for load balancing and other proxying needs. I’m a big fan and have written often about it.
A friend of mine asked me recently how to handle a situation with a dot (.) in the path for an MVC project. The path looked something like this:
IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.
IIS URL Rewrite supports server variables for pretty much every part of the URL and http header. However, there is one commonly used server variable that isn’t readily available. That’s the protocol—HTTP or HTTPS.