Category: Windows Server 2008 R2

Bob had a great question when it came to published CRL’s vs Online responders.

“Why is one preferred, and when is one used over the other?”

To get to the bottom of this let’s see how the validation process works. SEE Certificate Revocation and Status Checking

Certificate Status Checking

When an application requests the certificate chaining engine to evaluate a certificate, the validation is performed on all certificates in that certificate’s chain. This includes every certificate from the leaf certificate presented to the application to the root certificate.

When the first certificate in the chain is validated, the following process takes place.

  1. The chaining engine will attempt to find the certificate of the CA that issued the certificate being examined. The chaining engine will inspect the local system certificate stores to find the parent CA certificate. The local system stores include the CA store, the Root store, and the Enterprise Trust store. If the parent CA certificate is not found in the local system certificate stores, the parent CA certificate is downloaded from one of the URLs available in the inspected certificates AIA extensions. The paths are built without signature validation at this time because the parent CA certificate is required to verify the signature on a certificate issued by the parent CA.

  2. For all chains that end in a trusted root, all certificates in the chain are validated. This involves the following steps.

    • Verify that each certificate’s signature is valid.

    • Verify that the current date and time fall within each certificate’s validity period.

    • Verify that each certificate is not corrupt or malformed.

  3. Each certificate in the certificate chain is checked for revocation status. The local cache is checked to see if a time valid version of the issuing CA’s base CRL is available in the cache. If the base CRL is not available in the local cache, or the version in the local cache has expired, the base CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate. If available, it is confirmed that the certificate’s serial number is not included in the CA’s base CRL.

    When a root certificate—a certificate that contains the same DN for both the Subject and Issuer attributes—is encountered, a revocation check may or may not occur. If the certificate chaining engine behavior will depend on whether the application enables the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag, which is the default, the root CA’s certificate is not checked for revocation. If the flag is not enabled, the root CA certificate is checked for revocation if the root CA certificate includes the CDP extension. If the CDP extension is not included, no revocation check is performed.

    Note  Windows XP RTM and Windows XP SP1 will perform revocation checking as the chain is built, rather than only performing revocation checking on chains that end at a trusted root CA.

  4. If the base CRL contains the Freshest CRL extension, the local cache is checked to see if a time valid version of the issuing CA’s delta CRL is available in the cache. If available, it is confirmed that the certificate’s serial number is not included in the CA’s delta CRL. If the delta CRL is not available in the local cache, or the version in the local cache has expired, the delta CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate.

    Warning  If delta CRLs are enabled at a CA, both the base CRL and delta CRL must be inspected to determine the certificate’s revocation status. If one of the two, or both, are unavailable, the chaining engine will report that revocation status cannot be determined, and an application may reject the certificate.

Once the validation check is completed, the certificate chaining engine returns the results of the validation check to the calling application. The results will indicate if all certificates in the chain are valid, if the chain terminates at a non-trusted root CA, if any certificates in the chain are not valid, or if the revocation status for any of the certificates in the chain cannot be determined.

Note  If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.


Ok, now that we’ve got the validation part down. Let’s take a peek at Online Responders. What do they do differently than the CA and published CRL’s?

An Online Responder is a trusted server that receives and responds to individual client requests for information about the status of a certificate.

The use of Online Responders is one of two common methods for conveying information about the validity of certificates. Unlike certificate revocation lists (CRLs), which are distributed periodically and contain information about all certificates that have been revoked or suspended, an Online Responder receives and responds only to individual requests from clients for information about the status of a certificate. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be.

In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. For example:

  • Clients who connect to the network remotely and either do not need nor have the high-speed connections required to download large CRLs.
  • A network needs to handle large peaks in revocation checking activity, such as when large numbers of users log on or send signed e-mail simultaneously.
  • An organization needs an efficient means to distribute revocation data for certificates issued from a non-Microsoft certification authority (CA).
  • An organization wants to provide only the revocation checking data needed to verify individual certificate status requests, rather than make available information about all revoked or suspended certificates.

Now the application has to be configured to use an Online responder. it’s not going to just figure it out on it’s own.

Bob from this week’s 6426 class posed the following question. I have some users who access multiple SQL databases, can ILM or FIM automate password changes across them?

I grabbed the information from the Understanding Forefront Identity Manager 2010 white paper which is accessible via the link. Here are a few choice excerpts

  • Heterogeneous identity synchronization & consistency. FIM 2010 delivers integration with a broad range of network operating systems, e-mail, database, directory, application, and flat-file access. FIM 2010 supports connectors for Active Directory, Novell, Sun, IBM, Lotus Notes, Microsoft Exchange Server, Oracle databases, Microsoft SQL Server™ databases, SAP and others. This provides organizations with the power to connect and synchronize the plethora of disparate sources of identity information in their company—in most cases without the need to install software of any kind on the target systems. Since in some cases it might be necessary to connect to custom or legacy applications unique to a specific organization, FIM 2010 extensible agent capabilities enables companies to integrate and manage identities for these applications through developing custom agents in the Microsoft Visual Studio® development environments.


  • Simplified sign-on by synchronizing passwords across systems. Importantly, FIM 2010 provides a simplified sign-on experience through its identity synchronization capabilities, delivering the ability to synchronize passwords across heterogeneous systems.


     Sometimes you trust people just a bit too much. I had heard from another instructor that if you move a single WS2008 R2 server into your infrastructure you need to upgrade your cal’s since it’s a different SKU to MSFT. Well in short form, the information I received was incorrect.

     The worst part is I passed this bad info to you, the students. I apologize for any confusion or extra work this may have caused  you guys. I’d like to point to MSFT’s own site to give you the “from the horses mouth” answers…


Windows Server 2008 R2 Licensing Overview

Windows Server 2008 R2 Licensing FAQ

Windows Server Client Access Licensing