Vadims Podans's blog - PowerShell | Certificates

Создание самоподписанного сертификата средствами PowerShell

Camelot — Sun, 18 Apr 2010 09:46:11 GMT

Самоподписанные сертификаты — это зло, за исключением сертификатов корневых CA. Я об этом говорил, говорю и буду говорить. Но в данном случае мы не преследуем цель создания самоподписанного сертификата. Нас по сути будет интересовать немного другое — рассмотрение принципа, который заложен во многих популярных тулзах как MakeCert или OpenSSL. Лично я не фанат ни первого, ни второго по своим сугубо личным причинам. Но, кроме этих двоих есть ещё утилита CertReq.exe, которая достаточно православная и вряд ли ей грозит вымирание (а жаль). Вобщем, сегодня предлагаю ещё раз поковырять CryptoAPI.

Как мы уже знаем, CryptoAPI обладает большим количеством всяческих COM интерфейсов, при помощи которых мы можем работать практически с любыми аспектами цифровых сертификатов. Некоторые из них бажные, а некоторые — не очень , но функционал у них впечатляющий. В настоящее время существует 2 основных набора API, которые реализуют клиентскую часть энроллмента — XEnroll и CertEnroll. Первый доступен только в системах начиная с Windows 2000 и до Windows Server 2003 включительно. В более новых версиях XEnroll был вырезан вместе с CAPICOM'ом полностью (куски CAPICOM'а ещё можно найти в висте) за ненадобностью. Семейство интерфейсов CertEnroll было значительно переработано и расширено, что делает его крайне гибким. Я не буду рассказывать про XEnroll, потому что это неинтересно и трупов пинать нехорошо.

Многие считают, что CryptoAPI — это очень сложно. Я могу возразить им. Я не программист совсем, но могу достаточно свободно их использовать. Нашей отправной точкой будет MSDN по адресу: Certificate Enrollment API Reference. Эта секция содержит всё самое необходимое — описание интерфейсов и перечисления. И самый первый интерфейс, который мы видим — IX509Enrollment. Этот интерфейс реализует нечто промежуточное между клиентом и сервером. Мы можем по описанию найти то, что нам нужно, а именно первую секцию — Out-of-band-enrollment. И мы видим, что для него надо сначала вызвать метод CreateRequest(). Но прежде чем вызывать метод, нам надо создать форму сертификата, на основе которой будет создан запрос. Как я уже упоминал, мы будем делать самоподписанный сертификат, поэтому следующий интерфейс подойдёт нам как нельзя кстати — IX509CertificateRequestCertificate2. Вот давайте с него и начнём.

Все указанные здесь и далее интерфейсы являются COM интерфейсами семейства X509Enrollment и эти объекты создаются следующим образом:

$Cert = New-Object -ComObject X509Enrollment.CX509CertificateRequestCertificate.1

Примечание: как строятся такие команды? Поскольку это COM интерфейс, первую букву I в названии интерфейса меняем на букву C. Далее, если мы видим цифру 2 в конце названия интерфейса, в команде мы ставим точку и пишем число на единцу меньшее. Вот такие нехитрые правила.

Прежде чем его начать использовать, нам надо инициализировать его. К сожалению документация на MSDN далеко не полная, поэтому будем искать нужные методы через PowerShell и командлет Get-Member:

[↓] [vPodans] $cert | gm -MemberType methods


   TypeName: System.__ComObject#{728ab35a-217d-11da-b2a4-000e7bbb2b09}

Name                             MemberType Definition
----                             ---------- ----------
CheckPublicKeySignature          Method     void CheckPublicKeySignature (IX509PublicKey)
CheckSignature                   Method     void CheckSignature (Pkcs10AllowedSignatureTypes)
Encode                           Method     void Encode ()
GetCspStatuses                   Method     ICspStatuses GetCspStatuses (X509KeySpec)
GetInnerRequest                  Method     IX509CertificateRequest GetInnerRequest (InnerRequestLevel)
Initialize                       Method     void Initialize (X509CertificateEnrollmentContext)
InitializeDecode                 Method     void InitializeDecode (string, EncodingType)
InitializeFromCertificate        Method     void InitializeFromCertificate (X509CertificateEnrollmentContext, string...
InitializeFromPrivateKey         Method     void InitializeFromPrivateKey (X509CertificateEnrollmentContext, IX509Pr...
InitializeFromPrivateKeyTemplate Method     void InitializeFromPrivateKeyTemplate (X509CertificateEnrollmentContext,...
InitializeFromPublicKey          Method     void InitializeFromPublicKey (X509CertificateEnrollmentContext, IX509Pub...
InitializeFromTemplate           Method     void InitializeFromTemplate (X509CertificateEnrollmentContext, IX509Enro...
InitializeFromTemplateName       Method     void InitializeFromTemplateName (X509CertificateEnrollmentContext, string)
IsSmartCard                      Method     bool IsSmartCard ()
ResetForEncode                   Method     void ResetForEncode ()


[↓] [vPodans]

Из всех методов нам по сути доступен только InitializeFromPrivateKey(), поскольку остальные методы инициализации требуют наличие доступа к Certification Authority. Посмотрим что требуется для этого метода:

[↓] [vPodans] $cert | gm -MemberType methods | ?{$_.name -eq "InitializeFromPrivateKey"} | select definition

Definition
----------
void InitializeFromPrivateKey (X509CertificateEnrollmentContext, IX509PrivateKey, string)


[↓] [vPodans]

В качестве аргументов метода нам надо указать контекст энроллмента и объект закрытого ключа. Значения контекста находятся здесь: X509CertificateEnrollmentContext (просто включаете поиск на MSDN по названию перечисления). В качестве контекста мы можем выбрать контекст текущего пользователя или компьютера (остальное нас сейчас не волнует совсем). Контекст пользователя имеет значение 0x1. Так и запишем. Но этого мало. Надо ещё создать объект закрытого ключа:

$PrivateKey = New-Object -ComObject X509Enrollment.CX509PrivateKey

Этот интерфейс позволяет задавать различные параметры закрытого ключа, но мы обойдёмся лишь самым необходимым:

# во-первых надо указать CSP. Выберем самый простой криптопровайдер
$PrivateKey.ProviderName = "Microsoft Base Cryptographic Provider v1.0"
# закрытый ключ будет использоваться для подписи (Digital Signature)
# http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx
$PrivateKey.KeySpec = 0x2
# длина вполне стандартная
$PrivateKey.Length = 1024
# ключ будем хранить в пользовательском хранилище
$PrivateKey.MachineContext = 0x0
# и генерируем ключ
$PrivateKey.Create()

Ура! Мы сгенерировали ключ. Теперь вернёмся к предыдущему интерфейсу и инициализируем его из закрытого ключа:

$Cert.InitializeFromPrivateKey(0x1,$PrivateKey,"")

Мы указываем контекст текущего пользователя и объект закрытого ключа. Там есть ещё один аргумент, который называется String. Я не знаю, что они этим хотели сказать, поэтому оставляем пустую строку. А теперь вернёмся к интерфейсу IX509CertificateRequestCertificate2 и посмотрим, что мы можем сделать сейчас. Например, используя свойства NotBefore и NotAfter мы зададим срок действия сертификата. Например, 1 год с сегодняшнего дня:

$Cert.NotBefore = [datetime]::Now
$Cert.NotAfter = $Cert.NotBefore.AddDays(365)

Теперь нам надо добавить следующие свойства: EncancedKeyUsage (т.е. для каких целей вообще будет использоваться сертификат), Subject (на кого будет выписан сертификат) и Issuer (кто выдал этот сертификат). Поскольку у нас самоподписанный сертификат, поле Subject и Issuer будут одинаковые. На MSDN'е не хватает документации по свойствам Issuer и Subject, но у нас есть поиск, который нас приведёт сюда: IX500DistinguishedName. Поля Subject и Issuer должны заполняться в формате Distinguished Name и доступные префиксы для DN достаточно понятно расписаны в таблице. Нам нужно как-то активировать этот объект. Методов для инициализации здесь нет, поэтому будем использовать метод Encode().

Лирическое отступление: в подавляющем большинстве случаев вы не можете присваивать значения свойствам объектов после создания самих объектов. Предварительно их надо «активировать» одним из двух способов. Если у объекта есть метод Initialize или производное от него, необходимо сначала воспользоваться одним из доступных методов инициализации. Если объект не содержит явных методов инициализации, нужно воспользоваться методом Encode, который кодирует объект или строку в ASN.1 DER строку и инициализирует объект. Единственным исключением из этого правила являются коллекции объектов. Они как правило используют метод Add() для добавления уже инициализированных объектов.

Уже с главной страницы IX500DistinguishedName видно, что Encode кодирует строку, которая записана в DN формате. Поэтому вызываем этот метод:

$SubjectDN.Encode("CN=Some Subject,DC=lucernepublishing,DC=COM", 0x0)

После строки нужно ещё указать флаг, в котором указана строка DN. Ставим дефолтный флаг. Теперь у нас готово поле Subject и Issuer (как мы договаривались, они будут одинаковые). Давайте их прицепим к нашему шаблону сертификата:

$Cert.Subject = $SubjectDN
$Cert.Issuer = $Cert.Subject

Что нам осталось сделать? Нам надо создать расширение Enchanced Key Usage. Для этого нам надо использовать следующий интерфейс: IX509ExtensionEnhancedKeyUsage:

$EKU = New-Object -ComObject X509Enrollment.CX509ExtensionEnhancedKeyUsage

Данный объект инициализируется из коллекции объектов IObjectIds. Давайте создадим эту коллекцию:

$OIDs = New-Object -ComObject X509Enrollment.CObjectIDs

В эту коллекцию с использованием метода Add() надо добавить один или несколько объектов IObjectId, каждый из которых представляет конкретное предназначение сертификата. Например, Server Authentication, Client Authentication, Smart Card Logon, Secure e-mail и т.д. Но мы сделаем сертификат для Code Signing. OID этого EKU = 1.3.6.1.5.5.7.3.3. Вот и сделаем его:

# создаём объект IObjectID
$OID = New-Object -ComObject X509Enrollment.CObjectID
# инициализируем его с использованием Code Signing
$OID.InitializeFromValue("1.3.6.1.5.5.7.3.3")
# добавляем наш OID в коллекцию OID'ов
$OIDs.Add($OID)
# добавляем коллекцию в объект IX509ExtensionEnhancedKeyUsage
$EKU.InitializeEncode($OIDs)

объект EKU у нас готов, теперь его надо добавить в наш шаблон сертификата. Поскольку это не стандартное поле сертификата, а расширение, добавляем этот объект в свойство X509Extensions, которое является аналогом интерфейса IX509Extensions и, который в свою очередь, является коллекцией расширений. Поэтому добавляем наше расширение методом Add():

$Cert.X509Extensions.Add($EKU)

Всё, мы собрали все минимально необходимые поля и расширения:

[↓] [vPodans] $cert


Type                        : 4
EnrollmentContext           : 1
Silent                      : False
ParentWindow                :
UIContextMessage            :
SuppressDefaults            : False
ClientId                    :
CspInformations             : System.__ComObject
HashAlgorithm               : System.__ComObject
AlternateSignatureAlgorithm : False
TemplateObjectId            :
PublicKey                   : System.__ComObject
PrivateKey                  : System.__ComObject
NullSigned                  : False
ReuseKey                    : False
Subject                     : System.__ComObject
CspStatuses                 : System.__ComObject
SmimeCapabilities           : False
SignatureInformation        : System.__ComObject
KeyContainerNamePrefix      : lp
CryptAttributes             :
X509Extensions              : System.__ComObject
CriticalExtensions          : System.__ComObject
SuppressOids                : System.__ComObject
Issuer                      : System.__ComObject
NotBefore                   : 16.04.2010 18:25:22
NotAfter                    : 16.04.2011 18:25:22
SignerCertificate           :
PolicyServer                :
Template                    :



[↓] [vPodans]

Теперь мы можем превращать наш шаблон сертификата в настоящй сертификат.

Лирическое отступление: а что такое запрос в техническом смысле? На самом деле запрос ничем не отличается от сертификата. Когда вы запрашиваете сертификат у CA, клиент использует эти же интерфейсы для генерации запроса. При этом получается самый настоящий самоподписанный сертификат, где Subject и Issuer одинаковые и равны имени текущего пользователя или компьютера, а так же содержит все необходимые расширения. Сам запрос подписывается закрытым ключом, который мы сгенерировали. По большому счёту, его уже можно использовать как настоящий самоподписанный сертификат. Если его отправить на сервер CA, то последний просто подменяет значения необходимых полей (как Issuer, в котором он ставит себя) и расширений, удаляет старую подпись и подписывает сертификат новой подписью. Вы можете убедиться в этом очень просто. Сгенерируйте запрос для сертификата, откройте оснастку Certificates и разверните секцию Certificate Enrollment Requests. Там будет этот самый запрос в виде уже готового сертификата. Просто там он ждёт, пока какой-нибудь CA не подпишет его.

Давайте вернёмся в самое начало текущего поста и вспомним про «исходный предмет» — IX509Enrollment. Вот этот интерфейс нам сконвертирует шаблон сертификата в настоящий сертификат с использованием метода CreateRequest(). Но прежде чем использовать метод, нам надо инициализировать объект:

$Request = New-Object -ComObject X509Enrollment.CX509enrollment
$Request.InitializeFromRequest($Cert)

И генерируем файл запроса, который ничем не отличается от самоподписанного сертификата:

$endCert = $Request.CreateRequest(0x0)

В аргументах метода указываем кодировку согласно этой страничке: EncodingType Enumeration. Мы выбираем Base64 с заголовками. $endCert будет содержать сам сертификат (открытую его часть). Фактически запрос хранится в контейнере Certificate Enrollment Requests. Поскольку этот интерфейс не был задуман специально для самоподписанных сертификатов мы проходим стандартную процедуру установки сертификата. Мы просто берём открытую часть нашего же сертификата и устанавливаем её. Вот, кстати, как он выглядит:

[↓] [vPodans] $endcert
-----BEGIN CERTIFICATE-----
MIICaTCCAdKgAwIBAgIQEzCS/mFIxLBAiGjz7+n0dDANBgkqhkiG9w0BAQUFADBP
MRMwEQYKCZImiZPyLGQBGRYDQ09NMSEwHwYKCZImiZPyLGQBGRYRbHVjZXJuZXB1
Ymxpc2hpbmcxFTATBgNVBAMMDFNvbWUgU3ViamVjdDAeFw0xMDA0MTgxMTI5MDla
Fw0xMTA0MTgxMTI5MDlaME8xEzARBgoJkiaJk/IsZAEZFgNDT00xITAfBgoJkiaJ
k/IsZAEZFhFsdWNlcm5lcHVibGlzaGluZzEVMBMGA1UEAwwMU29tZSBTdWJqZWN0
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBGa+PnrhnOFO5+76c5zX5/+xh
Kb2hUYl/pRuIKzYcqrmkvqjpPK/McusibT1h70emUkED0TSZsAlSivdIFK6WSxn6
HsTCaGIHhyOSKAvzQkBsZ74BPEydGT5LiX0+MOTyxwFAHhb+bqfbkdkXqUSkJAHK
Z6p+fgX8uaJkKjL/kwIDAQABo0YwRDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNV
HQ4EFgQUzIFwoRTY6KjUiqmjWjSjlkxbNncwDgYDVR0PAQH/BAQDAgeAMA0GCSqG
SIb3DQEBBQUAA4GBACizodCpl/cF3OGLUx8HVag0yhr1e1P8+CLPc31FmCPAY1CO
T0yxyJPoafkbXKRjclevNJdvxE3ys9fyYigFUhgswh3oWmjanDaatPKa0kE4147k
SQHvN8JP20KeDDCJBk/FbS3xCn3jTix90ddzTa1uFoqBbBNbKOaDHIrqypTY
-----END CERTIFICATE-----

[↓] [vPodans]

Система приклеит этот сертификат к шаблону сертификата и переложит его уже в контейнер Personal:

$Request.InstallResponse(0x2,$endCert,0x0,"")

Всё, теперь мы увидим этот сертификат в нашем хранилище и который готов к использованию. Я немного переработал код и обернул его в красивую функцию, которая будет делать следующее:

Генерировать тестовый самоподписанный сертификат для подписи скриптов PowerShell
Устанавливать сертификат с закрытым ключом в контейнер Personal
Устанавливать открытую часть сертификата в Trusted Root CAs для обеспечения доверия этому сертификату
Устанавливать открытую часть сертификата в Trusted Publishers для задания явного доверия цифровым подписям, сделанные этим сертификатом.

#####################################################################
# Create PowerShell cert.ps1
# Version 1.0
#
# Creates self-signed signing certificate and install it to certificate store
#
# Note: Requires at least Windows Vista. Windows XP/Windows Server 2003
# are not supported.
#
# Vadims Podans (c) 2010
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

function New-SigningCert {
<#
.Synopsis
    Creates self-signed signing certificate and install it to certificate store
.Description
    This function generates self-signed certificate with some pre-defined and
    user-definable settings. User may elect to perform complete certificate
    installation, by installing generated certificate to Trusted Root Certification
    Authorities and Trusted Publishers containers in *current user* store.
    
.Parameter Subject
    Specifies subject for certificate. This parameter must be entered in X500
    Distinguished Name format. Default is: CN=PowerShell User, OU=Test Signing Cert.

.Parameter KeyLength
    Specifies private key length. Due of performance and security reasons, only
    1024 and 2048 bit are supported. by default 1024 bit key length is used.

.Parameter NotBefore
    Sets the date in local time on which a certificate becomes valid. By default
    current date and time is used.

.Parameter NotAfter
    Sets the date in local time after which a certificate is no longer valid. By
    default certificate is valid for 365 days.

.Parameter Force
    If Force switch is asserted, script will prepare certificate for use by adding
    it to Trusted Root Certification Authorities and Trusted Publishers containers
    in current user certificate store. During certificate installation you will be
    prompted to confirm if you want to add self-signed certificate to Trusted Root
    Certification Authorities container.
#>
[CmdletBinding()]
    param (
        [string]$Subject = "CN=PowerShell User, OU=Test Signing Cert",
        [int][ValidateSet("1024", "2048")]$KeyLength = 1024,
        [datetime]$NotBefore = [DateTime]::Now,
        [datetime]$NotAfter = $NotBefore.AddDays(365),
        [switch]$Force
    )
    
    $OS = (Get-WmiObject Win32_OperatingSystem).Version
    if ($OS[0] -lt 6) {
        Write-Warning "Windows XP, Windows Server 2003 and Windows Server 2003 R2 are not supported!"
        return
    }
    # while all certificate fields MUST be encoded in ASN.1 DER format
    # we will use CryptoAPI COM interfaces to generate and encode all necessary
    # extensions.
    
    # create Subject field in X.500 format using the following interface:
    # http://msdn.microsoft.com/en-us/library/aa377051(VS.85).aspx
    $SubjectDN = New-Object -ComObject X509Enrollment.CX500DistinguishedName
    $SubjectDN.Encode($Subject, 0x0)
    
    # define CodeSigning enhanced key usage (actual OID = 1.3.6.1.5.5.7.3.3) from OID
    # http://msdn.microsoft.com/en-us/library/aa376784(VS.85).aspx
    $OID = New-Object -ComObject X509Enrollment.CObjectID
    $OID.InitializeFromValue("1.3.6.1.5.5.7.3.3")
    # while IX509ExtensionEnhancedKeyUsage accept only IObjectID collection
    # (to support multiple EKUs) we need to create IObjectIDs object and add our
    # IObjectID object to the collection:
    # http://msdn.microsoft.com/en-us/library/aa376785(VS.85).aspx
    $OIDs = New-Object -ComObject X509Enrollment.CObjectIDs
    $OIDs.Add($OID)
    
    # now we create Enhanced Key Usage extension, add our OID and encode extension value
    # http://msdn.microsoft.com/en-us/library/aa378132(VS.85).aspx
    $EKU = New-Object -ComObject X509Enrollment.CX509ExtensionEnhancedKeyUsage
    $EKU.InitializeEncode($OIDs)
    
    # generate Private key as follows:
    # http://msdn.microsoft.com/en-us/library/aa378921(VS.85).aspx
    $PrivateKey = New-Object -ComObject X509Enrollment.CX509PrivateKey
    $PrivateKey.ProviderName = "Microsoft Base Cryptographic Provider v1.0"
    # private key is supposed for signature: http://msdn.microsoft.com/en-us/library/aa379409(VS.85).aspx
    $PrivateKey.KeySpec = 0x2
    $PrivateKey.Length = $KeyLength
    # key will be stored in current user certificate store
    $PrivateKey.MachineContext = 0x0
    $PrivateKey.Create()
    
    # now we need to create certificate request template using the following interface:
    # http://msdn.microsoft.com/en-us/library/aa377124(VS.85).aspx
    $Cert = New-Object -ComObject X509Enrollment.CX509CertificateRequestCertificate
    $Cert.InitializeFromPrivateKey(0x1,$PrivateKey,"")
    $Cert.Subject = $SubjectDN
    $Cert.Issuer = $Cert.Subject
    $Cert.NotBefore = $NotBefore
    $Cert.NotAfter = $NotAfter
    $Cert.X509Extensions.Add($EKU)
    # completing certificate request template building
    $Cert.Encode()
    
    # now we need to process request and build end certificate using the following
    # interface: http://msdn.microsoft.com/en-us/library/aa377809(VS.85).aspx
    
    $Request = New-Object -ComObject X509Enrollment.CX509enrollment
    # process request
    $Request.InitializeFromRequest($Cert)
    # retrievecertificate encoded in Base64.
    $endCert = $Request.CreateRequest(0x1)
    # install certificate to user store
    $Request.InstallResponse(0x2,$endCert,0x1,"")
    
    if ($Force) {
        # convert Bas64 string to a byte array
         [Byte[]]$bytes = [System.Convert]::FromBase64String($endCert)
        foreach ($Container in "Root", "TrustedPublisher") {
            # open Trusted Root CAs and TrustedPublishers containers and add
            # certificate
            $x509store = New-Object Security.Cryptography.X509Certificates.X509Store $Container, "CurrentUser"
            $x509store.Open([Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
            $x509store.Add([Security.Cryptography.X509Certificates.X509Certificate2]$bytes)
            # close store when operation is completed
            $x509store.Close()
        }
    }
}

С виду кажется сложно, но на самом деле тут ничего сложного нет совсем. Просто представьте себе сертификат как большую матрёшку, в которую вы вкладываете другие маленькие матрёшки, которые представляют собой поля и расширения сертификатов. Начинаете собирать самые маленькие матрёшки, вкладываете в более большие и в конечном итоге собираете настоящий сертификат. Хоть документация на MSDN не очень полная, используя командлет Get-Member вы можете восполнить этот пробел.

1 PS1 file
13,1 KB New-SigningCert.ps1

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell (часть 3)

Camelot — Mon, 14 Dec 2009 18:47:12 GMT

Продолжаем серию постов, которые посвящены базовому управлению объектами PKI в Active Directory. На данный момент мы рассмотрели сценарии публикации и просмотра сертификатов в Active Directory:

На данном этапе нам осталось последнее — удаление сертификатов из AD. Логика здесь очень простая: командой Get-ADPKIObject мы получаем коллекцию объектов, которые представляют собой сертификаты и через конвейер командой Remove-ADPKIObject указываем ID объектов, которые необходимо удалить. Если кто-то уже разбирал код предыдущих скриптов, то ему будет совсем нетрудно понять логику скрипта удаления объектов. Вот он, вместе с комментариями:

function Remove-ADPKIObject {
<#
.Synopsis
    Deletes certificates from Active Directory containers
.Description
    Deletes certificates from Active Directory containers by specifying particular ID or IDs
.Parameter ID
    Specifies certificate ID to delete that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | Remove-ADPKIObject 2
    
    deletes certificate with ID = 2 in certificate viewer
.Outputs
    This command provide a resultant of operation.
#>
    param([int[]]$ID = $(throw "you must specify number of the object to delete"))
    # объявляем массив для хранения сертификатов из контейнера NTAuthCertificates
    begin {$sum = @()}
    process {
        # проверяем тип контейнера входящего объекта
        if ($_.Container -ne "NTAuthCertificates") {
            # если это не NTAuthCertificates, то проверяем, что ID текущего объекта
            # совпадает с ID, который нужно удалить
            if (@($ID) -contains $_.Id) {
                # если совпал, то собираем LDAP-запрос
                $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
                # и удаляем текущий объект из AD
                $retn = $ldap.Delete("certificationAuthority", "CN=$($_.Subject)")
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            }
        # если контейнер текущего объекта является NTAuthCertificates, то собираем их все в массив
        } else {$sum += $_}
    }
    end {
        # проверяем, что массив непустой (т.е. надо что-то удалять из NTAuthCertificates)
        if ($sum) {
            # если массив непустой, то выбираем те элементы, которые нужно сохранить
            # т.е. ID которых не содержится в аргументах скрипта
            $sum = @($sum |?{$ID -notcontains $_.Id})
            # делаем LDAP-запрос к этому контейнеру
            $ldap = [ADSI]"LDAP://CN=$($_.Container),$script:ConfigContext"
            # проверяем, что после фильтрации, хотя бы один сертификат нужно оставить
            if ($sum.count -ge 1) {
                # записываем первый сертификат. Это необходимо потому что ADSI не поддерживает запись
                # массива сертификатов в свойство cACertificate, а только один сертификат в виде byte[]
                $ldap.put("cACertificate", [byte[]]$sum[0].RawCertificate)
                # а вот простое добавление он поддерживает. Тогда ADSI сам пересоберёт объекты
                # в свойстве в нужный формат данных. На данном этапе я применил маленькую хитрость:
                # как видно, я первый сертификат записываю дважды - предыдущей строкой и в первой итерации
                # текущей строки. Но это не проблема, поскольку метод SetInfo() записывает только уникальные
                # объекты, а дублирующиеся просто отбросит.
                $sum | %{$ldap.cACertificate += ,[byte[]]$($_.RawCertificate)}
                $ldap.SetInfo()
                if ($?) {
                    Write-Host "`'$($_.Subject)`' certificate was sucessfully deleted from `'$($_.Container)`' container"`
                    -ForegroundColor Green
                }
            # а вот если после фильтрации объектов, у нас ничего не остаётся на запись, то это означает, что все
            # сертификаты из этого контейнера удаляются. Поэтому мы просто удаляем запись NTAuthCertificates.
            } else {
                ([ADSI]"LDAP://$script:ConfigContext").Delete("certificationAuthority", "CN=NTAuthCertificates")
                if ($?) {Write-Host "All certificates was sucessfully deleted from NTAuthCertificates entry ." -ForegroundColor Green
                    Write-Warning "This was last certificate in contaner. NTAuthCertificates entry is removed from Active Directory"
                }
            }
        }
    }
}

И теперь можно подвести краткие итоги. Мы смогли реализовать функционал certutil и других графических утилит (консоли MMC) в PowerShell значительно улучшив читабельность выходных объектов, адаптировали под работу из консоли (синтаксис стал значимо короче и более юзерфрендли) и шаг за шагом делаем из PowerShell единое консольное средство управления различными аспектами PKI.

Можно задать вопрос: а кто целевая аудитория всего этого? Целевая аудитория есть — администраторы PKI. Просто у вас не всегда будет возможность использовать графические консоли для решения этих задач (потому что их функционал далёк от идеального). Можно использовать certutil, который умеет много чего, но тоже имеет свои недостатки. Это и ужасный синтаксис, и вырвиглазный неуправляемый вывод результатов. Вобщем я надеюсь, что рано или поздно PowerShell сможет по-настоящему заменить certutil (который вообще-то ни в чём не виноват) и стать единой консолью всех Windows-администраторов. Вот не знаю на сколько это хорошо или плохо, потому что Microsoft всех насильно переводит на PowerShell (это очень показательно продемонстрировано в MS Exchange, где у вас по сути есть только PowerShell и всё). Обычно, насильно переводят на другой инструмент когда он является УГ и очень тяжело на него перевести людей посредством обычной рекламы. Но является ли PowerShell таким УГ? Я пока не готов ответить на этот вопрос. Моё мнение — PowerShell пока что особой революцией не стал. Даже не смотря на тонны рекламы, пеара и прочего, где восхваляют PowerShell, закидывают ногами CMD/WSH. Это обусловлено тем фактом, что не всегда PowerShell бывает удобней CMD/WSH, особенно в тривиальных задачах. Говорить, что синтаксис стал более простым и компактным тоже нельзя, потому что реально функционала из коробки хватает для решения процентов 10 задач. Всё остальное нужно скриптовать и программировать (да-да!) самому. Благо средств для этого в PowerShell хватает. Во что это обычно выливается? А в то, что в большинстве случаев результирующий объём кода будет не сильно меньше, чем в связке WSH + CMD. В любом случае преимущества PowerShell перед остальными очевидны, но они далеко не определяющие, ведь люди раньше решали свои задачи на WSH/CMD, пирожки продавались, бизнес шёл. С одной стороны Microsoft дал людям простор для творчества, т.е. делать в PowerShell всякие потрясающие штуки и всё такое. Но это не совсем то, что нужно было администраторам. Им нужна одна кнопка на весь экран с надписью «Сделать всё п**дато!». Пока что PowerShell и близко не готов стать такой кнопкой, а является «удочкой». Т.е. удочка у вас уже есть, а что касается конечной рыбы (результата), то дело осталось за малым — написать мега-скрипт. Мне вот интересно, что думают администраторы Exchange (поскольку пока что только они получили полноценную поддержку для своего продукта в PowerShell) — стало ли им жить легче с PowerShell или нет? Если да, то это может быть хорошим знаком, что однажды PowerShell станет такой кнопкой. И не будет более в системе certutil и всеми задачами будет рулить PowerShell (пока что это наиболее логичный сценарий развития событий). А вот если их жизнь не стала легче, то обещанной революции (которая по словам Microsoft уже наступила, как и вендекапец у луноходов) не будет, а будет просто какое-то логическое продолжение предыдущих инструментов для сценариев.

К чему я написал столько букв? К тому, что я ежедневно задаю себе один и тот же вопрос: а зачем я всё это делаю? А ответ найти очень непросто, потому что отмазы вида «проще, удобней, красивее» не годятся для серьёзного аргумента. На самом деле я не ищу ответ на него, а просто говорю себе «так надо» и делаю. Поэтому не надо меня использовать как пример «правильного пользователя PowerShell» и пытаться повторить что-то подобное астрономических масштабов на овер9000 строк — поверьте, оно не стоит того. Используйте его по мере сил. Если чего-то будет не хватать и его решение потребует значительных усилий — посмотрите на готовые утилиты, они наверняка будут уметь то, что вам надо.

Удачи!© One

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell (часть 2)

Camelot — Fri, 11 Dec 2009 21:09:45 GMT

В предыдущем посте мы ознакомились с основными контейнерами с объектами PKI в Active Directory и смогли изучить функциональный аналог ключа dspublish в утилите certutil. Если публикация сертификатов в AD задача простая даже для Certutil, то просмотр содержимого может быть весьма нетривиальным. Например, если вы хотите посмотреть содержимое записи NTAuthCertificates, то придётся выполнить вот такую команду:

certutil –viewstore "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration, ForestRootDomainDN"

такие вещи совершенно неприспособлены к командной строке, поскольку надо набирать много текста и ошибиться весьма просто. Одно хорошо, команда выводит графическое окошко, где мы можем посмотреть содержимое. Но тут есть несколько неудобных моментов: мы не можем посмотреть несколько контейнеров сразу, для каждого контейнера надо выполнять отдельную команду. В этом окошке мы можем только посмотреть на содержимое контейнера и всё. Ни добавить, ни удалить сертификат мы не можем. Для добавления сертификатов мы можем воспользоваться тем же certutil или моим скриптом, который был опубликован в предыдущем посте. Графика — хорошо и замечательно, но мы можем хотеть автоматизировать какие-то задачи или просто посмотреть информацию в консоли. Вы можете подумать, что это не нужно, но преимущество между консольным выводом и графическим диалоговым окном очевидное: из первого можно копировать информацию в буфер обмена. Есть ещё вариант — для просмотра и удаления сертификатов из AD, пользоваться консолью pkiview.msc. Но мы сразу же теряем главную нить — единое средство управления. Т.е. даже похожие операции мы должны выполнять в разных инструментах! Но с появлением PowerShell мы получили единый (хоть и консольный) инструмент, которым можно автоматизировать абсолютно всё! Даже сам PowerShell Вот, собственно код, который в разы упрощает процесс просмотра содержимого контейнеров:

function Get-ADPKIObject {
<#
.Synopsis
    Displays certificates info from Active Directory containers
.Description
    Displays info about certificates that are stored in AD PKI-related containers.
.Parameter Container
    Optional parameter. Specifies particular container to view. May contain one or
    more value from following possible values:
    
    RootCA - retrieves certificates from Certification Authorities container
    SubCA - retrieves certificates from AIA container
    NTAuthCA - retrieves certificates from NTAuthCertificate directory entry.
    
    if no parameter is set, command will return all certificates from all applicable
    containers.
.EXAMPLE
    Get-ADPKIObject RootCA
    
    Retrieves certificates from Certification Authorities container
.EXAMPLE
    Get-ADPKIObject RootCA, AIA
    
    Retrieves certificates from Certification Authorities and AIA containers
.Outputs
    Output AD PKI object collection
#>
[CmdletBinding()]
    param([string[]][ValidateSet("RootCA", "SubCA", "NTAuthCA", "")]$Container)
    # объявляем массив, который будет хранить выходные объекты
    $script:sum = @()
    # это весьма крутая штука будет. Каждый объект будет содержать свойство Id или просто
    # порядковый номер объекта. При дальнейших операциях с этими объектами вам достаточно
    # будет указать его Id вместо длинных и неудобных LDAP/Thumpbrint значений, как это делается
    # в certutil и подобных ему утилитах. Нумерацию начнём с единицы
    $script:n = 1
    # итоговая функция, которая будет разбирать бинарные массивы и готовить выходные объекты
    function _formatter_ ($certs, $type, $name) {
        # поскольку у нас все объекты в AD находятся в бинарном формате, мы импортируем каждый из них
        # в X509Certificate2 объект.
        $certs | %{
            $script:Cert.Import($_)
            # здесь мы создаём образец выходного объекта и обвязываем этот объект необходимыми свойстами и данными
            $current = "" | select @{n='Id';e={$script:n}}, Subject, @{n='Type';e={$type}}, @{n='Container';e={$name}},
                @{n='Thumbprint';e={$script:Cert.Thumbprint}}, @{n='SerialNumber';e={$script:Cert.SerialNumber}}, 
                @{n='ValidFrom';e={$script:Cert.NotBefore}}, @{n='ValidTo';e={$script:Cert.NotAfter}}, 
                @{n='RawCertificate';e={$script:Cert.RawData}}
            # чтобы не писать полный DN поля Subject, мы будем показывать только первую его часть
            # (которая отображается в самом сертификате)
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $current.Subject = $matches[1]
            # добавляем объект в массив выходных объектов
            $script:sum += $current
            # очищаем X509Certificate2
            $script:Cert.Reset()
            # увеличиваем счётчик и обрабатываем следующий элемент
            $script:n++
        }
    }
    # ещё одна суб-функция, которая выдёргивает сертификаты из AD в бинарном виде и отправляет
    # их в _formatter_, который уже сформирует итоговые объекты.
    function _switcher_ ($name) {
        # подключаемся к нужному контейнеру
        $ldap = [ADSI]("LDAP://CN=$name,$script:ConfigContext")
        # как мы знаем, NTAuthCertificates не является контейнером, поэтому для него код будет немного
        # отличаться. А отличие будет состоять в том, что мы не будем залезать в контейнер, а сразу читать
        # свойства объекта NTAuthCA
        if ($name -eq "NTAuthCertificates") {
            # убеждаемся, что длина первого элемента свойства cACertificate больше единицы, т.е. содержит ненулевое
            # значение. Так же проверяем свойство crossCertificatePair, которое содержит Cross-certificates
            # и если оно не нулевое, то отправляем и его на формирование вывода
            if ($ldap.cACertificate[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "CA Certificate" $name
            }
            if ($ldap.crossCertificatePair[0].count -gt 1) {
                $certs = @($ldap.cACertificate)
                _formatter_ $certs "Cross CA Certificate" $name
            }
            # и переходим к следующему контейнеру
            return
        }
        # если контейнер указан как Certification Authority и/или AIA, то заглядываем
        # внутрь контейнера
        $ldap.psbase.children | %{
        # и заглядываем в каждую запись на исследование свойств cACetificate и crossCertificatePair
            $certs = @($_.cACertificate)
            $ccerts = @($_.crossCertificatePair)
            # проверяем, что свойство имеет ненулевое значение. Если так, то отправляем
            # содержимое этих свойств на формирование вывода
            if ($certs[0].count -gt 1) {_formatter_ $certs "CA Certificate" $name}
            if ($ccerts[0].count -gt 1) {_formatter_ $ccerts "Cross CA Certificate" $name}
        }
    }
    switch ($Container) {
        # конструкцией switch проверяем содержимое аргумента функции, чтобы определить какие именно
        # контейнеры надо обследовать.
        "RootCA" {_switcher_ "Certification Authorities"}
        "SubCA" {_switcher_ "AIA"}
        "NTAuthCA" {_switcher_ "NTAuthCertificates"}
        # если контейнер в аргументе не указан, то проверяем все контейнеры и записи
        "" {
            _switcher_ "Certification Authorities"
            _switcher_ "AIA"
            _switcher_ "NTAUthCertificates"
        }
    }
    # когда вывод будет полностью сформирован, выбрасываем все объекты в консоль
    $script:sum
}

Примечание: данная функция является частью файла dspublish.ps1, т.к. использует глобально объявленные переменные.

и вывод у него вот такой красивый:

Id             : 3
Subject        : Contoso CA
Type           : CA Certificate
Container      : AIA
Thumbprint     : BA8FECE99165E68CE27C9F0AF5F0664FDA39F7A2
SerialNumber   : 5DD87E4CFFE3B3BC43F608EB57C767F7
ValidFrom      : 2009.02.15. 16:31:15
ValidTo        : 2014.02.15. 16:40:11
RawCertificate : {48, 130, 4, 98...}

Id             : 4
Subject        : sysadmins-LV-CA
Type           : Cross CA Certificate
Container      : AIA
Thumbprint     : 1A28B582E21803D2BFE0DAEEF4593DE372C8EC3C
SerialNumber   : 170AD11B0000000000A7
ValidFrom      : 2009.11.24. 19:43:10
ValidTo        : 2011.03.30. 17:06:53
RawCertificate : {48, 130, 7, 94...}

я считаю его достаточно информативным. Но если хотите посмотреть любой сертификат из этого списка, то можно и сделать просмотр. К сожалению я в программировании не шарю и как работать напрямую с библиотекой просмотрщика сертификатов, поэтому я реализовал просмотр обходным путём:

filter View-ADPKIObject {
<#
.Synopsis
    Displays certificates in certificate viewer
.Description
    Displays certificates in certificate viewer by selecting necessary certificates ID.
    Must be placed after Get-ADPKIObject command only.
.Parameter ID
    Specifies certificate ID that was set in Get-ADPKIObject command.
.EXAMPLE
    Get-ADPKIObject RootCA | ViewADPKIObject 1, 3
    
    displays certificate with ID = 2 in certificate viewer
.Outputs
    Script doesn't generate any output except errors
#>
    # судя по конструкции int[] мы можем указать несколько чисел, тогда все выбранные
    # сертификаты будут отображены. Номер указывать обязательно.
    param([int[]]$ID = $(throw "you must specify number of the object to display"))
    # и проверяем входные объекты с конвейера на предмет их ID. Если ID совпадает с
    # одним из ID в аргументах, обрабатываем его. Если ID не совпадает, ничего не делаем.
    if (@($ID) -contains $_.Id) {
        # генерируем в пользовательской папке Temp временный файл с рандомным расширением
        $TempFile = [System.IO.Path]::GetTempFileName() + ".cer"
        # записываем бинарный массив сертификата в файл в виде DER кодировки
        [System.IO.File]::WriteAllBytes($TempFile, $_.RawCertificate)
        # запускаем файл (просмоторщик сертификатов)
        & $TempFile
        # в санитарных целях ждём пол секунды
        Start-Sleep 0.5
        # и удаляем этот файл, чтобы не копился мусор
        del $TempFile -Force
    }
}

Как вы видите, ничего сверх-космического или магического в этом коде нет, самое трудное здесь — придумать логику работы. А остальное — накидать несколько строк кода и у нас PowerShell в лёгкую может соперничать с certutil за право называться единой утилитой управления PKI

Чтобы подкрутить рейтинг PowerShell в этой конкуренции, в следующий раз я покажу как мы можем легко и просто удалять сертификаты из контейнеров AD с использованием PowerShell

PowerShell Powered - http://www.sysadmins.lv

Active Directory PKI object management с помощью PowerShell

Camelot — Wed, 09 Dec 2009 19:35:17 GMT

Подоспела ещё одна задачка для PowerShell'а — управление объектами PKI в Active Directory. Active Directory содержит целый раздел посвящённый PKI и вот из чего он состоит:

CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain
CN={CA name},CN=Certification Authority, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain

Вот о них мы сегодня и поговорим. В AD есть ещё несколько контейнеров, которые связаны с PKI, но они сегодня интереса представлять не будут. Как мы уже знаем, в:

NTAuthCertificates публикуются все сертификаты CA, которые выдают сертификаты для аутентификации пользователей в домене. В том числе для логона смарт-картой, аутентификации в IIS или для аутентификации EAP-TLS в VPN. Все сертификаты в этой записи хранятся в виде массива;
AIA публикуются сертификаты промежуточных (Intermediate) CA, за счёт чего можно значительно сократить время построения цепочек сертификатов. При этом не обязательно должен содержать сертификаты CA, которые зарегистрированы в текущем лесу. Это могут быть сертификаты промежуточных CA сторонних компаний, сертификаты которых вы используете. По большому счёту сюда должны публиковаться все сертификаты;
CDP публикуются CRL списки CA для ускорения проверки сертификатов в цепочке. Так же, как и в случае с AIA не обязательно может содержать CRL'ы CA только текущего леса. Сюда могут публиковаться и CRL сторонних CA, сертификаты которых вы используете;
Certification Authority публикуются сертификаты корневых CA, которым должен доверять весь лес.

Вы спросите, а зачем это всё, если то же самое можно сделать через групповые политики? Ответ тут достаточно очевиден. Дело в том, что PKI не видит границ доменов и эти сертификаты распространяются по всему лесу вместе с репликацией. Поэтому для добавления нового доверенного корневого CA вам придётся создавать одинаковую политику в каждом домене леса. И вы некоторые объекты (например CRL) не можете распространять через GPO.

Какие у нас есть инструменты для управления данными контейнерами? Их у нас несколько:

ADSIEdit.msc — обеспечивает только просмотр содержимого контейнеров в AD (но сами записи там нечитабельны);
PKIView.msc — позволяет просматривать содержимое каждого контейнера и удалять оттуда сертификаты. C использованием данной консоли мы можем добавлять сертификаты только в NTAuthCertificates. Остальные — только чтение и удаление;
certutil — интерфейс командной строки, который позволяет добавлять, просматривать контейнеры и удалять сертифакты из них.

Кажется, что certutil'а хватит всем. Но у него есть одна большая проблема — ужасный синтаксис. Напрмер, если вы хотите посмотреть CRL'ы в AD, то придётся делать что типа такого:

certutil –viewstore ldap:///CN=MyCA,CN=CRL,CN=CDP,CN=Public%20Key%
20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

этот синтаксис возможно чем-то универсален, но cовершенно неудобный для использования в командной строке, поэтому я поставил задачу решить этот вопрос с помощью PowerShell. И вот как я его решил:

Примечание: к сожалению я не в состоянии объяснять все особенности работы ADSI и PowerShell, поэтому для понимания работы скрипта нужно иметь представление и некоторый опыт скриптования с использованием ADSI и PowerShell.

#####################################################################
# dspublish.ps1
# Version 0.7
#
# Adds certificates in Active Directory containers
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires -Version 2.0

# любая ошибка будет фатальной, поэтому при её возникновении останавливаем работу
# скрипта, чтобы предотвратить фатальные изменения в Active Directory
trap {break}
# объявляем глобальные переменные, которые будут использоваться всеми функциями скрипта
$script:ConfigContext = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetDirectoryEntry().distinguishedName
$script:ConfigContext = "CN=Public Key Services,CN=Services,CN=Configuration," + $script:ConfigContext
$script:Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2

function Publish-ADPKIObject {
<#
.Synopsis
    Publishes certificates to Active Directory containers
.Description
    Publishes certificates to Public Key Services containers in Active Directory.
.Parameter File
    Specifies the path to certificate file or X509Certificate2 object.
    Certificates may be passed through pipeline.
.Parameter Container
    Specifies the AD PKI container to publish file. For certificates only
    following containers MUST be used:
    
    RootCA - indicates that certificate will be published to Certification Authorities container
    SubCA - indicates that certificate will be published to AIA container
    NTAuthCA - indicates that certificate will be added to NTAuthCertificate directory
    entry. If not exist, entry will be created.
    
    you MAY specify several containers at once. Certificate will be added to all
    specified containers. Entry names are based on certificate subject.
    
.Parameter Force
    forces object rewrite if object already exist in Active Directory
.EXAMPLE
    dir *.cer | Publish-ADPKIObject RootCA, SubCA
    
    will publish all .CER certificates to Certification Authorities and AIA containers
.EXAMPLE
    Publish-ADPKIObject certificate.cer RootCA -Force
    
    will publish 'Certificte.cer' certificate to Certification Authorities container. If
    object already exist, it will rewrited
.Outputs
    This command provide a resultant of operation.
#>
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [object[]]$file,
        [Parameter(Mandatory = $true, Position = 1)]
        [string[]]$Container,
        [switch]$Force
    )
    begin {
        # функция, которая будет осуществлять запись сертификатов в AD
        function _ldaproutine_ ($ldap, $CN, $script:Cert, $name, $Force) {
            $path = [ADSI]"LDAP://$ldap"
            # убеждаемся, что такой же объект не существует в AD
            if ($($path.psbase.children | ?{$_.cn -eq $CN})) {
                # если существует, проверяем ключ Force, который позволяет перезаписывать
                # объекты
                if ($force) {
                    $ldap = [ADSI]"LDAP://CN=$CN,$ldap"
                    # если ключ Force указан, то мы просто перезаписываем свойство
                    # cACertificate новым сертификатом
                    $ldap.put("cACertificate", $script:Cert.RawData)
                    # предыдущей строкой мы просто перезаписали объект, который теперь
                    # надо записать в AD методом SetInfo()
                    $retn = $ldap.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully rewrited to `'$name`' container" -ForegroundColor Green}
                # если объект уже существует и ключ Force не указан, то просто выводим сообщение, что такой объект уже существует
                } else {Write-Warning "Object already exist in `'$name`' container. Use -Force switch to rewrite"}
            } else {
                # если объект ещё не существует в указанном контейнере, то создаём в нём новый объект
                # с типом certificationAuthority
                $CA = $path.Create("certificationAuthority","CN=$CN")
                # записываем сертификат в свойство cACertificate в бинарном виде из объекта X509Certificate2
                $CA.Put("cACertificate", $script:Cert.RawData)
                # записываем нулями обязательные поля, которые требуются для создания объекта. Использовать как есть.
                $CA.Put("authorityRevocationList", 0)
                $CA.Put("certificateRevocationList",0)
                # когда объект сформирован, записываем его в AD
                $retn = $CA.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
            }
        }
    }
    # рабочая секция, которая будет разбирать входные сертификаты и подготавливать необходимые данные
    # которые необходимы для записи 
    process {
        # выбираем текущий объект сертификата
        $script:Certificate = gi $file -ErrorAction Stop
        # проверяем, что объект не является готовым объектом X509Certificate2
        if ($script:Certificate -isnot [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            # если не является, то это будет файл. Проверяем расширение файла.
            # допускаются только расширения CER и CRT
            if (".cer", ".crt" -contains $script:Certificate.Extension) {
                # если это CER или CRT файл, то конвертируем его в объект X509Certificate2
                $script:Cert.Import($script:Certificate.FullName)
                # в переменную $CN записываем первую часть поля Subject сертификата
                [void]($script:Cert.Subject -match 'CN=([^,]+)')
                $CN = $matches[1]
            }
        # если у нас на конвейер или через аргументы поступил готовый X509Certificate2, то только выбираем
        # поле Subject в отдельную переменную.
        } else {
            $script:Cert = $script:Certificate
            [void]($script:Cert.Subject -match 'CN=([^,]+)')
            $CN = $matches[1]
        }
        # проверяем аргументы, которые указывают на контейнеры, куда надо записывать наши сертификаты.
        # я не делал проверку этих контейнеров в секции param() через использование ValidateSet
        # поскольку данная функция в будущем будет использоваться и для публикации CRL. А для
        # них нужно вручную прописывать имя записи в контейнере CDP и оно может быть произвольным.
        # отфильтровываем все неправильные контейнеры, которые были заданы при вызове функции
        $Container = $Container | ?{"RootCA","SubCA","NTAuthCA" -contains $_}
        # если после фильтрации ни одного валидного контейнера не осталось, то очень сильно ругаемся.
        if (!$Container) {throw "For certificate containers only following values are applicable: RootCA, SubCA, NTAuthCA"}
        # проверяем, что входной сертификат содержит свойство CertificateAuthority равным True.
        # это свойство соответствует расширению Basic Constraints в сертификате, которое может иметь
        # значения: Subject Type=CA - это сертификат CA и Subject Type=End entity, если это конечный
        # сертификат. А в X509Certificate2 конечный сертификат будет иметь значение False в свойстве
        # CertificateAuthority. Но работу скрипта не прерываем, а просто пропускаем текущий сертификат.
        if (!$script:Cert.Extensions | ?{$_.CertificateAuthority -eq $true}) {
            Write-Warning "Input certificate `'$CN`' is not recognized as CA certificate. Skipping"
            return
        }
        # а теперь подготавливаем необходимые данные для записи в зависимости от названия контейнера
        switch ($Container) {
            "RootCA" {
                # указываем название данного контейнера в AD
                $name = "Certification Authorities"
                # получаем LDAP объект этого контейнера
                $ldap = "CN=$name,$script:ConfigContext"
                # и отправляем всё это в функцию записи
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "SubCA" {
                # здесь то же самое, что и для RootCA
                $name = "AIA"
                $ldap = "CN=$name,$script:ConfigContext"
                _ldaproutine_ $ldap $CN $script:Cert $name $Force
                $script:Cert.Reset()
            }
            "NTAuthCA" {
                $name = "NTAuthCertificates"
                $ldap = [ADSI]"LDAP://CN=$name,$script:ConfigContext"
                # поскольку NTAuthCertificates не является контейнером, а отдельной
                # записью, которая содержит массив сертификатов, то правила записи
                # здесь немного иные. Сначала проверяем, что эта запись уже существует в AD.
                if (!$ldap.cn) {
                    # если нет, то создаём её
                    $CA = ([ADSI]"LDAP://$script:ConfigContext").Create("certificationAuthority","CN=$name")
                    # заполняем обязательные свойства объекта и первый сертификат.
                    $CA.Put("authorityRevocationList", 0)
                    $CA.Put("certificateRevocationList",0)
                    $CA.put("cACertificate", $script:Cert.RawData)
                    # когда объект уже готов, то просто записываем его в AD
                    $retn = $CA.SetInfo()
                    if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                    return
                }
                # а вот если эта запись уже есть, то ничего создавать не надо, а просто добавляем
                # новый сертификат вдобавок к существующим. При этом обратите внимание, что объект добавляется
                # как массив (используется запятуя сразу за оператором). Это связано с особенностью работы PowerShell с
                # массивами. Поскольку бинарный сертификат сам по себе является массивом, то при простом добавлении
                # к существующему бинарному массиву, просто сделает ресайз текущего массива. Чтобы новый массив
                # записать как отдельный элемент нового массива - надо при помощи запятой явно это указать
                $ldap.cACertificate += ,$cert.RawData
                # и записываем объект обратно в AD.
                $retn = $ldap.SetInfo()
                if ($?) {Write-Host "`'$CN`' certificate is sucessfully added to `'$name`' container" -ForegroundColor Green}
                $script:Cert.Reset()
            }
        }
    }
}

А примеры использования этого скрипта приведены во встроенном хелпе и сводятся к одной из схем:

Publish-ADPKIObject <certificate> <container> –Force
<certificate> | Publish-ADPKIObject –Force

Причём вы можете указывать несколько контейнеров сразу, например: Publish-ADPKIObject file.cer NTAuthCA, RootCA, SubCA. Я думаю, что этот скрипт получился не такой уж и сложный и его разобрать с помощью моих комментариев не так и сложно. Его можно спокойно расширить под другие контейнеры, например, CDP или KRA. Единственное, что здесь пока не реализовано — санитизация имён объектов. На сколько я знаю, certutil этого тоже не поддерживает. Но сделать её надо. Правда, я пока не нашёл ни одного стандартного механизма, который бы санитизировал имена

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell (часть 2)

Camelot — Mon, 19 Oct 2009 18:52:44 GMT

Примечание: данный материал публикуется на правах ТЗ (ТЗ — Тайное Знание) и обязателен для знания администраторам PKI.

В предыдущей части (Certificate chaining engine в PowerShell) мы рассмотрели реализацию certificate chaining engine в .NET в виде класса X509Chain. Но этот рассказ был бы неполным, если мы не поговорили про CAPICOM.Chain. Хоть Microsoft рекомендует использовать .NET, а не CAPICOM для решения данной задачи, я считаю необходимым осветить этот вопрос. Для начала начнём с реализации CAPICOM в PowerShell. По непонятным мне пока причинам мне не удалось завести его в PowerShell на системах Windows Vista и выше, поэтому примеры буду приводить на Windows Server 2003.

PS G:\> $chain = New-Object -ComObject "CAPICOM.Chain"
PS G:\> $chain

Certificates
------------



PS G:\> $chain | gm -MemberType methods


   TypeName: System.__ComObject#{ca65d842-2110-4073-aee3-d0aa5f56c421}

Name                MemberType Definition
----                ---------- ----------
ApplicationPolicies Method     IOIDs ApplicationPolicies ()
Build               Method     bool Build (ICertificate)
CertificatePolicies Method     IOIDs CertificatePolicies ()
ExtendedErrorInfo   Method     string ExtendedErrorInfo (int)


PS G:\>

Так же, как и в .NET у нас есть метод Build(), который запускает certificate chaining engine для указанного сертификата. Но это COM объект и X509Certificate2 объекты не принимает. Поэтому мы средствами этого же CAPICOM получим нужный объект сертификата:

PS G:\> $store = New-Object -ComObject "CAPICOM.Store"
PS G:\> $store.Open(2,"my",128)
PS G:\> $cert = @()
PS G:\> $store.Certificates | %{$cert += $_}
PS G:\> $cert = $cert[1]
PS G:\> $cert


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :



PS G:\>

Вот такой объект сертификата мы получили. Вот его и пропустим через метод Build():

PS G:\> $chain.Build($cert)
False
PS G:\> $chain.Status()
32
PS G:\> $chain.Certificates


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :

Version       : 3
SerialNumber  : 3DFFAF914D613282427BD591C1FB586D
SubjectName   : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.06. 10:21:01
ValidToDate   : 2014.08.06. 10:30:54
Thumbprint    : E82ACC45841280DDEAB9F7847418FA26354457A7
Archived      : False
PrivateKey    :



PS G:\> $chain.ApplicationPolicies()

                                   Name FriendlyName                            Value
                                   ---- ------------                            -----
                                    123 Smart Card Logon                        1.3.6.1.4.1.311.20.2.2
                                    101 Client Authentication                   1.3.6.1.5.5.7.3.2


PS G:\>

Метод вернул False, т.е. наш сертификат не прошёл проверку. Свойство Certificates содержит все сертификаты в текущей цепочке. А метод ApplicationPolicies() показал Application Policies (в прошлом EKU). Ну и метод Status() вернул код ошибки. Все коды ошибок расписаны в описании самого метода. Т.е. ошибка 32 по табличке означает:

CAPICOM_TRUST_IS_UNTRUSTED_ROOT (&H00000020) — The certificate or certificate chain is based on an untrusted root.

Особо углубляться дальше я смысла не вижу, поскольку используя эти примеры можно поупражняться в других задачах с использованием CAPICOM. А вместо этого, мы разберём кое-какие неочевидные, но очень важные вещи.

Когда вышел Remote Desktop Connection 7.0 (который поставляется вместе с Windows 7), Александр Станкевич (MVP: Enterprise Security) заметил очень плохую особенность с ним, а именно — рандомно пропал доступ к терминальным серверам, которые используют SSL для терминальных подключений. В ходе множества проверок было констатировано:

цепочка завершалась на доверенном корневом сертификате (через просмотр сертификата);
CDP/AIA пути были валидные и CRL не были просрочены;
остальные параметры были сконфигурированы верно.

RDP клиент мотивировал отказ в подключении следюущим: «RDP клиент не смог проверить сертификат на отзыв». Причём подключение с предыдущих версий RDC, а так же подключение к TS Web Access через IE было успешным. Как выяснилось на днях, причина была в том, что в новом RDC был изменён алгоритм certificate chaining engine и новая версия RDC больше не доверяла корневым сертификатам в пользовательском хранилище. Переустановка корневого сертификата в компьютерное хранилище решала проблему RDC 7. Но, как я говорил, в Windows 7/2008 R2 было изменено поведение certificate chaining engine в реализации X509Chain. Продемонстрирую небольшую табличку, которая покажет доверие пользовательским корневым сертификатам в CAPICOM и .NET реализациях certificate chaining engine для различных операционных систем:

	X509Chain (.NET)	CAPICOM.Chain (CryptoAPI)
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2

Таблица доверия пользовательскким корневым сертификатам различными движками построения цепочки сертификатов

Следует учитывать, что различные приложения могут использовать свой движок для построения цепочек сертификатов, как RDC 7.0 и PKIView.msc использует CAPICOM, а PowerShell — X509Chain. Однако, у меня есть уверенность, что существует ещё одна реализация этого движка, которую использует Internet Explorer. Это только мои догадки, но они основаны на том, что Internet Explorer (кроме Windows 7 и выше) использует пользовательский контейнер для проверки SSL веб-сайтов, т.е. по симптомам похоже на X509Chain. Однако, этот класс появился только в .Net Framework 2.0, которого, к примеру в оригинальной инсталляции Windows XP/2003 не было. Либо, как вариант, есть возможность настраивать этот момент в каждой реализации движка построения цепочек, но я пока не нашёл как. Это пока всё, что у меня есть по этому поводу.

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell

Camelot — Sat, 17 Oct 2009 20:51:59 GMT

Я предлагаю снова поговорить о certificate chaining engine, о котором мы уже говорили в посте Certificate Chaining Engine — как это работает но в рамках его реализации в .NET и PowerShell. В Windows есть несколько реализаций этого chaining engine. Самые популярные:

CAPICOM — вещь несколько стрёмная и её лучше избегать. Тем более мне не удалось завести его в Vista/Windows 7. Реализация в .NET в виде X509Chain ничуть не хуже, но, в то же время, проще. Итак, предлагаю начать с создания этого объекта с помощью New-Object:

[↓] [vPodans] $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
[↓] [vPodans] $chain

                 ChainContext ChainPolicy                   ChainStatus                   ChainElements
                 ------------ -----------                   -----------                   -------------
                            0 System.Security.Cryptograp... {}                            {}


[↓] [vPodans] $chain | gm -membertype methods


   TypeName: System.Security.Cryptography.X509Certificates.X509Chain

Name        MemberType Definition
----        ---------- ----------
Build       Method     bool Build(System.Security.Cryptography.X509Certificates.X509Certificate2 certificate)
Equals      Method     bool Equals(System.Object obj)
GetHashCode Method     int GetHashCode()
GetType     Method     type GetType()
Reset       Method     System.Void Reset()
ToString    Method     string ToString()


[↓] [vPodans]

Здесь видно, что метод, который будет строить и проверять цепочку будет называться Build() и в качестве аргумента этот метод принимает только объекты x509Certificate2, а возвращать объект типа Boolean — True/False. Объекты такого типа можно найти в провайдере Certififcates (просто выполнить dir cert:\store\container) или импортировать из файла — Импорт сертификатов в PowerShell. Но сначала мы посмотрим, что здесь можнол настроить. А настроить можно ChainPolicy, представляющий собой объект X509ChainPolicy. Эта политика позволяет задавать порядок проверки отзыва сертификатов, соответствие сертификата каким-то certificate policy, наличие определённых application policy (в прошлом известен нам как EKU — Extended Key Usage) и некритичность каких-то ошибок. Мы всё разбирать не будем, а только основное:

[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

Первое, что может быть интересным — Revocation Mode, который задаёт режим проверки отзыва и может иметь 3 вполне понятных значения, которые перечислены в X509RevocationMode:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationmode])
NoCheck
Online
Offline

Тут очень просто:

NoCheck — проверяет цепочку сертификатов без проверки на отзыв любых сертификатов в цепочке;
Online — проверяет сертификаты в цепочке скачивая новые списки CRL из свойства CDP сертификата, игнорируя локальный кеш CRL (используется по умолчанию, как это видно в просмотре свойств ChainPolicy)
Offline — проверяет сертификаты на отзыв с использованием кешированного CRL (если есть).

Если проверяем сертификаты на отзыв, то мы можем выбрать что именно будем проверять и этот выбор перечислен в X509RevocationFlag:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationflag])
EndCertificateOnly
EntireChain
ExcludeRoot

и здесь тоже всё достаточно понятно:

EndCertificateOnly — проверяет на отзыв только сам проверяемый сертификат. Остальные сертификаты в цепочке не проверяются;
EntireChain — проверяет на отзыв абсолютно все сертификаты в цепочке включая корневой сертификат. Правила хорошего тона диктуют нам не включать в корневой сертификат CA поля CDP и AIA, поскольку это лишено смысла и в большинстве случаев с этим флагом вы будете получать невалидную цепочку;
ExcludeRoot — проверяет на отзыв все сертификаты в цепочке, кроме корневого сертификата, что есть религионзно правильно и этот флаг установлен по умолчанию.

Следующий момент определяет флаги проверки, т.е. по каким именно критериям будет проверяться цепочка сертификатов:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509verificationflags])
NoFlag
IgnoreNotTimeValid
IgnoreCtlNotTimeValid
IgnoreNotTimeNested
IgnoreInvalidBasicConstraints
AllowUnknownCertificateAuthority
IgnoreWrongUsage
IgnoreInvalidName
IgnoreInvalidPolicy
IgnoreEndRevocationUnknown
IgnoreCtlSignerRevocationUnknown
IgnoreCertificateAuthorityRevocationUnknown
IgnoreRootRevocationUnknown
AllFlags

Эти флаги так же достаточно понятны и подробно разжёваны в перечислении X509VerificationFlags.

Примечание: эти флаги показывают что будет исключено из проверки, а не наоборот. По умолчанию проверяется всё (установлен NoFlag).

Как можно задавать эти флаги и режимы, если есть такая потребность? Можно пойти двумя способами — правильным и неправильным, хотя оба рабочие:

[↓] [vPodans] # правильный метод:
[↓] [vPodans] $revflag = [System.Security.Cryptography.X509Certificates.X509RevocationFlag]::EndCertificateOnly
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = $revflag
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : EndCertificateOnly
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans] # неправильный метод, но мне он нравится
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = "excluderoot"
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

В принципе, все эти enumeration можно просто указывать в виде строки, а PowerShell уже сам подобъёт его под нужный тип.

Примечание: флаги проверки на отзыв можно указывать только по одному, а флаги исключений можно перечислять через запятую. Это видно по названию класса: если класс указан в единственном числе (X509RevocationFlag), то и значение можно указать только одно, а если во множественном числе (X509VerificationFlags), то их можно указать несколько через запятую.

В принципе, можно делать проверку:

[↓] [vPodans] $valid = (dir cert:\currentuser\my)[1]
[↓] [vPodans] $invalid = (dir cert:\currentuser\my)[0]
[↓] [vPodans] $chain.Build($valid)
True
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
E82ACC45841280DDEAB9F7847418FA26354457A7  CN=sysadmins-LV-CA, DC=sysadmins, DC=lv


[↓] [vPodans]

Я из локального хранилища взял заведомо хороший сертификат и плохой (разумеется, это сертификат с сайта БиЛайн ). Метод Build() вернул True, что означает успешную проверку всей цепочки моего сертификата до доверенного корня. А вот что случилось с сертификатом билайна:

[↓] [vPodans] $chain.reset()
[↓] [vPodans] $chain.Build($invalid)
False
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
EB74DA32E865C78FCB853DDA5FE45962098E1B3B  CN=trust.beeline.ru, OU=DIT, O=Vimpelcom, L=Moscow, S=Moscow, C=RU


[↓] [vPodans] $chain.ChainStatus

                                                     Status StatusInformation
                                                     ------ -----------------
                                               PartialChain Sertificesanas kedi nevareja veidot pie uzticamas saknes...
                                    RevocationStatusUnknown Atsauksanas funkcija nevareja parbaudit sertifikata atsa...
                                          OfflineRevocation Atsauksanas funkcija nevareja parbaudit atsauksanu, jo a...


[↓] [vPodans] $chain.ChainStatus | %{$_.statusinformation.trim()}
Sertificesanas kedi nevareja veidot pie uzticamas saknes iestades.
Atsauksanas funkcija nevareja parbaudit sertifikata atsauksanu.
Atsauksanas funkcija nevareja parbaudit atsauksanu, jo atsauksanas serveris bija bezsaiste.
[↓] [vPodans]

Поскольку при каждой проверке сертификаты в ChainElements накапливаются, то после каждой проверки следует очищать объект методом Reset(). Как и следовало ожидать, сертификат билайна вернул False, показывая, что цепочка у этого сертификата имеет проблемы. В случае неуспешной проверки, будет заполняться свойство ChainStatus. Данное свойство содержит все ошибки, которые были костатированы при проверке цепочки. Для меня пока непонятным стал факт, что ошибки он написал на латышском языке, хотя я его об этом не просил. Откуда он это взял — непонятно, но он сказал, что не смог построить цепочку до доверенного корня и функция проверки отзыва провалилась по всем статьям, поскольку пути в CDP сертификата нерабочие.

Примечание: обязательно следует учитывать тот факт, что при построении цепочки сертификатов и проверке доверия класс X509Chain в Windows 7 и Windows Server 2008 R2 работает в контексте LocalSystem и всегда игнорирует пользовательские контейнеры Trusted Root Certification Authorities. Поэтому если корень цепочки не заканчивается на одном из сертификатов Trusted Root CAs хранилища LocalMachine, то цепочка будет считаться недоверенной. Для предыдущих ОС цепочка может заканчиваться на пользовательском хранилище Current User.

В принципе это всё, что вам следует знать про реализацию certificate chaining engine в .NET и его использование в PowerShell. В качестве бонуса прилагаю скрипт для проверки цепочки сертификатов:

#####################################################################
# Test-Certificate.ps1
# Version 1.0
#
# Passes certificate through certificate chaining engine
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires –Version 2.0

function Test-Certificate {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        $Certificate,
        [System.Security.SecureString]$Password,
        [ValidateSet("NoCheck", "Online", "Offline")]
        [string]$CRLMode = "Online",
        [ValidateSet("EndCertificateOnly", "EntireChain", "ExcludeRoot")]
        [string]$CRLFlag = "ExcludeRoot",
        [ValidateSet("AllFlags", "AllowUnknownCertificateAuthority", "NoFlag", "IgnoreNotTimeValid",
            "IgnoreCtlNotTimeValid", "IgnoreNotTimeNested", "IgnoreInvalidBasicConstraints",
            "IgnoreWrongUsage", "IgnoreInvalidName", "IgnoreInvalidPolicy", "IgnoreEndRevocationUnknown",
            "IgnoreCtlSignerRevocationUnknown", "IgnoreCertificateAuthorityRevocationUnknown",
            "IgnoreRootRevocationUnknown")]
        [string[]]$VerificationFlags = "NoFlag"
    )
    
    begin {
        # создаём объекты X509Certificate2 и X509chain ещё до поступлениея первого объекта сертификата
        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
        $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
        # в X509Chain записываем параметры проверки сертификатов. Как критерии
        # отзыва, так и исключения из проверки
        $chain.ChainPolicy.RevocationFlag = $CRLFlag
        $chain.ChainPolicy.RevocationMode = $CRLMode
        $chain.ChainPolicy.VerificationFlags = $VerificationFlags
        # мини-функция для предоставления понятного вывода на экран о статусе проверки
        # и ошибках в цепочке, если они есть.
        function _getstatus_ ($status, $chain, $cert) {
            if ($status) {
                Write-Host Current certificate $cert.SerialNumber chain and revocation status is valid -ForegroundColor Green
            } else {
                Write-Warning "Current certificate $($cert.SerialNumber) chain is invalid due of the following errors:"
                $chain.ChainStatus | %{Write-Host $_.StatusInformation.trim() -ForegroundColor Red}
            }
        }
    }
    
    process {
        # если аргумент сертификата уже является объектом X509Certificate2, то
        # сразу строим цепочку и получаем статус цепочки вызывая мини-функцию
        if ($_ -is [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            $status = $chain.Build($_)
            _getstatus_ $status $chain $_
        } else {
        # если аргумент не является объектом X509Certificate2, то это будет путь к файлу
        # если указанный путь не существует, то ругаемся и выходим
            if (!(Test-Path $Certificate)) {Write-Warning "Specified path is invalid"; return}
            else {
            # если путь существует, то проверяем, что это путь файловой системы.
            # если это не так, то ругаемся и выходим
                if ((Resolve-Path $Certificate).Provider.Name -ne "FileSystem") {
                    Write-Warning "Spicifed path is not recognized as filesystem path. Try again"; return
                } else {
                # если предварительные проверки прошли успешно, то выбираем объект файла
                    $Certificate = gi $(Resolve-Path $Certificate)
                # и на основании расширения файла через Switch преобразуем файл в
                # X509Certificate2 объект или объекты
                    switch -regex ($Certificate.Extension) {
                    "\.CER|\.DER|\.CRT" {$cert.Import($Certificate.FullName)}
                    "\.PFX" {
                        if (!$Password) {$Password = Read-Host "Enter password for PFX file $certificate" -AsSecureString}
                        # тут пришлось указать контекст хранилища, куда предполагается сохранить сертификат.
                        # на самом деле мы никуда не будем сохранять объект сертификата, это было сделано
                        # по причине отсутствия подходящего конструктора метода Import(), чтобы
                        # можно было указать только путь к файлу и пароль от PFX
                            $cert.Import($Certificate.FullName, $password, "UserKeySet")
                        }
                    "\.P7B|\.SST" {
                        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
                        $cert.Import([system.IO.File]::ReadAllBytes($file.FullName))
                        }
                    default {Write-Warning "Looks like your specified file is not a certificate file"; return}
                    }
                    # полученный объект или объекты сертификатов пропускаем через метод Build() и вызываем
                    # мини-функцию расшифровки статуса проверки
                    $cert | %{
                        $status = $chain.Build($_)
                        _getstatus_ $status $chain $_
                    }
                    # после каждой итерации очищаем объекты сертификата и цепочки
                    $cert.Reset()
                    $chain.Reset()
                }
            }
        }
    }
}

Данный скрипт может принимать аргументы в виде уже готовых объектов X509Certificate2 или с указанием пути к файлу сертификата, например:

dir cert:\currentuser\my | Test-Certificate
Test-Certificate .\mycert.cer

Ну и при желании можно поуказывать там разные параметры и флаги проверки.

PowerShell Powered - http://www.sysadmins.lv

Certificate management pack

Camelot — Mon, 14 Sep 2009 19:02:32 GMT

Представлю на обозрение пробный скрипт по управлению сертификатами в хранилище Certificate Store — CertMgmtPack.ps1, который (как я надеюсь) может найти применение на серверах Windows Server 2008 R2 Server Core и реализован на основе наших недавних исследований:

Версия пока что 0.47 (т.к. предстоит добавить ещё разного функционала и допилить существующий). Пока что мне удалось реализовать функционал импорта сертификатов из файлов в store и экспорт из store в файлы сертификатов.

1 PS1 file
15,8 KB CertMgmtPack.ps1

Примечание: скрипт работает только в PowerShell V2. В каждую функцию вложена справка, которую вы можете прочитать набрав Get-Help Import/Export-Certiifcate.

После подключения скрипта (используя dot-sourcing) у вас будут доступны 2 функции:

Export-Certificate
Import-Certificate

И пару слов о том, как их использовать.

Import-Certificate

содержит следующие параметры:

Path <String> — путь к файлу сертификата, который может иметь следующий набор расширений: CER, DER, PFX, P7B, SST. Распознавание типов сертификатов осуществляется по расширению файла. Данная функция может принимать параметр пути из конвейера следующим путём:
```
dir *.cer | Import-Certificate
```
Параметр обязательный.

Password <SecureString> — пароль для PFX файла. Пароль не требуется для остальных типов файлов. Однако, хочу предупредить, что пароли не принимаются в открытом виде, а должны передаватьсякак SecureString. Это можно реализовать различными способами, например, вот так:
```
Read-Host "Enter password for PFX file" –AsSecureString
```

Storage <String> — указывает контекст импорта сертификата, т.е. это будет хранилище текущего пользователя (по умолчанию) или в хранилище компьютера (требуются права локального администратора). Может принимать значения User или Computer. Если параметр не указан, то берётся значение по умолчанию — User.
Container <String> — указывает контейнер размещения сертификата. Это может быть один из: AuthRoot, CA, Disallowed, My (по умолчанию), REQUEST, Root, SmartCardRoot, Trust, TrustedPeople, TrustedPublisher, UserDS. Расшифровка контейнеров (сопоставление названиям в оснастке CertMgr.msc) приведена внутри скрипта в хелпе функции. Если параметр не указан, то применяется параметр по умолчанию — My.
Exportable <Switch> — применяется только для импорта PFX файлов. Данный ключ помечает импортируемый сертификат как экспортируемый. Это означает, что вы после процедуры импорта сможете снова экспортировать сертификат с закрытым ключом. Эсли ключ Exportable не указан, то закрытый ключ сертификата не помечается как экспортируемый и при экспорте у вас не будет возможности экспортировать закрытый ключ данного сертификата.
StrongProtection <Switch> — применяется только для импорта PFX файлов. Данный ключ включает режим усиленной защиты закрытого ключа PFX файла. Это означает, что для каждой попытки использования закрытого ключа от этого сертификата потребуется ручной ввод пароля. Данный ключ нельзя использовать, если Storage указан как Computer, поскольку компьютерные сертификаты не поддерживают такой режим. Это связано с тем, что компьютерные сертификаты используются в контексте учётной записи LocalSystem и lsass.exe не предоставляет пользователю UI для ввода пароля. В любом случае, если вы попробуете это сделать, скрипт выдаст соответствующую ошибку и импорт произведён не будет.

И пару примеров, как использовать функцию:

$pass = Read-Host "Enter password for PFX" –AsSecureString
Import-Certificate mycert.pfx -Password $pass -Exportable

импортирует файл mycert.pfx в контейнер Personal хранилища текущего пользователя и пометит ключ как экспортируемый.

Import-Certificate mycert.pfx -Password $pass -StrongProtection

Импортирует файл mycert.pfx в контейнер Personal хранилища текущего пользователя, пометит ключ как неэкспортируемый и включит режим усиленной защиты закрытого ключа, что потребует ввод пароля пользователя каждый раз при его использовании.

Import-Certificate certs.p7b –Storage 'Computer' –Container 'TrustedPublisher'

Импортирует все сертификаты из файла certs.p7b в контейнер Trusted Publishers компьютерного хранилища.

Экспорт сертификатов

Path <String> — указывает путь к папке (не к файлу!), в которую будут экспортированы все указанные сертификаты. Парамер обязателен.
Type <String> — указывает тип экспортируемых сертификатов. Может принимать одно из значений: CERT, PFX, PKCS12, PKCS7, SST (Serialized Store). Параметр так же обязателен.
Password <SecureString> — задаёт пароль для экспортируемых PFX файлов (в качестве типа экспортируемых сертификатов указано PFX или PKCS12 и является для них обязательным). Параметр не принимает значение в виде простой строки, а только SecureString.
Storage <String> — указывает контекст поиска экспортируемых сертификатов, т.е. поиск будет производиться в компьютерном хранилище или хранилище текущего пользователя (по умолчанию). Может принимать значения CurrentUser или LocalMachine. Если параметр не указан, то берётся значение по умолчанию — User.
Container <String> — указывает контейнер размещения сертификата (или сертификатов). Это может быть один из: AuthRoot, CA, Disallowed, My (по умолчанию), REQUEST, Root, SmartCardRoot, Trust, TrustedPeople, TrustedPublisher, UserDS. Расшифровка контейнеров (сопоставление названиям в оснастке CertMgr.msc) приведена внутри скрипта в хелпе функции. Если параметр не указан, то поиск производится в контейнере по умолчанию — My.
Thumbprint <String> — задаёт критерий поиска сертификатов по отпечатку ключа (соответствующее поле Thumbprint сертификата). Можно указывать как полный отпечаток, так и любую его часть.
Subject <String> — задаёт критерий поиска сертификатов по полю Subject. Можно указывать как полный Subject, так и любую его часть.
Issuer <String> — задаёт критерий поиска по конкретному издателю сертификата. Можно указывать как полный CN издателя, так и любую его часть.
SerialNumber <String> — задаёт критерий поиска по серийному номеру сертификата. Можно указывать как точный серийный номер, так и любую его часть.
NotAfter <String> — задаёт критерий поиска по дате истечения сертификата. Дата задаётся в формате dd.MM.yyyy (день.месяц.год). В результате использования этого параметра будут отобраны сертификаты, которые истекут не позднее указанной даты.
NotBefore <String> — задаёт критерий поиска по дате начала действия сертификате. Как и в NotAfter дата указывается в формате dd.MM.yyyy и в результате использования этого параметра будут отобраны сертификаты, действие которых начинается не раньше указанной даты.
DeleteKey <Swtich> — используется только при экспорте сертификатов вместе с закрытыми ключами в PFX файлы. Данный ключ при успешном экспорте удаляет закрытый ключ данного сертификата из хранилища.

Я не смог провести полноценное тестирование функции экспорта, поэтому гарантировать 100% работу пока не могу. Но вы, уважаемые читатели, можете мне в этом помочь.

И несколько примеров использования:

Export-Certificate c:\certs -Type 'PKCS7'

Экспортирует все сертификаты из Current User\Personal в один PKCS7 файл с именем ExportedCertificates.p7b (это имя зашито на уровне скрипта).

Export-Certificate c:\certs -Type 'cert' -Storage 'LocalMachine' -Container 'Root' -SerialNumber '663'

Экспортирует все сертификаты из контейнера доверенных центров сертификации (Trusted Root CAs) компьютерного хранилища, у которых в серийном номере встречается последовательность 663 в CER файлы. При этом каждый сертификат будет экспортирован в индивидуальный файл с именем, которое строится по схеме: SubjectCN_Thumprint.CER, например: Thawte Premium Server CA_4F65566336DB6598581D584A596C87934D5F2AB4.cer

Export-Certificate c:\certs -Type 'PKCS12' -Password $pass -DeleteKey -Subject 'UserName'

Экспортирует все сертификаты из Current User\Personal в PFX файлы у которых в любом месте поля Subject есть UserName. При успешном экспорте закрытый ключ сертификата будет удалён из хранилища и будет содержаться только в PFX файле.

В связи с тем, что CN поля Subject может содержать недопустимые символы для имён файлов, мне скорее всего придётся искать другой метод именования экспортируемых сертификатов и чтобы они были распознаваемые. Если вы обнаружите какие-то ошибки или будут пожелания, то пишите мне в коментарии или на почту. По мере дописывания я буду выкладывать новые версии скрипта.

PowerShell Powered - http://www.sysadmins.lv

Экспорт PFX с удалением ключа из хранилища в PowerShell

Camelot — Thu, 10 Sep 2009 19:07:54 GMT

Короткая заметка. Когда вы экспортируете сертификат вместе с закрытым ключом, то можете заметить такую опцию:

К сожалению, метод Export() у объектов X509Certificate2 не позволяет штатно проделывать данную операцию. Это можно сделать через CAPICOM.PrivateKey.Delete(), но данная возможность отсутствует в PowerShell, в то время, как вы можете это сделать в VBS. Это связано с весьма паршивой поддержкой COM со стороны PowerShell, поэтому для реализации функционала этой галочки вам придётся проделать следующие шаги:

Получить объект X509Certificate2 самого сертификата;
Экспортировать его в PFX;
Открыть хранилище в режиме ReadWrite;
Удалить данный сертификат из хранилища;
Экспортировать объект сертификата уже не в PFX, а в Cert;
Импортировать этот экспортированный объект Cert (хотя, на самом деле там будет массив байтов, но это не столь существенно).

На языке PowerShell это выглядеть будет примерно так:

# получаем объект сертификата с закрытым ключом
$cert = (dir cert:\currentuser\my)[0]
# записываем пароль для PFX файла
$pass = Read-Host "Password" -AsSecureString
# экспортируем его в PFX формат
$bytes = $cert.Export("pfx", $pass)
# и записывем его в файл
[System.IO.File]::WriteAllBytes('mycert.pfx', $bytes)
# снова экспортируем данный объект, но уже в Cert формат
$tempcert = $cert.Export("Cert")
# создаём объект нашего хранилища
$store = New-Object system.security.cryptography.X509Certificates.X509Store "my", "CurrentUser"
# открываем его на чтение и на запись
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
# удаляем текущий сертификат с закрытым ключом из хранилища
$store.Remove($cert)
# записываем обратно Cert объект в хранилище, теперь уже без закрытого ключа
$store.Add($tempcert)
$store.Close()

Это только образец кода и его не стоит использовать прямо в таком виде, т.к. вы должны точно убедиться, что у вас PFX файл создался и он валидный. В противном случае вы останетесь совсем без закрытого ключа. И ещё раз напоминаю, при работе с хранилищем – не забывайте его закрывать после работы.

PowerShell Powered - http://www.sysadmins.lv

Импорт сертификатов в PowerShell

Camelot — Wed, 09 Sep 2009 19:20:18 GMT

В предыдущих статьях мы с вами уже изучили методы экспорта сертификатов из хранилища Certificate Store в файл:

а так же рассмотрели сопутствующие вопросы. Теперь же предлагаю рассмотреть обратную операцию – добавление сертификатов в cert store из файлов. Этот процесс будет несколько легче, чем экспорт, поэтому я в одном посте покажу импорт всех типов сертификатов (они все используют одну схему).

Для импорта нам потребуется метод x509Certificate.Import(), который так же как и метод Export() имеет несколько конструкторов. Мы можем выбрать один универсальный, который подойдёт нам для всех типов файлов сертификатов и это будет конструктор: X509Certificate2.Import Method (String, SecureString, X509KeyStorageFlags). В качестве аргументов он принимает следующее:

String – путь к файлу сертификата
SecureString – строка с паролем. Требуется только для импорта PFX сертификатов, т.к. остальные типы файлов не содержат закрытых ключей и защищать их паролем нет смысла. Если это не PFX, то значение этого аргумента просто выставляется в $null.
объект типа X509KeyStorageFlags, который описывает область хранения сертификатов.

Давайте немного разберёмся с флагами последнего аргумента:

DefaultKeySet – указывает, что сертификат предназначен для импорта в контейнер Personal хранилища CurrentUser (дефолт).
Exportable – используется только для PFX файлов и говорит, будет ли возможность экспортировать сертификат с закрытым ключом. Если мы этот флаг не указываем, то после импорта не будет возможности снова экспортировать в PFX файл.
MachineKeySet – указывает, что сертификат будет установлен в хранилище компьютера (LocalSystem).
PersistKeySet – используется только для PFX и сохраняет пароль от PFX файла в сертификате. Данный пароль будет использован при дальнейшем экспорте в PFX файл (будет работать только с флагом Exportable).
UserKeySet – указывает, что сертификат будет установлен в пользовательское хранилище.
UserProtected – используется только для PFX файлов и для пользовательских сертификатов. Этот флаг включает Private Key Strong Protection, который при каждом использовании закрытого ключа будет требовать ввода пароля.

Примечание: вы никогда не должны использовать флаг UserProtected для компьютерных сертификатов, поскольку они используются в контексте LocalSystem и у вас просто не будет возможности ввести пароль для использования этого закрытого ключа.

Т.к. X509KeyStorageFlags на самом деле является перечислителем (enumerator), то создавать его объект не обязательно и флаги можно просто использовать как строки. PowerShell уже сам подобъёт эти флаги к нужному типу данных.

т.к. у нас ещё нет готового объекта сертификатов, то мы его просто создаём:

$certs = New-Object system.security.cryptography.x509certificates.x509certificate2

И в этом объекте у нас будет метод Import(), которым мы уже воспользуемся:

$path = "mycert.pfx"
$password = Read-Host "Type password for PFX certificate" -AsSecureString
$flags = "UserKeySet, Exportable"
$certs.Import($path, $password, $flags)

Обратите внимание, что вы за один раз можете указать несколько флагов для KeyStorage, просто перечислив их через запятую. Теперь $certs у нас содержит x509Certificate2 объект нашего сертификата:

[↓] [vPodans] $certs = New-Object system.security.cryptography.x509certificates.x509certificate2
[↓] [vPodans] $path = "mycert.pfx"
[↓] [vPodans] $password = Read-Host "Type password for PFX certificate" -AsSecureString
Type password for PFX certificate: *
[↓] [vPodans] $flags = "UserKeySet, Exportable"
[↓] [vPodans] $certs.Import($path, $password, $flags)
[↓] [vPodans] $certs

Thumbprint                                Subject
----------                                -------
0F5157A8342C66493E7B1354530DD7A9F980BC69  CN=vPodans


[↓] [vPodans]

как видите, у нас всё случилось, PFX файл был успешно прочитан и помещён в объект x509Certificate2. Но это только половина дела, поскольку этот сертификат пока существует только самом в объекте, но не в хранилище. Для того, чтобы записать объект в хранилище мы должны поработать с хранилищем. За него отвечает класс X509Store. Мы создадим этот объект с нуля и укажем какой именно контейнер в каком хранилище открывать. Для этого мы воспользуемся следующим конструктором: X509Store Constructor (StoreName, StoreLocation). Здесь я подробно останавливаться не буду, поскольку названия хранилищ и контейнеров мы уже рассматривали в одном из предыдущих постов: Простой экспорт сертификатов в PowerShell, в этом посте все контейнеры показаны в первом снимке консоли. В нашем случае StoreName будет My (Personal), а Store Location будет CurrentUser (контекст текущего пользователя):

$store = New-Object system.security.cryptography.X509Certificates.X509Store "My", "CurrentUser"

Создали мы объект хранилища, теперь нам надо его открыть в режиме ReadWrite:

$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)

Этот флаг открытия хранилища указывать надо обязательно, иначе у вас просто не будет к нему доступа. Теперь когда хранилище открыто, можно методом Add(), который в качестве аргумента принимает только x509Certificate2 объекты (он у нас уже есть в переменной $certs):

$store.Add($certs)
$store.Close()

Примечание: MSDN настоятельно рекомендует закрывать хранилище после того, как вы провели с ним необходимые операции.

Вот и всё, собственно, у нас теперь PFX файл был успешно импортирован в хранилище.

Когда вы импортируете сертификаты из p7b (PKCS#7) файла, то в нём может быть несколько сертификатов, поэтому здесь поменяется всего 2 строчки. Поскольку у нас в одном файле может быть несколько сертификатов, то для их чтения из файла будем использовать не x509Certificate2 объект, а специальный массив таких объектов – x509Certificate2Collection, о котором мы уже говорили в предыдущем посте:

$bytes = [System.IO.File]::ReadAllBytes($path)
$certs = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$certs.Import($bytes)

Мы сначала прочитали байтовый массив из файла и засунули его в коллекцию x509Certificate2 объектов. Т.к. сертификатов там несколько, а метод Add() у x509Store за раз может взять только один объект – воспользуемся циклом:

$certs | %{$store.Add($_)}

А в остальном схема импорта p7b файлов будет такая же. Вот и всё, что я хотел рассказать по импорту сертификатов из файлов в хранилище. В принципе, используя эти знания вы уже можете затачивать код под свои нужды, тем более я везде, где это было необходимо, указывал ссылки на MSDN, где вы можете узнать более подробно этот материал. Но чтобы сделать жизнь чуточку проще, я постараюсь написать несколько полезных функций для управлениями сертификатами в PowerShell, что будет весьма актуально для Windows Server 2008 R2 Server Core.

Спасибо за внимание

PowerShell Powered - http://www.sysadmins.lv

Сложный экспорт сертификатов в PowerShell

Camelot — Mon, 07 Sep 2009 20:28:36 GMT

Продолжая тему экспорта сертификатов поговорим о более сложных вещах, чем простой экспорт сертификата из хранилища в CER/DER файл. На сей раз расскажу про экспорт сертификатов из хранилища в PFX (Personal Information Exchange Syntax Standard) и PKCS#7 (Cryptographic Message Syntax Standard) формат. Будет немного треша, но в пределах разумного.

Для экспорта сертификата в PFX нам потребуется выполнить половину кода из предыдущей статьи: Простой экспорт сертификатов в PowerShell.

Сначала выберем объект сертификат из хранилища:

$cert = (dir cert:\currentuser)[4]

Как вы помните, если экспортировать сертификат в PFX нам нужно указывать пароль:

Следовательно, конструктор метода Export(X509ContentType), который мы использовали нам уже не подойдёт, поскольку в этот конструктор нельзя вложить пароль. Мы можем воспользоваться одним из оставшихся конструкторов:

SecureString/String представляют собой аргумент для пароля. Я бы не советовал использовать простую строку для хранения пароля, а SecureString. Для этого мы сделаем такую строчку:

$password = Read-Host "Password" –AsSecureString

А теперь по аналогии с примером из предыдущего поста укажем тип сертификата как PFX и применим наш метод Export(X509ContentType, SecureString):

$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx
$bytes = $cert.Export($type, $password)

У нас снова получится массив байтов, т.к. этот метод возвращает только его. Но что с этим бинарным мусором делать? Я сначала по наивности предположил, что его так же запаковать в Base64 и записать в файл. Да, у меня всё вышло хорошо, данные были записаны в файл и Certificate Import Wizard принял его за валидный PFX файл. Но у меня всё обломалось на стадии ввода пароля, т.к. этот визард не хотел его брать. Ввиду отсутствия практики в этих делах, пришлось попросить помощи на одном из бложиков технета, откуда и пришёл ответ, что этот Certificate Import Wizard не декодирует файл обратно из Base64, поэтому для записи в файл нужно писать сразу байты:

[System.IO.File]::WriteAllBytes('certificate.pfx', $bytes)

В качестве первого аргумента указывается путь к файлу и вторым аргументом наш массив. Лично я без подсказки долго бы ещё ломал голову, что сделать с этим массивом, чтобы получить нужный эффект.

Но это всё относительно просто. Когда я задался вопросом “а как экспортировать в PKCS#7?”, то пришлось убить несколько часов на выяснение этого процесса. PKCS#7 удобен тем, что в себе может содержать кучу сертификатов и главным образом используется для хранения цепочки сертификатов (Certificate Chain). Например, особенно наблюдательные пользователи при посещении многих HTTPS сайтов могут заметить, что поле AIA есть только у самих SSL сертификатов, а у промежуточных CA его уже нету. Но этих сертификатов нету и в хранилище сертификатов (Certificate Store). Напрашивается вопрос: а как же система построила эту цепочку сертификатов при отсутствующем AIA в сертификатах? Оказывается, всё очень просто, в RFC2246 есть хороший момент:

certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

Это означает, что веб-сервер может вместе с SSL сертификатом отправлять клиенту и цепочку сертификатов, которая как раз и есть в формате PKCS#7. Если что, это было просто введение к назначению данного типа сертификатов.

Предупреждаю сразу, что методы x509Certificate2.Export Method нам не сгодятся, т.к. в описании метода есть ремарка:

The contentType parameter accepts only the following values of the X509ContentType enumeration: Cert, SerializedCert, and Pkcs12. Passing any other value causes a CryptographicException to be thrown.

Хоть класс System.Security.Cryptography.X509Certificates.X509ContentType и имеет в себе атрибут PKCS7, но метод Export класса x509Certificate2 его просто не принимает. Это был провал! Но делать нечего, пришлось искать. Наткнулся я вот на один замечательный пост: PKCS7 (p7b) bag of certificates and powershell. Но там пример как раз наоборот – как извлечь сертификаты из p7b файла и вывести их в виде x509Certificate2 объектов:

[reflection.assembly]::LoadWithPartialName("System.Security")
$data = [System.IO.File]::ReadAllBytes("certificates.p7b")
$cms = new-object system.security.cryptography.pkcs.signedcms
$cms.Decode($data)
$cms.Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | echo

Автор поста вообще удивительный человек. Просто взял и выложил код без каких-либо комментариев, предполагая, что все знают что делает этот код в деталях. Попробую за него сделать это я. Данный код читает бинарный мусор из файла (обратите внимание, что используется обратная операция экспорта PFX бинарного массива в файл). Далее создаётся объект CMS (Cryptographic Message Syntax). И что мы с него имеем:

[↓] [vPodans] [void][reflection.assembly]::LoadWithPartialName("System.Security")
[↓] [vPodans] $cms = new-object system.security.cryptography.pkcs.signedcms
[↓] [vPodans] $cms


Version      : 0
ContentInfo  : System.Security.Cryptography.Pkcs.ContentInfo
Detached     : False
Certificates : {}
SignerInfos  : {}



[↓] [vPodans] $cms | gm -MemberType methods


   TypeName: System.Security.Cryptography.Pkcs.SignedCms

Name             MemberType Definition
----             ---------- ----------
CheckHash        Method     System.Void CheckHash()
CheckSignature   Method     System.Void CheckSignature(bool verifySignatureOnly), System.Void CheckSignature(System....
ComputeSignature Method     System.Void ComputeSignature(), System.Void ComputeSignature(System.Security.Cryptograph...
Decode           Method     System.Void Decode(byte[] encodedMessage)
Encode           Method     byte[] Encode()
Equals           Method     bool Equals(System.Object obj)
GetHashCode      Method     int GetHashCode()
GetType          Method     type GetType()
RemoveSignature  Method     System.Void RemoveSignature(int index), System.Void RemoveSignature(System.Security.Cryp...
ToString         Method     string ToString()


[↓] [vPodans]

Мы имеем объект с 5 свойствами и различными методами. В коде используется метод Decode() и как видно в описании метода, в качестве аргумента принимается массив байтов, полученный из p7b файла. Этот метод преобразует этот массив обратно в массив объектов x509Certificate2, что видно из последней строки кода. Более-менее тут что-то понятно. Следовательно, для экспорта нам нужно проделать операцию наоборот, создать объект CMS, в свойство Certificates запихать x509Certificate2 объекты сертификатов и применить метод Encode(). Чтобы использовать этот метод у нас в свойстве Certificates должны храниться x509Certificate2 объекты наших сертификатов, которые хотим экспортировать. Но тут меня ждал облом, т.к. свойство Certificates является Read-only и записать туда ничего нельзя. Однако, PowerTab мне показал, что там есть что-то интересное:

[↓] [vPodans] $cms.Certificates.
                                ╔═ $cms.Certificates. ═════════════╗
                                ║ $cms.Certificates.PSBase         ║
                                ║ $cms.Certificates.Add(           ║
                                ║ $cms.Certificates.AddRange(      ║
                                ║ $cms.Certificates.Clear(         ║
                                ║ $cms.Certificates.Contains(      ║
                                ║ $cms.Certificates.CopyTo(        ║
                                ║ $cms.Certificates.Equals(        ║
                                ║ $cms.Certificates.Export(        ║
                                ║ $cms.Certificates.Find(          ║
                                ║ $cms.Certificates.GetEnumerator( ║
                                ║ $cms.Certificates.GetHashCode(   ║
                                ║ $cms.Certificates.GetType(       ║
                                ║ $cms.Certificates.Import(        ║
                                ║ $cms.Certificates.IndexOf(       ║
                                ║ $cms.Certificates.Insert(        ║
                                ║ $cms.Certificates.Remove(        ║
                                ║ $cms.Certificates.RemoveAt(      ║
                                ║ $cms.Certificates.RemoveRange(   ║
                                ║ $cms.Certificates.ToString(      ║
                                ║ $cms.Certificates.Item(          ║
                                ║ $cms.Certificates.Capacity       ║
                                ║ $cms.Certificates.Count          ║
                                ╚═[1] 1-22 (22/22)]════════════════╝

Я испробовал несколько по смыслу похожих методов, как Add, AddRange и Import, но всё неудачно. Сертификаты никак не хотели туда помещаться. После некоторого времени возни я бросил это занятие, как бесполезное, т.к. там ловить нечего:

[↓] [vPodans] $cms.Certificates | gm
Get-Member : No object has been specified to the get-member cmdlet.
At line:1 char:23
+ $cms.Certificates | gm <<<<
    + CategoryInfo          : CloseError: (:) [Get-Member], InvalidOperationException
    + FullyQualifiedErrorId : NoObjectInGetMember,Microsoft.PowerShell.Commands.GetMemberCommand

[↓] [vPodans]

Вобщем, всякие вариации с этим CMS объектов никаких успехов не приносили до тех пор, пока я не посмотрел тип этого свойства Certificates:

[↓] [vPodans] $cms.Certificates.GetType().FullName
System.Security.Cryptography.X509Certificates.X509Certificate2Collection

Я отправился на MSDN читать макулатуру по этому классу (точнее по его членам): X509Certificate2Collection Members. Если вы ещё не забыли, то мы ищем способ разобрать наш x509Certificate2 объект на массив байтов, который бы соответствовал формату PKCS#7. Здесь из годных методов я нашёл метод Add(X509Certificate2). У меня уже есть этот объект, поэтому мы его можем добавить в объект X509Certificate2Collection. Данный класс по сути представляет массив объектов x509Certificate2. Давайте сделаем:

[↓] [vPodans] $cert = (dir cert:\currentuser\my)[4]
[↓] [vPodans] $cert1 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
[↓] [vPodans] $cert1.Add($cert)
0
[↓] [vPodans] $cert1

Thumbprint                                Subject
----------                                -------
0F5157A8342C66493E7B1354530DD7A9F980BC69  CN=vPodans


[↓] [vPodans]

ну хорошо, преобразовали мы x509Certificate2 в X509Certificate2Collection, а что дальше? Нам по прежнему нужен этот дурацкий массив байтов. После этого я посмотрел на метод X509Certificate2Collection Export Method (X509ContentType) нового класса и прочитал ремарки:

This method supports content types that do not require a password.

Вот тут я и сказал “слава ~~сиськам~~Протоколу!”. Данный метод позволяет экспортировать объекты сертификатов в любой тип, который не требует пароля (т.е. всё, кроме PFX/PKCS#12). А дальше уже по отработанной схеме:

[↓] [vPodans] $type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs7
[↓] [vPodans] $bytes = $cert1.Export($type)
[↓] [vPodans] [System.IO.File]::WriteAllBytes('certificate.p7b', $bytes)
[↓] [vPodans]

Вот таким долгим и тяжёлым (для меня, во всяком случае) я смог его победить и научиться экспортировать сертификаты в PKCS#7.

Что нас ждёт дальше? А дальше, возможно, поговорим про SerializedCert и SerializedStore (а может и не будем говорить) и уже импорт сертификатов из файлов в Certificate Store. А на сегодня, пожалуй, хватит.

PowerShell Powered - http://www.sysadmins.lv

Простой экспорт сертификатов в PowerShell

Camelot — Sun, 06 Sep 2009 09:46:46 GMT

С различной периодичностью на ньюсгруппах и англоязычных форумах встречаю вопрос, как экспортировать сертификаты из хранилища (Certificate Store) или сертификаты цифровых подписей файлов в .CER или .DER файл. Сегодня я продемонстрирую простой метод для экспорта этих сертификатов.

На самом деле разница между экспортом сертификата из хранилища сертификатов и подписанного файла заключается только в методе извлечения самого сертификата в x509Certificate2 объект. Давайте начнём с самого простого – экспорт сертификата из хранилища. В PowerShell уже есть свой провайдер для этого хранилища и свой PSDrive:

[↓] [vPodans] dir cert:\


Location   : CurrentUser
StoreNames : {SmartCardRoot, UserDS, AuthRoot, CA...}

Location   : LocalMachine
StoreNames : {SmartCardRoot, AuthRoot, CA, Trust...}



[↓] [vPodans] dir cert:\currentuser


Name : SmartCardRoot

Name : UserDS

Name : AuthRoot

Name : CA

Name : AddressBook

Name : Trust

Name : Disallowed

Name : My

Name : Root

Name : TrustedPeople

Name : TrustedPublisher

Name : REQUEST



[↓] [vPodans] dir cert:\currentuser\my


    Directory: Microsoft.PowerShell.Security\Certificate::currentuser\my


Thumbprint                                Subject
----------                                -------
9C5E4DCEF6598C1298894F62D4BD16E601B8C780  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
4BB89D732920DD91DE66983DDF2CC4EEC272A802  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
14B931DB4790403CCE2A3D03B62638FC7A0D5F34  CN=Administrator, OU=Administrators, DC=sysadmins, DC=lv


[↓] [vPodans]

Если просто посмотреть содержимое Cert:\, то мы увидим там 2 хранилища

CurrentUser – представляет хранилище текущего пользователя, т.е. является аналогом графической консоли CertMgr.msc
LocalMachine – представляет хранилище локального компьютера и является аналогом графической консоли MMC – Certificates, запущенной в контексте LocalComputer.

Внутри уже видны контейнеры, которые мы видим в виде папок в MMC консоли. А дальше уже хранятся наши сертификаты. Эти сертификаты здесь представлены в виде массива x509Certificate2.

[↓] [vPodans] (dir cert:\currentuser\my)[0].gettype().FullName
System.Security.Cryptography.X509Certificates.X509Certificate2
[↓] [vPodans]

Если посмотреть свойства этого объекта через Get-Member, то мы сможем там увидеть метод Export(). Но лучше посмотреть этот метод на MSDN, т.к. он имеет несколько конструкторов: x509Certificate2.Export Method. Из них нас заинтересует только первый конструктор, который Export(X509ContentType). Остальные 2 необходимы для экспорта с паролем (только для PFX). Но, как мы видим из описания метода, нам надо ещё указать x509ContentType объект, который будет указывать нам на тип экспортируемого сертификата. Типы экспортируемых сертификатов можно посмотреть по ссылке: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509contenttype.aspx или в консоли PowerShell:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509contenttype])
Unknown
Cert
SerializedCert
Pfx
Pkcs12
SerializedStore
Pkcs7
Authenticode

Нас сейчас будет интересовать только тип Cert (только открытая часть сертификата).

Теперь мы уже знаем достаточно много, чтобы уже начать писать код. Мы сейчас получим объект сертификата, укажем тип экспортируемого сертификата и выполним метод Export():

$cert = (dir cert:\currentuser\My)[0]
$type = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$ExportedData = $cert.Export($type)

Но это ещё не всё. Посмотрите, что у вас находится в переменной $ExportedData! Там на самом деле огромный массив байтов (в среднем более 2-20 тысяч элементов). Это же и указано в описании метода, что он возвращает. Именно массив байтов. Но что с ним делать? Я сам по-началу думал об этом, пока не вспомнил про одну вещь:

У нас есть выбор, как экспортировать сертификат – в DER или Base64 кодировке. Когда я писал про PsFCIV, то у меня была такая же ситуация. Hasher у меня так же возвращал массив байтов, который мы сразу же загоняли в Base64 кодировку. В нашем случае потребуется то же самое:

$base64Data = [System.Convert]::ToBase64String($ExportedData)

И на выходе мы молучим длинную Base64 строку, которую уже и нужно экспортировать в файл любым удобным для вас методом:

$base64Data > path\file.cer
Set-Content -Path path\file.cer -Value $base64Data

вы можете убедиться в этом просто открыв .CER файл. Чтобы получить объект сертификата из цифровой подписи файла, то мы можем просто воспользоваться командлетом Get-AuthenticodeSignature и выбрать свойство SignerCertificate. Если подпись файла дополнительно подписана сертификатом сервера времени, то вы можете использовать так же и свойство TimeStampCertificate:

[↓] [vPodans] $a.SignerCertificate

Thumbprint                                Subject
----------                                -------
9E95C625D81B2BA9C72FD70275C3699613AF61E3  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...


[↓] [vPodans] $a = Get-AuthenticodeSignature .\Desktop\EASetup.exe
[↓] [vPodans] $a.SignerCertificate

Thumbprint                                Subject
----------                                -------
9E95C625D81B2BA9C72FD70275C3699613AF61E3  CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=W...


[↓] [vPodans] $a.TimeStamperCertificate

Thumbprint                                Subject
----------                                -------
4D6F357F0E6434DA97B1AFC540FB6FDD0E85A89F  CN=Microsoft Time-Stamp Service, OU=nCipher DSE ESN:85D3-305C-5BCF, OU=MOP...


[↓] [vPodans]

В этих свойствах сертификаты уже хранятся в виде объектов x509Certificate2 и дальше их можно экспортировать тем же самым путём, как мы это делали для сертификатов из Certificate Store. Собственно, для извлечения сертификатов из цифровых подписей файлов я написал неплохой скриптик, который добавляет в контекстное меню элемент Export Certificate:

и по нажатию на него цифровая подпись будет экспортирована в MyDocs\FileName.ext.cer, где FileName.ext – оригинальное имя файла и к нему просто пристыковывается расширение CER. В скрипте предусмотрены несколько диалоговых окон о состоянии сертификата:

файл подписан и хеш файла соответствует хешу в цифровой подписи:

файл подписан, но хеш файла не соответствует хешу в цифровой подписи:

файл не содержит цифровых подписей:

В двух последних случаях сертификат не экспортируется никуда по очевидным причинам. И, собственно скрипты-инсталляторы этого контекстного меню с рабочим кодом для:

PowerShell 1.0:

1 PS1 file
8,97 KB ExportCertificate_ps1.0.ps1

PowerShell V2:

1 PS1 file
8,34 KB ExportCertificate_ps2.0.ps1

В следующих статьях я планирую поговорить про импорт сертификатов в Certificate Store, а так же и экспорт сертификатов с закрытыми ключами в PFX файл с использованем Windows PowerShell.

PowerShell Powered - http://www.sysadmins.lv