Sometimes I don't understand Microsoft. They a lot of useful things, but thing implementation is quite poor. For example in Windows Server 2008 R2 we have an option to install certificate enrollment service (hereinafter CES) that will allow to securely enroll certificates outside of domain network perimeter. Also CES allows to enroll certificates from non-domain clients. Here is excellent whitepaper about the subject: Certificate Enrollment Web Services in Windows Server 2008 R2. You can setup only one CES instance via Server Manager snap-in. What if we have multiple CA servers and we need to configure CES to work with them? For example, one CA is configured to issue user certificates only and another CA is configured to issue computer certificates only. Also we need to issue these certificates to external clients. In that case we need to setup at least two Windows Server 2008 R2 servers, assign them public IP address and install required CES instance on each CES server. This is pretty ugly. Hopefully there is a trick to install additional CES instances on the same server via CryptoAPI COM interface: CERTOCM.CertificateEnrollmentServerSetup. Currently this interface is not documented on MSDN, therefore I cannot provide interface explanation links. However I wrote PowerShell script that will add additional CES instance and remove specified or all CES instances from local computer. I have commented some code parts for understanding, but the code generally is self-explanatory.

Looking to my previous posts I've noticed that I haven't described the methods how certificate extensions are encoded. Cryptography in overall relies on encoded data. For example, digital certificate is a byte array that contains encoded certificate fields. All certificate content is encoded using Abstract Syntax Notation 1 Distinguished Encoding Rules (simply ASN.1 DER). If certificate is stored in Base64 string format, system just converts Base64 content to a byte array. There are several encoding rules for each data type. For example, object identifiers (OIDs) has their own encoding rules, DateTime — their own encoding rules and so on.

In this post I would like to demonstrate encoding rules for Object Identifier data type. Object Identifiers are used to encode Enhanced Key Usage, Application Policies, Certificate Policies and other certificate extensions. The following format is used:

• Tag value
• String length
• Data type
• Actual data string length
• Encoded data string

In my previous posts: New-OpsMgrRequest and Install-OpsMgrCertificate I posted two nice scripts. However there is a little bug that operating system version is not recognized correctly. Also these scripts have limited Windows versions support — only Windows Vista and higher. Now I have updated both scripts by fixing several bugs and added Windows XP/Windows Server 2003 (including R2) support. The following scripts demonstrates as well as CertEnroll and XEnroll CryptoAPI interfaces and how you can deal with them in Windows PowerShell. Here is an updated code:

This article will explain and demonstrate the techniques that will add custom extensions to certificate requests.

A little abstract. As you know, when Hewlett-Packard iLO generate certificate request for SSL it include server *short* name to the Subject field. There is no way to change subject name format. While output request file is signed you cannot edit this request, because signature will become broken and CA (Certification Authority) will reject this request. Subject name short format is not quite useful, because many administrators prefer FQDN (Fully Qualified Domain Name), for example: iLO1.domain.com. I agree with this point that FQDN are more useful and can be used in various network configurations and in multi-domain/multi-forest environments.

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.