Wednesday, January 28, 2015

1. Create a new scheduled task
2. On the actions tab, click new
3. Change the action to send an e-mail
4. Enter the to, from, subject, text and smtp server information For subject and text enter something along the lines of "A schedule task failed on server so and so"
5. Click OK

Now anytime a schedule task completes with a result code of 1, an email will go out letting you know. 1 in our case indicates an error. What ever task you have may return other codes to indicate errors. You could say were data > 0.

Monday, January 12, 2015

If you view a cert,
windows goes out and downloads the root and puts it in the third-party trusted
root certificate authorities store.

If you select a cert
in IIS binding, windows goes out and downloads the root and puts it in the
third-party trusted root certificate authorities store. It also downloads the
intermediate certificates and places them in the intermediate certificate
authorities store. (Assuming the cert has a proper AIA configured and
accessible.) Thus, IIS will work and serve the intermediate certs even if you
didn't explicitly install them into the intermediate cert store. I'm sure this
was done to make things simple on admins.

I disabled the
gateway and dns so that the windows box could not get out to the internet.
Windows did not download the chain when viewing the cert by double clicking and
IIS only served the one certificate. IIS
did not download the intermediate certs. (It couldn't.)

Of note, it appears
as though the windows crypto APIs cache previous root certs. I viewed a cert
while the server had internet access. Windows downloaded the root cert and put
it in the third-party trusted root certificate authorities store. I removed the
root cert from the third party store, disabled internet connectivity and viewed
the same leaf cert again. Without an internet it placed the root cert in the
third-party trusted root certificate authorities store again.

While disconnected,
I manually installed intermediate certs in intermediate store. IIS did not
server them until I touched the bindings of the site in IIS. You need to edit
the binding in IIS and just hit ok for the new chain to be served. Just adding
intermediate certs into the store will not do it.

It looks like IIS
creates the cert chain when the binding is configured and then stores it
somewhere for future access. Likely so that path resolution doesn't have to
occur over and over. IIS just has to do it once on binding configuration.
Restarting IIS/the website had no effect. The binding needed to be
modified/re-applied. Restarting the server seems to have updated the
certificates served by IIS. IIS's cert chain storage must not be persistent.

I tried placing the
intermediate cert in the personal store and IIS did not serve it. I tried
placing the intermediate cert in the root store and IIS did server it. So
technically intermediate certs could go in the root or intermediate store. I
would not put them in the root though as that has other implications.

The big take aways here are:

Windows/IIS will try to make things easy for you as an
admin and download/configure cert chains for you

IIS
will only update the certificates it send to clients when you update the
binding or restart the server

In the future I'd
like to test out certs with multiple paths and discover how IIS/path resolution
determines path priority. Will one store take precedence? Does it base it
solely on whatever window's path selection algorithm is? How will auto
downloading play in? I personally think the way IIS serves certificates could
use an overhaul. It would be nice to be able to server multiple certificates
from IIS. For example, depending on client handshake capabilities, serve either
RSA or ECDSA hashed cert for authentication to root CA. Then we could easily
transition to ECC certs.