Disclaimer: this article contains information about modifying the IIS configuration files. Before you modify the IIS configuration file, make sure to back it up and make sure that you understand how to restore the file if a problem occurs.

This article contains information about unsupported operations. Before you modify any settings described below, make sure to backup your system and make sure that you understand how to restore the system if a problem occurs

A little abstract. The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. Why it has been developed? Prior to OCSP, clients checks certificate status (valid/revoked) using certificate revocation lists (CRLs). Client software downloads certificate issuer CRL file and examines its Revocation List property. If particular certificate serial number is present in CRL, certificate is considered as revoked or invalid and is rejected for usage. While CRLs may contain many revoked certificates, CRL size is grown. Typically empty CRL with default settings is about 600 bytes (the CRL size generally depends on field and extension textual information length and signing certificate key length). Each revoked certificate entry is about 80 bytes. If 10 certificates are revoked, CRL size will be: 600 + 80 * 10 = 1400 bytes. For 100 revoked certificates the size will be about 9 kilobytes. For 100 000 revoked certificates, the size will be approximately 8 megabytes.

Continuing my previous post I want to discuss about certificate installation. As you know, certificate erollment generally consist of several steps:

• Certificate Request generation;
• Certificate Request submission to Certification Authority;
• Certificate Request response (certificate signed by CA) installation;

In previous post I have demonstrated how certificate request can be created using native PowerShell capabilities. While CA server cannot be contacted directly from managed client, you will have to manually transfer and submit certificate to Certification Authority.

When you create Certificate Request, it is placed in Certificate Enrollment Requests container (in Certificates snap-in). This request waits for signed certificate public part. When certificate public part is signed by external authority, signed certificate must be installed to local store. Installation process consist of two steps:

I would like to demonstrate a quite pretty script that simplifies certificate request generation for OpsMgr managed clients. Recently we had have to use various complex (for administrators that are not familiar with digital certificates) methods, such:

• CertReq.exe utility in conjunction with Policy.inf file (as decribed here: Certificate Enrollment for System Center Operations Manager Agent);
• Request generation using MMC console Certificates snap-in.

Both methods require some additional steps to generate request. For example, if you use CertReq.exe utility you need to write enough complex certificate enrollment configuration file. If you use Certificates snap-in you will need to manually specify all necesary data (such subject, private key settings, certificate extensions, etc). This PowerShell script will do all stuff, so you will have to copy and paste script to PowerShell console and run it.

In this article I want to talk about Applocker rule priority and rule sorting. As you know, Applocker has one security level or default action — Disallowed all except explicity allowed. This is common misunderstanding point for some administrators.

When you create Path or Publisher rule, it cannot uniquely identify particular file. For example, when you create Path rule such C:\BusinessPrograms\*, it will allow to run anything within C:\BusinessPrograms folder and all subfolders. Or, for example, you create Publisher rule that will allow to run any file that is signed with ‘Microsoft Corporation’ digital certificate, regardless of actual file location. It is common scenario when you want continue to block some files that are located in this folder or subfolders (in Path rule case) or files that are signed with particular certificate subject (in our case this is ‘Microsoft Corporation’ certificate), however.

This post is based on existing OpsMgr product group (PG) post: Troubleshooting Ops Mgr Certificate issues with Powershell. For me existing script return overloaded information to user and is not quite easy for understanding. Also there is missing some points:

• certificates might be issued from 3rd party Certification Authorities (CAs) and not always has SerialNumber fixed length. Therefore in some cases it incorrectly converts certificate serial number to it actual value;
• by default X509Chain.Build() method (for Operating Systems prior Windows 7/Server 2008 R2) by default attempts to build a chain up to any root certificate that is stored in Trusted Root CAs container in CurrentUser store. This means that while original script return "Ok" status, OpsMgr Agent may not work with this certificate, because root certificate don't exist in Trusted Root CAs in LocalMachine store;

Another point is that what we want to get from script? I thing that we just want to know: