The ApplicationPoolIdentity
is assigned membership of the Users
group as well as the IIS_IUSRS
group. On first glance this may look somewhat worrying, however the Users
group has somewhat limited NTFS rights.
For example, if you try and create a folder in the C:\Windows
folder then you'll find that you can't. The ApplicationPoolIdentity
still needs to be able to read files from the windows system folders (otherwise how else would the worker process be able to dynamically load essential DLL's).
With regard to your observations about being able to write to your c:\dump
folder. If you take a look at the permissions in the Advanced Security Settings, you'll see the following:
See that Special permission being inherited from c:\
:
That's the reason your site's ApplicationPoolIdentity
can read and write to that folder. That right is being inherited from the c:\
drive.
In a shared environment where you possibly have several hundred sites, each with their own application pool and Application Pool Identity, you would store the site folders in a folder or volume that has had the Users
group removed and the permissions set such that only Administrators and the SYSTEM account have access (with inheritance).
You would then individually assign the requisite permissions each IIS AppPool\[name]
requires on it's site root folder.
You should also ensure that any folders you create where you store potentially sensitive files or data have the Users
group removed. You should also make sure that any applications that you install don't store sensitive data in their c:\program files\[app name]
folders and that they use the user profile folders instead.
So yes, on first glance it looks like the ApplicationPoolIdentity
has more rights than it should, but it actually has no more rights than it's group membership dictates.
An ApplicationPoolIdentity
's group membership can be examined using the SysInternals Process Explorer tool. Find the worker process that is running with the Application Pool Identity you're interested in (you will have to add the User Name
column to the list of columns to display:
For example, I have a pool here named 900300
which has an Application Pool Identity of IIS APPPOOL\900300
. Right clicking on properties for the process and selecting the Security tab we see:
As we can see IIS APPPOOL\900300
is a member of the Users
group.
UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust store. If possible, it's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.
UPDATE 11/29/2014 -- This is still a problem, and Godaddy appears to not care nor will do anything about it. There is a blog post[here][1]
by Godaddy VP of Security Products from several months ago saying a fix was on it's way and provided a temporary work-around, but as-of today nothing has changed. It is important to note that Godaddy's G2 CA server has been around for a minimum of 5 years, and in that time Godaddy has not taken the proper steps to resolve this known issue. The work-around provided is just that, a work-around, not a solution. Users of 3rd party services have zero control over how the cert is installed on the server.
It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.
Here is their SSL team's contact info if you feel inclined to call:
GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com
UPDATE 9/17/2014 -- This is still a problem, and Godaddy appears to not care nor will do anything about it. Come November when Google deprecates all SHA-1 certs, this will become a major issue. I highly recommend anyone who can contact Godaddy and point them here.
~~~~
My initial post/question was regarding why my chain was not working. It became obvious I had a bad setup (which was quickly fixed with some advice from @Bruno and others - thanks). However, when my corrected chain still did not work with Java, it became apparent there was a much bigger problem lurking. It took a while, but the problem is actually with GoDaddy.
This actually is indeed a GoDaddy problem (I've had lengthy support emails with them).
They have 2 CA servers, one called Class 2 CA
and the other called G2 CA
. Their Class 2 CA
signs all SHA-1
certificates, while the G2 CA
signs all their SHA-2
certificates.
This is where the problem lies - GoDaddy has not added their newer G2 CA
server to the default Java truststore/keystore
- causing default Java installations to not trust it's authority, and hence, does not trust your chained certificate.
The work-around until GoDaddy adds the G2 CA
server to the default truststore/keystore is to simply rekey your cert using SHA-1
as-to get a cert signed by the Class 2 CA
server. Rekeying is free for GoDaddy customers until your cert expires (obviously).
Once you have a SHA-1
cert signed by the Class 2 CA
server, your trust chain should work as expected and no custom truststore/keystore imports and/or setup is required.
It does not make me happy that I must use a "weaker" cert in order to get it to work properly, and discussions with GoDaddy via email support thus far have indicated they have no current plans to add the G2 CA
server to the default truststore/keystore. I guess until they do add it, make sure you get a SHA-1
Class 2 CA
server signed cert if you plan to work with Java.
Best Answer
I had this exact same issue a few months ago when I was setting up a cert for a client.
There's a MachineKeys folder that the Administrator need rights -
give Administrator (or the Administrator group) Full Control over this directory. I don't think you have to restart IIS, but it never hurts .
I have no idea why Admin doesn't control this as default. Once this is changed, the Certificate Creation Wizard will successfully generate the certificate request.
I think there's even a Microsoft KB article about it somewhere.
EDIT: Here's the KB article : http://support.microsoft.com/kb/908572
-Jon