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.

This is a new cmdlet for Exchange Server 2010 SP1. The cmdlet has FileData parameter that accepts certificate raw data in DER encoded format (byte array). However you will encounter an issue in the case when you have a certificate encoded in Base64. This is not an issue for PFX files because Pkcs12 don't support Base64 encoding, but other certificate file types (CER/Pkcs7/SST) support this. And if you have certificate encoded in Base64 you will get error. Let's see why. Here is an example of Base64-encoded certificate:

Recently someone asked a question about how to remove unused certificate stores. GUI and .NET don't provide this functionality (within X509Store class) and you will have to use other things. New Quest AD PKI cmdlets adds some features for certificate stores:

• Review certificate store

Get-QADLocalCertificateStore -StoreLocation CurrentUser
Get-QADLocalCertificateStore -StoreLocation LocalMachine

these commands can be used to explore available certificate containers in CurrentUser and LocalMachine store location. In addition these commands can be used to retrieve certificates from local stores as shown:

Many systems administrators asks about dealing with CRLs (Certificate Revocation List) in Windows PowerShell. Some time ago the answer was — PowerShell can't natively work with CRLs because there are no any managed API (both in .NET and CryptoAPI COM), so you was unable to wrap these classes/interfaces to PowerShell. Hopefully there are 3rd party library in Mono (open-source .NET reference). However this just adds API and nothing else. For more complete PowerShell solution we need to get a cmdlet form. Fortunately Quest Software was first who developed cmdlets for PKI management. You can download them from the link: http://www.quest.com/powershell/activeroles-server.aspx.

Currently there are cmdlets for client certificate/CRL management only. You may ask: we have great certutil.exe, so why we need to search for native PowerShell solution? Yeah, certutil.exe is great cmd utility, but when we want to automate certain tasks, we will have to parse quite complex certutil output. By using PowerShell we can dramatically simplify this job by working with well-known objects.

In one of my recent posts I have posted a bug in AppLocker path rule processing (see: The case of another AppLocker bug). I have opened Technical Support case and AppLocker product group was able to repro the issue and provide a temporary workaround. Here is official Microsoft's response:

We've investigated the issue and it appears to be a problem in the implementation of case-insensitive path comparison for characters outside the ASCII range. Fortunately it seems there is a workaround for the time being. If, in Local Security Policy, one specifies paths in all-uppercase characters, including uppercasing any non-ASCII characters as appropriate, then the rule will match properly. Concretely, for your example 'Mapīte', putting that string with lowercase ī in a rule's path in Local Security Policy will not work; however putting the string 'MAPĪTE' with uppercase Ī does seem to work.

Therefore if path in the path rule contains non-english characters (outside the ASCII 1-127), write these characters in upper case. Unfortunately you cannot use PowerShell for that conversion (by using String.ToUpper() method), because console host doesn't display diacritic characters, so you will have to do this task manually.