Update 04.08.2018: clarified behavior on timestamping certificate revocation

Hello again! Today I would like to discuss about digital signatures and signature usage questions.

A very short introduction to digital signatures

As you know the signature guarantees that the electronic document wasn't changed after signing process. This is a useful feature for sensitive data that may be changed during transfer over network. For example, Internet. There is one well-known attack named Man In The Middle (MITM). In MITM, malicious user intercepts document change some data and transfer to the original recipient. If the document is originally signed (by sender) the recipient will attempt to validate document signature and will see that the document was changed during data transmission. This would invalidate the document.

In real world digital signatures are used very often and use asymmetric encryption/decryption processes.

Update 22.10.2017: updated use-case recommendations based on best practices.

Update 27.06.2018: added commands

In this article I will discuss about Root CA certificate renewal with new and existing key pair. At first we discuss about CA certificate renewal with existing key pair.

Renewal with existing key pair

When you renew CA certificate with existing key pair, nothing important in certificate is changed. The certificate will contain the same public and private key. As the result all previously issued certificates will chain up to new CA cert without any changes. You just replace old CRT file in AIA download locations. In addition, new CA cert ValidFrom (NotBefore) field will contain the value when existing CA key pair was generated. For example, old CA cert has ValidFrom (NotBefore) = 08.10.2000 and ValidTo (NotAfter) 08.10.2010. When you renew CA cert with existing key pair new certificate will have following values: ValidFrom (NotBefore) 08.10.2000 and ValidTo (NotAfter) 08.10.2020. In other words this renewal just increases current CA certificate validity period. In addition new CA cert introduces one new extension: Preious CA certificate hash that will contains preious certificate Thumbprint extension value. And changes another extension: CA Version. Let's take a look to a CA Version extension.

Many, many and many administrators request new certificates and mark private keys as exportable. Is this a good solution? Definitely no. Are there a reasons to do that? In most cases — no. Do I need to explain the subject? Definitely yes.

In many MS guides that are suited with custom certificate enrollment you may find certificate enrollment configuration INF file like this:

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.

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.