Hello мир! Yesterdays I've published another version of my PowerShell PKI module — v1.0. Here are release notes:

Installation experience

I've spent much time on reviewing existing installation experience. My main goals were:

  • Provide a single package for different platforms — x86 and x64.
  • Support direct updates (without requiring to manually remove previous installation).
  • Provide custom installation scenarios — for current user or for all users.

As you may be noticed, previously I've used Advanced Installer (thanks to PowerShell MVP Shay Levy who advised me this product) to wrap my package in MSI. Advanced Installer has intuitive, well-designed (attractive) and rich UI and this product is (possible) the best for beginners like me. However, free license is not enough for custom installation scenarios (like 32/64-bit mixed packages, direct upgrades, patching and so on). In order to accomplish these goals, I've contacted Caphyon Advanced Installer team for some support here. Advanced Installer support was very quick and kind, so I'm ready to provide new installation experience.

Now you need only single package to install the module on either x86 or x64 platform and all future updates will automatically upgrade existing installation.

Besides these technical questions, I was thinking about installation paths. Generally speaking, Windows PowerShell team do not recommend to install custom modules to the default location: %windir%\System32\WindowsPowerShell\v1.0\Modules due to the fact that the folder may be replaced by certain updates or upgrades. I'm still looking for the best solution here. Therefore I've changed module installation default path from System32 folder to My Documents folder. By default it is installed to My Documents\WindowsPowerShell\Modules folder (for current user only). Optionally you can switch to System32 folder by checking corresponding check-box in installation UI.

Even though the default path is My Documents folder and do not require administrator permissions, I don't think that this is a good idea, when any user can install the module by using MSI/EXE. This means that local administrator permissions are required for all cases!

What is changed in the code?

  • CRL Distribution Points and Authority Information Access extension management

During module usage I've faced some bad things. For example, it was not possible to replace all CDP/AIA URLs. You was able to remove particular URLs, but not replace them all. To address this issue I've revisited and changed AuthorityInformationAccess and CRLDistributionPoint objects, so now you receive one object per CA. All URLs are placed in the URI property:

PS C:\> Get-CA int* | get-cdp

DisplayName                              URI
-----------                              ---
Sysadmins LV Internal Class 1 SubCA-1    {65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl, 65:\\sysadmins.lv\Sh...

You can expand the URI property by piping the object to 'Select -Expand URI' command and you'll get detailed information about each URI:

PS C:\> Get-CA int* | get-cdp | select -ExpandProperty uri


RegURI           : 65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
ConfigURI        : C:\Windows\system32\CertSrv\CertEnroll\.crl
Flags            : {1, 64}
CRLPublish       : True
DeltaCRLPublish  : True
AddToCertCDP     : False
AddToFreshestCRL : False
AddToCRLCDP      : False
IDP              : False
<...>

Now you can create oneliners that will replace all links like this:

Get-CA | Get-CDP | Remove-CDP –URI * | Add-CDP –URI "link1","link2","link3" | Set-CDP

Another good improvement is in Get-CertificationAuthority command. At first I've added short Get-CA alias, because even PowerShell has tab-completion, I had to press Tab button many times to get the right command. Now the things are easier. In addition, I've encountered an issue with annoying delays during CA information retrieval in the case when one or more CAs are offline. Even if I explicitly specify the right CA name (which is online). I've changed the behavior to filter out unnecessary CA objects and they are returned immediately after object construction (say, you've specified particular CA or CAs server which is online and there are other stopped CAs).

  • Service start/stop operations

Many commands (especially Set-* and Restore-*) has –RestartCA switch parameter to restart CA service to immediately apply changes. Previously there was a fixed 2sec timeout between StopService and StartService function calls. This fixed timeout causes service start issues when the CA database is relatively large. Now, the behavior is changed to wait until CA service is completely stopped and then call for service start. There are 2 notes:

After service is started, CA server may not be immediately available. This is because, CA server continues database checking and will not respond to client calls.

Do not use –RestartCA switch parameter and Start/Stop/Restart-CertificationAuthority commands against clustered CAs. This is because, when you try to stop CertSvc service, cluster will treat this as a node failure and will move CA resource to second node and CA cluster may fail. Instead, all service stop/start operations MUST be performed by using cluster tools (cluadmin.msc or Cluster PowerShell module), so the cluster service is aware about your actions. In other words, you must take appropriate resource offline or bring it back online.

New stuff

Mainly I've spent attention to existing commands and only 2 new commands are added:

If you are subscribed to my blog or read it on a regular basis, you may notice that this is the same stuff as posted here: Install Certification Authority with PowerShell. Enjoy CA installation from PowerShell console! :)

Other stuff

I've performed some additional tests and can say about:

  • PowerShell 3.0 support — not supported!

The module isn't working in Windows PowerShell 3.0 CTP1 and partially works in CTP2. The problem (still exist) with CTP2 is that it won't load format (PKI.Format.ps1xml) file. Other functionality seems ok, but without formatting. Will wait for next bits.

  • Clustered CA support

The module supports clustered CAs with the only limitation mentioned above (about CA server start and stop operations). Everything else works just fine and is supported.

Other notes and downloads are available here: Downloads

p.s. do not hesitate to share your opinions and suggestions regarding the module. It is designed for you and you have some good ideas to implement — you are welcome.

p.p.s. after new version publishing I've noticed that the module was downloaded 1k times (since project launch):

image

:)


Share this article:

Comments:


Post your comment:

Please, solve this little equation and enter result below. Captcha