Posts on this page:
In the previous post, I tried to explain some inconsistences in the current implementation of Constrained PowerShell feature that is introduced in PowerShell 5.0: PowerShell 5.0 and Applocker. When security doesn’t mean security. After having a long email and twitter conversations I realized that many of readers blame me for being against Constrained PowerShell feature. It is not true. In this post, I would like to summarize what is going wrong now and how it should work in my opinion.
A friend of mine asked why his PowerShell scripts (PowerShell profile) doesn’t execute properly in after upgrading to PowerShell 5.0. A brief investigation showed that interactive PowerShell console runs in Constrained Language mode, as the result many language features are stripped out and PowerShell profile isn’t loaded with the following error:
Windows PowerShell Copyright (C) 2015 Microsoft Corporation. All rights reserved. C:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 : Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator. At line:1 char:1 + . 'C:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_ ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Microsoft.PowerShell_profile.ps1], NotSupportedException + FullyQualifiedErrorId : DotSourceNotSupported,Microsoft.PowerShell_profile.ps1 PS C:\Users\vpodans> [math]::Sqrt(1) Cannot invoke method. Method invocation is supported only on core types in this language mode. At line:1 char:1 + [math]::Sqrt(1) + ~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) , RuntimeException + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage PS C:\Users\vpodans> $ExecutionContext.SessionState.LanguageMode ConstrainedLanguage PS C:\Users\vpodans>
I’m glad to announce another version of PowerShell PKI module release.
This release includes major internal code changes with new functionality.
At first, I completely separated Abstract Syntax Notation (ASN.1) code from main library to a dedicated DLL:
SysadminsLV.Asn1Parser.dll. As I mentioned in one of previous posts, PKI.Core.dll and ASN parser are opensourced on GitHub: pkix.net and Asn1DerParser.NET.
Some time ago I wrote a script that converts PEM file to CryptoAPI compatible format: How to convert PEM file to a CryptoAPI compatible format. The script involves some non-PowerShell commands (certutil) which associates private key with a certificate instance. I received several feedback comments about avoiding certutil in favor of native PowerShell/.NET managed code. In this post I want to show some code that eliminates certutil from the script.
Just to recall what we generally do when converting PEM to X509Certificate2/PFX:
It was a long-waited decision, however, finally I did it. Today I released my two major .NET projects to GitHub:
This is my own ASN.1 binary parser. ASN.1 parser/reader is a mandatory component when you are dealing with cryptography and cryptographic messages, because all they use ASN.1. I’m using this library in ASN.1 Editor and PowerShell PKI module’s API library (it is now opensourced as well).