Цифровая подпись у PowerShell скрипта (файла *.PS1) позволяет при запуске удостовериться, что скрипт подписан доверенным издателем и его код не был изменен. Для подписи кода PowerShell скрипта вам нужно получить сертификат типа Code Signing. Такой сертификат можно:
- Запросить на внутреннем корпоративном центра сертификации (Certificate Authority, CA).
Если у вас развернут PKI на Active Directory Certificate Services, нужно на нем включить шаблон Code Signing, и запросить сертификат по этому шаблону.

- Приобрести у внешнего коммерческого центра сертификации
- Выпустить самоподписанный сертификат
Таким образом, у вас должен файл сертификата с закрытым ключом в формате .PFX (с X509. Импортируйте этот сертификат в локальное хранилище компьютера:
Если вы хотите использовать самоподписанный сертификат, его можно сгенерировать с помощью PowerShell:
$certFile = New-SelfSignedCertificate -Subject "Certificate to sign PowerShell sсripts" -Type CodeSigningCert -DnsName $env:computername -CertStoreLocation cert:\LocalMachine\my
Подписать код PowerShell скрипта с помощью сертификата
Вывести список доступных сертификатов для подписывания кода скриптов PowerShell в указанном хранилище:
Get-ChildItem cert:\LocalMachine\my -CodeSigningCert
Выбрать сертификат можно по его отпечатку:
Чтобы подписать код указанного PowerShell скрипта, выполните:
$PSScript = "C:\PS\HardwareReadiness.ps1"
$TimestampServer = "http://timestamp.verisign.com/scripts/timstamp.dll"
Set-AuthenticodeSignature -FilePath $PSScript -Certificate $signcert -TimestampServer $TimestampServer
Если вы попытаетесь использовать обычный сертификат для подписывания скрипта, появится ошибка:
Set-AuthenticodeSignature : Cannot sign code. The specified certificate is not suitable for code signing.

При подписывании файла PowerShell скрипта, командлет Set-AuthenticodeSignature добавляет в конец текстового файла PS1 блок сигнатуры цифровой подписи, обрамленный специальными метками:
# SIG # Begin signature block ........... ........... # SIG # End signature block
Блок сигнатуры содержит хэш скрипта, который зашифрован с помощью закрытого ключа.

В свойствах PS1 файла на вкладке Digital Signatures появится информация о наличии подписи у скрипта и информация о сертификате.

Запуск подписанных PowerShell скриптов в Windows
По умолчанию настройки политики выполнения PowerShell скриптов в Windows блокируют запуск любых PS1 скриптов (режим Restricted) и при запуске скрипта появится ошибка.
File C:\PS\HardwareReadiness.ps1 cannot be loaded because running scripts is disabled on this system.
Чтобы разрешить запуск только подписанных PowerShell скриптов, нужно изменить настройки политики на AllSigned. Настройки политики выполнения можно изменить:
- Командой:
Set-ExecutionPolicy AllSigned –Force - Через групповые политики: Включить выполнение сценариев (Turn on Script Execution) в разделе GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell. Измените значение параметра на «Разрешать только подписанные сценарии» (Allow only signed scripts).
Проверьте настройки политики выполнения:

Если попробовать запустить сейчас подписанный PowerShell скрипт, появится ошибка:
File C:\PS\HardwareReadiness.ps1 cannot be loaded. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Для запуска подписанного PowerShell скрипта, нужно добавить отпечаток сертификата в корневые доверенные сертификаты. Можно скопировать сертификат из секции Personal в хранилища Trusted Root Certification Authority и Trusted Publisher с помощью графической консоли
Certlm.msc
(скопируйте сертификат из Personal хранилища и вставьте его в корневые).

Теперь подписанный PowerShell скрипт будет запускаться без предупреждений.

Чтобы проверить действительность подписи PowerShell скрипта, выполните команду:
- Статус Valid указывает, что код PowerShell скрипта подписан доверенной цифровой подписью и не был изменен
- Если команда возвращает HashMismatch, значит код скрипта был модифицирован после подписания и сейчас не валиден. Запуск такого скрипта будет заблокирован с ошибкой:
File .ps1 cannot be loaded. The contents of file .ps1 might have been changed by an unauthorized user or process, because the hash of the file does not match the hash stored in the digital signature

Таким образом, после любой модификации кода подписанного PS1 скрипта его нужно заново переподписать. Также скрипт перестанет запускаться после истечения срока действия сертификата, поэтому за этой датой также нужно следить.
Рекомендуется подписывать все PowerShell скрипты, выполняющиеся с повышенными привилегиями администраторов домена или серверов, а также скрипты, которые запускаются на компьютерах пользователей через GPO.
Статья успешно отправлена на почту
Для получения самоподписанного тестового сертификата в системах Windows® 8 и Windows Server® 2012 легче всего воспользоваться Windows PowerShell 3.0.
Установка Windows PowerShell.
Для запуска консоли Windows PowerShell, выполните: Win+R, «PowerShell_ISE.exe», «Выполнить». Запускать консоль необходимо с правами локального администратора.

Далее, в окне консоли Windows PowerShell необходимо выполнить командлет «New-SelfSignedCertificate», для этого вводим команду:
New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:LocalMachineMy
Данная команда запускает командлет, который производит генерацию самоподписанного сертификата для DNS имени localhost, и помещает его в раздел «Личные» локального хранилища сертификатов, иногда по неустановленным причинам сертификат может быть помещен в другой раздел локального хранилища, например «Промежуточные центры сертификации».
При успешном выполнении командлета в окне консоли появится информация, содержащая слепок сгенерированного сертификата.


Далее необходимо открыть оснастку «Сертификаты» с правами локального администратора, для этого запустите соответствующий файл «certmgr.msc» и произведите поиск сгенерированного сертификата по его DNS имени «localhost».

Далее, найденный сертификат необходимо переместить в раздел «Доверенные корневые центры сертификации\Сертификаты».

Если описанный способ не сработал, попробуйте альтернативные способы получения сертификата:
- Как создать самоподписанный сертификат в Windows
- Выпуск собственного SSL-сертификата
Creating Self-Signed SSL in Powershell
Self-signed certificates are useful for:
- Testing and development environments where you need HTTPS enabled but do not require trusted certificates.
- Internal websites, services, and tools where you control the clients.
- Internet of Things (IoT) devices that require HTTPS but can’t get public certificates.
This guide will walk you through the steps to generate a self-signed SSL certificate using Powershell on Windows. We will also cover how to export the certificate and private key to install on servers like IIS and Apache.
Key Takeaways
- Self-signed SSL certificates allow you to encrypt traffic to your websites and web services without needing to purchase a certificate from a certificate authority. However, users will see warnings that the certificate is not trusted since it is self-signed.
- The New-SelfSignedCertificate cmdlet in Powershell can generate self-signed certificates easily. You can specify the subject, DNS names, key usage, extended key usage, and more.
- Export the self-signed certificate and private key to a PFX file for installation on your web server. Protect the private key file.
- You can create a self-signed certificate that is valid for an extended period by specifying a far-off “NotAfter” date. However, some browsers may only trust certificates with a shorter validity period.
- Self-signed certificates provide a quick and easy way to implement HTTPS for internal sites and testing. However, for public production sites, you should purchase an SSL certificate from a trusted certificate authority.
Prerequisites
- Windows 10 or Windows Server with Powershell 5.1 or later. Any edition, including desktop and server.
- Administrator access to run Powershell commands.
- OpenSSL (if exporting certificate and key).
The drawback is that visitors will see certificate warnings as the certificate is not trusted. Public sites should use CA-signed certificates.
Prerequisites Before Installing Self-Signed Certificate in IIS
To create and install a self-signed certificate for a website in IIS, you need:
- IIS (Internet Information Services) installed on the Windows Server
- Administrative access rights to the server
- Access to IIS Manager console
Easy Steps to Create Self-Signed SSL Certificate in PowerShell
- Create Certificate Object in Powershell
- Create an Advanced Self-Signed Certificate
- Export Certificate and Private Key to PFX
- Install Certificate on Web Server
- Trust Certificate
Step 1 – Create Certificate Object in Powershell
Powershell provides an easy way to generate self-signed SSL certificates with the New-SelfSignedCertificate cmdlet.
New-SelfSignedCertificate -DnsName "www.example.com" -CertStoreLocation "Cert:\LocalMachine\My"
This will create a self-signed certificate for the site www.example.com and place it in the My certificate store on the local machine.
Let’s break down what’s happening:
- -DnsName “www.example.com” – Specifies the DNS Subject Alternative Name (SAN). This allows using the cert for that domain.
- -CertStoreLocation “Cert:\LocalMachine\My” – Puts the generated cert into the My store under Local Machine rather than the default CurrentUser.
You can also provide these parameters:
- -NotAfter – The expiration date for the cert as a DateTime object.
- -KeyUsage – The key usage flags like DigitalSignature, KeyEncipherment, etc.
- -Type – The certificate type is typically SSLServerAuthentication.
This generates a basic cert, but we can provide additional options for a more robust self-signed certificate next.
Step 2 – Create an Advanced Self-Signed Certificate
Specify additional parameters, such as subject, key usage, extended key usage, and more, to create a more complete self-signed certificate suitable for production use.
$today = Get-Date
$after = $today.AddYears(10)
$certificate = New-SelfSignedCertificate -DnsName "www.example.com", "example.com" -CertStoreLocation "Cert:\LocalMachine\My" `
-KeySpec "KeyExchange" -KeyUsage "DigitalSignature," "KeyEncipherment" `
-Type "SSLServerAuthentication" -NotAfter $after `
-Subject "CN=www.example.com, OU=IT, O=My Company Name, L=City, S=State, C=Country" `
-Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
-HashAlgorithm "SHA256" -KeyLength 2048
Here’s what each additional parameter does:
- -DnsName – Adds additional DNS names and alternative names. Allows using the cert for multiple domains/subdomains.
- -KeySpec “KeyExchange” – Makes the key usable for key exchange, which is required for SSL/TLS.
- -KeyUsage – Allows the use of certs for digital signatures and key encipherment.
- -Type “SSLServerAuthentication” – Specifies this is an SSL/TLS server certificate.
- -NotAfter – Sets expiration 10 years in the future.
- -Subject – Specifies certificate subject attributes like country, org, etc.
- -Provider – Sets crypto provider; this one support AES.
- -HashAlgorithm “SHA256” – Algorthim to hash and sign the certificate.
- -KeyLength 2048 – Bits in the RSA private key. Higher is more secure.
This creates an advanced certificate with options suitable for production use.
Step 3 – Export Certificate and Private Key to PFX
The self-signed certificate is stored in the local machine personal certificate store. To use it on a web server like IIS or Apache, you need to export the certificate and private key.
The most common format is PFX, which combines the private key and certificate chain into a single encrypted file.
First, copy the cert thumbprint, then export it along with the private key:
$cert = Get-ChildItem -Path "Cert:\LocalMachine\My\" -DnsName "www.example.com"
$thumb = $cert.Thumbprint
Export-PfxCertificate -Cert "Cert:\LocalMachine\My\$thumb" -FilePath "C:\cert\examplecert.pfx" -Password $pwd
This exports the certificate + private key to examplecert.pfx protected with the password stored in $pwd.
Keep this PFX file and password safe! It contains the private key that allows the decryption of all traffic secured with the certificate.
You can now import this PFX file into your web server, such as IIS, Apache, Nginx, etc.
Step 4 – Install Certificate on Web Server
IIS on Windows
- Open the IIS Manager console.
- Select your website.
- In the Actions pane, open Server Certificates.
- Click Import under the Actions panel on the right.
- Import the PFX file and enter the password.
- Select the imported cert under the SSL certificate bindings.
Apache
- Place the PFX file in a secure folder like /etc/ssl.
- Convert the PFX to a PKCS12 file using OpenSSL command.
openssl pkcs12 -in examplecert.pfx -out examplecert.pkcs12
Set the SSL certificate in your virtual host config.
SSLCertificateFile "/etc/ssl/examplecert.pkcs12"
SSLCertificateKeyFile "/etc/ssl/examplecert.pkcs12"
SSLCertificateChainFile "/etc/ssl/examplecert.pkcs12"
Restart Apache to apply the new certificate.
The steps vary slightly for other servers, but in general, you import the PFX file and then configure the webserver to use it.
Step 5 – Trust Certificate (Optional)
On Windows, double-click the CER file and install it under Trusted Root Certificate Authorities.
For public sites, use free or low-cost certificates from CAs like Let’s Encrypt instead for full trust.
Troubleshooting Self-Signed Certificates
Here are some common issues when using self-signed certificates and how to troubleshoot them:
Certificate Warnings in Browser
As covered earlier, self-signed certificates will show warnings in browsers because a trusted certificate authority does not sign them. You will see errors like “NET::ERR_CERT_AUTHORITY_INVALID” in Chrome or “SEC_ERROR_UNKNOWN_ISSUER” in Firefox.
This is expected behavior and can only be resolved by installing the self-signed cert as trusted on client machines, as detailed earlier. Alternatively, you can use a certificate from a public CA.
For local/testing purposes, you can bypass the warnings, but you should never do this for public production websites.
Certificate Name Mismatch
If the name in the self-signed cert does not match the site domain, you will see hostname mismatch errors.
Make sure the -DnsName parameter passed to New-SelfSignedCertificate matches your actual site domain(s).
You can also edit it later using the Set-SelfSignedCertificateDNSName cmdlet if needed.
Invalid Key Usage
Using the certificate for purposes other than what is permitted by the -KeyUsage parameter will result in errors.
For example, if you did not include DigitalSignature usage, the cert cannot be used to sign other certificates or messages.
Make sure to specify the appropriate key usages per the examples earlier when creating the certificate.
Expired Certificate
By default, self-signed certificates are only valid for one year. Once they expire, you must regenerate them.
Use the -NotAfter parameter to explicitly specify a future expiration date further out, like 10 years.
Private Key Permission Issues
If there are permission problems accessing the certificate’s private key, you may see errors when trying to start your web server or access sites.
Final Thoughts
Self-signed SSL certificates provide an easy way to implement HTTPS on your websites and services for local testing or internal usage. The New-SelfSignedCertificate cmdlet in Powershell makes generating certificates straightforward. You can create self-signed SSL certificate in Powershell quickly and easily.
When creating production self-signed certificates, be sure to use an adequate key length and appropriate parameters. Export the certificate and private key to a PFX file and install it on your web server. Keep the private key safe!
While convenient for testing and development, avoid using self-signed certificates on public production websites. Purchase trusted SSL certificates signed by certificate authorities for public sites that need to provide a trusted identity and encrypt traffic securely.
FAQs About Self-Signed SSL Certificate in Powershell
Where does Powershell store generated self-signed certificates?
Can I use a self-signed certificate for a public production website?
What is the benefit of converting to PFX when exporting a self-signed cert?
The PFX format allows exporting the private key used to sign the certificate along with the cert itself. This allows installing the self-signed cert on a web server like IIS or Apache. PFX also optionally encrypts the private key with a password for protection.
Do self-signed certificates expire? How can I generate one that lasts longer?
Yes, self-signed certs have a default expiration of one year. Use the -NotAfter parameter to specify a future expiration date, like 10 years. Just be aware some browsers don’t trust certificates with a validity period longer than 2-3 years.
Can I sign my certificates for my internal corporate network?
Yes, you can use your enterprise root certificate authority to issue and sign certificates for services on your corporate network. Just install the root CA cert as trusted on all company devices. This avoids untrusted errors while keeping the PKI internal.
What are the main risks of using a self-signed certificate?
По умолчанию, все операционные системы семейства Windows автоматически получают и обновляют корневые сертификаты с сайта Microsoft. Компания MSFT в рамках программы корневых сертификатов Microsoft Trusted Root Certificate Program, ведет и публикует в своем онлайн хранилище сертификаты для клиентов и устройств Windows. Если проверяемый сертификат в своей цепочке сертификации относится к корневому CA, который участвует в этой программе, Windows автоматически скачает с узла Microsoft Update и добавит такой корневой сертификат в доверенные на вашем компьютере.
Windows запрашивает обновление списка корневых сертификатов (certificate trust lists — CTL) один раз в неделю. Если в Windows отсутствует прямой доступ к каталогу Windows Update, то система не сможет обновить корневые сертификаты, соответственно у пользователя могут быть проблемы с открытием сайтов (SSL сертификаты которых подписаны недоверенными CA, см. статью об ошибке в Chrome Этот сайт не может обеспечить безопасное соединение), либо с установкой запуском подписанных приложений или скриптов.
В этой статье попробуем разобраться, как в Windows вручную обновить список корневых сертификатов в TrustedRootCA в изолированных сетях, или компьютерах/серверах без прямого подключения к Интернету.
Примечание. Если ваши компьютеры выходят в Интернет через прокси-сервер, для автоматического обновления корневых сертификатов Microsoft рекомендует открыть прямой доступ (bypass) к веб-узлам Microsoft. Но это не всегда возможно/применимо.
Управление корневыми сертификатами в Windows 10 и 11
Как посмотреть список корневых сертификатов на устройстве Windows?
- Чтобы открыть хранилище корневых сертификатов компьютера в Windows /Windows Server, запустите консоль
mmc.exe
; - Нажмите Файл (File) -> Добавить или удалить оснастку (Add/Remove Snap-in), в списке оснасток выберите Сертификаты (Certificates) -> Добавить (Add);
- В диалоговом окне выберите что вы хотите управлять сертификатами учетной записи компьютера (Computer account);

- Далее -> Ok -> Ok;
- Разверните Certificates (Сертификаты) -> Trusted Root Certification Authorities Store (Доверенные корневые сертификаты). В этом списке содержится список доверенных корневых сертификатов вашего компьютера.
Вы можете вывести список доверенных корневых сертификатов на вашем компьютере со сроками их действия с помощью PowerShell:
Можно вывести список истекших сертификатов, или которые истекут в ближайшие 30 дней:

Вы можете вручную перенести файл корневого сертификата с одного компьютера на другой с помощью функцию Экспорта/Импорта.
- Вы можете экспортировать любой сертификат .CER в файл, щелкнув по нему и выбрав “Все задачи” -> “Экспорт”;

- Затем с помощью команды Импорт можно импортировать этот сертификат на другом компьютере.

Включить/отключить автоматическое обновление корневых сертификатов в Windows
Как мы уже упомянули, Windows по умолчанию сама обновляет корневые сертификаты. Вы можете включить или отключить обновление сертификатов в Windows через GPO или реестр.
Параметр Turn off Automatic Root Certificates Update в этом разделе позволяет отключить автоматическое обновление корневых сертификатов через сайт Windows Update. По умолчанию это политика не настроена и Windows всегда пытается автоматически обновлять корневые сертификаты.

Если эта политика не настроена, а сертификаты не обновляются автоматически, проверьте не включен ли вручную параметр реестра, отвечающий за эту настройку. Проверьте значение параметра реестра с помощью PowerShell:
Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\SystemCertificates\AuthRoot' -Name DisableRootAutoUpdate

Если команда вернет, что значение ключа
DisableRootAutoUpdate=1
, значит на вашем компьютере отключено обновление корневых сертификатов. Чтобы включить его, измените значение параметра на 0.
Ручное обновление корневых сертификатов в Windows 10 и 11
Для генерации SST файла, на компьютере Windows 10/11 с доступом в Интернет, выполните с правами администратора команду:
certutil.exe -generateSSTFromWU c:\PS\roots.sst
Updated SST file. CertUtil: -generateSSTFromWU command completed successfully.

В результате в целевом каталоге появится файл SST, содержащий актуальный список сертификатов. Дважды щелкните по нему для открытия. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты.

В указанном каталоге появится файл SST, содержащий актуальный список сертификатов. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты. Дважды щелкните по нему.
В открывшейся
mmc
консоли вы можете экспортировать любой из полученных сертификатов. В моем случае, список сертификатов содержал 436 элементов. Естественно, экспортировать сертификаты и устанавливать по одному не рационально.
Запустите оснастку certmgr.msc и убедитесь, что все сертификаты были добавлены в хранилище Trusted Root Certification Authority. В нашем примере на Windows 11 количество корневых сертификатов увеличилось с 34 до 438.

Чистая копия Windows после установки содержит в корневом хранилище лишь небольшое количество сертификатов. Если компьютер подключен к интернету, остальные корневые сертификаты будут устанавливаться автоматически (по требованию), если ваше устройство попытается получить доступ к HTTPS сайту/SSL сертификату, в чей цепочке доверия есть отпечаток из CTL Microsoft. Поэтому как правило, нет необходимости добавлять в свое локальное хранилище сразу все сертификаты, доверенные Microsoft.
Список корневых сертификатов в формате STL

Файл authroot.stl представляет собой контейнер со списком отпечатков (thumbprint) доверенных сертификатов Microsoft в формате Certification Trust List.

Данный файл можно установить в системе с помощью утилиты certutil:
certutil -enterprise -f -v -AddStore "Root" "C:\PS\authroot.stl"

Root "Trusted Root Certification Authorities" CTL 0 added to store. CertUtil: -addstore command completed successfully.
Также вы можете импортировать сертификаты из консоли управления сертификатами (Trust Root CertificationAuthorities –>Certificates -> All Tasks > Import). Укажите путь к вашему STL файлу сертификатами.

После выполнения команды, в консоли управления сертификатами (
certmgr.msc
) в контейнере Trusted Root Certification Authorities (Доверенные корневые сертификаты) появится новый раздел с именем Certificate Trust List (Список доверия сертификатов).

certutil -enterprise -f -v -AddStore disallowed "C:\PS\disallowedcert.stl "
Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах
Если у вас возникла задача регулярного обновления корневых сертификатов в изолированном от Интернета домене Active Directory, есть несколько более сложная схема обновления локальных хранилищ сертификатов на компьютерах домена с помощью групповых политик. В изолированных сетях Windows вы можете настроить обновление корневых сертификатов на компьютерах пользователей несколькими способами.
Первый способ предполагает, что вы регулярно вручную скачиваете и копируете в вашу изолированную сеть файл с корневыми сертификатами, полученный так:
certutil.exe –generateSSTFromWU roots.sst
Второй способ предполагает получение актуальных корневых сертификатов с помощью команды:
Certutil -syncWithWU -f \\dc01\SYSVOL\winitpro.ru\rootcert\
В указанном сетевом каталоге появится ряд файлов корневых сертификатов (CRT) и в том числе файлы (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

Затем с помощью GPP нужно изменить значение параметра реестра RootDirURL в ветке HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate. Этот параметр должен указывать на сетевую папку, из которой клиентам нужно получать новые корневые сертификаты. Перейдите в секцию редактора GPO Computer Configuration -> Preferences -> Windows Settings -> Registry. И создайте новый параметр реестра со значениями:
Action: Update
Hive: HKLM
Key path: Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate
Value name: RootDirURL
Type: REG_SZ
Value data: file://\\dc01\SYSVOL\winitpro.ru\rootcert\

Осталось назначить эту политику на компьютеры и после обновления настроек GPO на клиенте проверить появление новых корневых сертификатов в хранилище.
Обновление корневых сертификатов в Windows 7
Несмотря на то, что Windows 7 уже снята с поддержки, есть много пользователей и компаний, в которых она еще используется.
После установки чистой Windows 7 из образа вы может столкнуться, что многие современные программы и инструменты на ней не работают из-за того, что они подписаны с помощью новых сертификатов. В частности, были жалобы, что в Windows 7 64 без обновления сертификатов не удается установить .Net Framework 4.8. или
vs_Community.exe с ошибкой:
installer manifest failed signature validation
После этого вы можете использовать утилиту certutil для генерации SST файла с сертификатами (на этом или на другом компьютере):
certutil.exe -generateSSTFromWU c:\ps\roots.sst
Теперь можно импортировать сертификаты в доверенные:
Утилита rootsupd.exe для обновления сертификатов в Windows XP
В Windows XP для обновления корневых сертификатов использовалась утилита rootsupd.exe. В этой утилита содержится список корневых и отозванных сертификатов, зашитых в которой регулярно обновлялся. Сама утилита распространялась в виде отдельного обновления KB931125 (Update for Root Certificates).
- Скачайте утилиту rootsupd.exe, перейдя по ссылке (по состоянию на 15.07.2019 ссылка не работает, возможно в Microsoft решили убрать ее из общего доступа. На данный момент вы можете скачать утилиту с сайта kaspersky.com — http://media.kaspersky.com/utilities/CorporateUtilities/rootsupd.zip);
- Для установки корневых сертификатов Windows, достаточно запустить файл rootsupd.exe. Но мы попробуем более внимательно рассмотреть его содержимое, распаковав его с помощью команды:
rootsupd.exe /c /t:C:\PS\rootsupd

- Сертификаты содержатся в SST файлах: authroots.sst, delroot.sst и т.п. Для удаления/установки сертификатов можно воспользоваться командами:
updroots.exe authroots.sst
updroots.exe -d delroots.sst
Но, как вы видите, дата создания этих файлов 4 апреля 2013 (почти за год до окончания официальной поддержки Windows XP). Таким образом, с этого времени утилита не обновлялась и не может быть использована для установки актуальных сертификатов. Однако нам чуть позже понадобится файл updroots.exe.
Была информация, что утилиту updroots.exe нежелательно использовать в современных билдах Windows 10 1803+, т.к. она может сломать корневой сертификат Microsoft Root Certificate Authority.
В этой статье мы рассмотрели несколько способов обновления корневых сертификатов на компьютерах Windows, изолированных от Интернета.
I am trying to decode and get information on a certificate using PowerShell. I want to be able to have a variable $Cert and then pull information about the certificate i.e.
$Cert.Subject
$Cert.Issuer
$Cert.ValidFrom
$Cert.ValidToI have the certificate as a variable.
$Cert = -----BEGIN CERTIFICATE-----
Content Here
-----END CERTIFICATE-----Decode the Base64 content into a byte array
$CertificateBytes = [System.Convert]::FromBase64String($Cert)**Error – MethodInvocationException: Exception calling “FromBase64String” with “1” argument(s): “The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.”
**
I’ve tried to see if there are hidden characters etc.
I did make some progress when I removed the —–BEGIN CERTIFICATE—– & —–END CERTIFICATE—– from the $Cert variable
I run the command again
Decode the Base64 content into a byte array
$CertificateBytes = [System.Convert]::FromBase64String($Cert) and it completes.
$CertificateBytesjust contains a list of numbers.
Create an X.509 certificate object from the byte array
$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2`
`$certificate.Import($certificateBytes)Error – MethodInvocationException: Exception calling “Import” with “1” argument(s): “X509Certificate is immutable on this platform. Use the equivalent constructor instead.”
$certificate= New-Object -TypeName system.Security.Cryptography.X509Certificates.X509Certificate2($CertificateBytes)Error – New-Object: Cannot find an overload for “X509Certificate2” and the argument count: “1608”.
$certificateBytes.Count




