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.

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:

Update 09.03.2011: removed SAN attribute flag as it is not necessary.

Many of windows administrators requires to setup SSL on their web servers and mostly they wish to use certificates with the Subject Alternative Name extension that allows to map a single certificate to a multiple web sites. For example, you want to use a single certificate for https://www.domaon.com and https://owa.domain.com. In that case you need to have multiple subjects in the certificate. However X.509 certificates don't support multiple subject fields. To resolve this issue, Subject Alternate Name extension is used. You can add multiple (even wildcard) subjects to a certificate.

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.