Recently I decided to perform little changes on my OCSP Responder. I'm using offline CA (root) and have configured to include OCSP URL to all issued certificates. But some time I haven't OCSP configuration for  my root CA. And today I have completed all changes and now Root CA issues OCSP signing certs for appropriate OCSP configuration.

You can find required info about the subject on TechNet: Online Responder Installation, Configuration, and Troubleshooting Guide or in AskDS blog: Implementing an OCSP responder: Part IV - Configuring OCSP for use with Standalone CAs. However both links contains incorrect settings, therefore I'll post correct steps.

Update 23.08.2010: added workaround to resolve the issue.

Today one customer claimed that AppLocker rules are not worked for his environment. He just created simple path rule and it didn't work. I have investigated this issue and I'm able to confirm that AppLocker don't apply path rules to a folder that contains non-english letters. Here is an example how to reproduce this issue. Assuming you have default Windows 7 Ultimate/Enterprise installation with C:\Windows as a system root folder.

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.

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 article describes process of obtaqining and installing a digital certificate for OpsMgr agent that is not a member of your AD forest or a trusted forest. This article assumes that your managed computer is running one of the following operating systems:

• Windows 2000
• Windows XP
• Windows Vista
• Windows 7
• Windows 8/8.1
• Windows 10
• Windows 2000 Server
• Windows Server 2003 (including R2)
• Windows Server 2008 (including R2 and Server Core)
• Windows Server 2012 (including R2 and Server Core)

 Target audience is OpsMgr administrators that have limited or no understanding of what certificates are and how PKI works. Described below is not the only way to achieve the same or similar goal but it implements many of PKI Best Practices.

In this article

• Prerequisites
  All steps described in this section must be completed in both scenarios
  • Existing Certification Authority (CA)
  • Export Certificates of CA Hierarchy
  • Distribute Certificates of CA Hierarchy
• Scenario 1 Certification Authority server is configured as Standalone CA and running one of the following operating systems: Windows Server 2003/2003 R2/2008/2008 R2 Standard, Enterprise or Datacenter edition.
  • Prepare certificate request template
  • Create a request file to use with an Standalone Certification Authority
  • Submit a request file to Standalone Cetrtification Authority
  • Install issued certificate to managed computer
  • Import certificates using MOMCertImport
• Scenario 2
  Certification Authority server is configured as Enterprise CA and running one of the following operating systems: Windows Server 2003/2003 R2/2008/2008 R2.
  • Prepare certificate template
  • Add new template to Issuing Enterprise CA
  • Prepare certificate request template
  • Create a request file to use with an Enterprise CA
  • Submit a request file to Enterprise Cetrtification Authority
  • Install issued certificate to managed computer
  • Import certificates using MOMCertImport