Problem description

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>

Recently I was asked about how to read Enrollment Agent Rights and Certificate Manager Restrictions in ADCS. At first, I would like to make a little introduction about the subject.

Enrollment Agents

With Active Directory Certificate Services (ADCS) you can designate one or more enrollment agents to enroll on behalf of other users. One of the most common scenarios is smart card provisioning. Suppose, you purchased smart cards and plan to issue them to employees. You will designate one or more highly trusted persons who will:

• instruct employees about smart card usage policies;
• register smart card serial number/other data in the accounting system (some certificate lifecycle management system);
• prepare smart card for use (print labels and so on);
• install certificate for another employee.

Enrollment Agent Restrictions cover the last point in the list. Restrictions define three major parts:

About the problem

Almost everyday we hear about SHA1 deprecation policy. Many commercial CAs now sign end-entity certificates with SHA2 (actually, SHA256) and. Some of them upgrade issuing CAs to SHA2. Many security administrators  move their private CAs and certificates to SHA2 signatures. Unfortunately, not all do this migration correctly. Companies just configure their CAs to sign certificates with SHA256. Is this enough? Actually, not.

Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:

Recently I was tasked to configure SSL/TLS protocols and cipher suites for internal web servers via Group Policy. At first, we collected a list of web server and web client applications to determine the weakest possible SSL/TLS protocols. Once the list was complete, we deployed sample policy in test OU and finally applied them to the rest domain.

Now I was tasked to scan web servers to determine if they match new security policy. In order to minimize my effort in testing, I wrote a simple PowerShell script that accepts a list of web URLs and tests each host with a list of SSL protocols: SSLv2, SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. Here is a sample code: