Ошибка «Invalid algorithm specified» при генерации сертификатов в Windows

Недавно столкнулся с такой ошибкой на хосте с Windows Server 2019 после установки СКЗИ «Валидата CSP». Ошибка была при работа двух сервисов: Remote Desktop Services и Veeam Agent Backup. В логах Veeam например были такие сообщения:

Info Generating certificate. FriendlyName: [Manager to Agent channel encryption], Subject: [CN=VeeamDataMover connection certificate], ValidFrom: [02.08.2026 15:14:24], ValidTo: [02.09.2026 15:14:24]
Error Win32 exception (-2146893816) occurred on 1 attempt to create a certificate. Attempts left: 2
Error Invalid algorithm specified (System.ComponentModel.Win32Exception)
Error at Veeam.Backup.Common.WinAPIWrappers.CertContext.CertCreateSelfSignCertificate(CryptContext context, X500DistinguishedName subjectName, CertCreateSelfSignCertificateFlags flags, CryptKeyProvInfo keyProvInfo, CryptAlgorithmIdentifier signatureAlgorithm, DateTime startTime, DateTime endTime, X509ExtensionCollection extensions)
Error at Veeam.Backup.Common.SCertificateHelper.CreateSelfSignCertificateInternal(CryptContext context, String friendlyName, String subject, DateTime from, DateTime to, X509ExtensionCollection extensions)
Error at Veeam.Backup.Common.SCertificateHelper.CreateShortLivingSelfSignCertificate(String name, String friendlyName, Int32 certificateValidityPeriodMonths, X509ExtensionCollection extentions)
Error at Veeam.Backup.Common.SAgentTlsCertificateFactory.GenerateTlsCertificateRetryable(String friendlyName, Int32 attemptCounter)

В процессе поиска проблемы обнаружены были ветки реестра:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\1.2.840.113549.1.1.11!4]
"Name"="sha256RSA"
"Algid"=dword:0000800c
"Flags"=dword:00000001
"ExtraInfo"=hex:00,24,00,00
"CNGAlgid"="SHA256"
"CNGExtraAlgid"="RSA"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\1.2.840.113549.1.1.12!4]
"Name"="sha384RSA"
"Algid"=dword:0000800d
"Flags"=dword:00000001
"ExtraInfo"=hex:00,24,00,00
"CNGAlgid"="SHA384"
"CNGExtraAlgid"="RSA"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\1.2.840.113549.1.1.13!4]
"Name"="sha512RSA"
"Algid"=dword:0000800e
"Flags"=dword:00000001
"ExtraInfo"=hex:00,24,00,00
"CNGAlgid"="SHA512"
"CNGExtraAlgid"="RSA"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\2.16.840.1.101.3.4.2.1!1]
"Name"="SHA256"
"Algid"=dword:0000800c
"CNGAlgid"="SHA256"
"Flags"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\2.16.840.1.101.3.4.2.2!1]
"Name"="SHA384"
"Algid"=dword:0000800d
"CNGAlgid"="SHA384"
"Flags"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo\2.16.840.1.101.3.4.2.3!1]
"Name"="SHA512"
"Algid"=dword:0000800e
"CNGAlgid"="SHA512"
"Flags"=dword:00000001

После удаления этих веток и перезагрузки сервера бекап Veeam-агентом заработал и служба RDS выпустила сертификат.

Info Generating certificate. FriendlyName: [Manager to Agent channel encryption], Subject: [CN=VeeamDataMover connection certificate], ValidFrom: [03.08.2026 12:44:35], ValidTo: [03.09.2026 12:44:35]
Info [LeaseKeeper] Created. LeaseId: [f3a7bced-1a15-4da0-8761-6d56cc5c5abd], TTL: [100sec], ignoreExceptions: [False]
Info [CTransportSvcAgentManager] Agent has been started, ID 'b461be0b-45ad-4cea-ad0a-f4391beeb2d6', addresses '[::1]:2501;127.0.0.1:2501;192.168.67.11:2501', PID '10316'

Замена STS сертификата на vCenter

Менял я недавно vCenter сертификат с названием «STS Signing Certificate». Делал этот через веб-интерфейс клиента .
После нажатия на «Actions» — «Refresh with vCenter certificate» сертификат в интерфейсе успешно обновился, но появилось уведомление о необходимости всех систем. Я на всякий случай перезагрузил весь vCenter.  Сертификат как видно на скриншоте выдался на 8 лет до 2033 года. После этого я зашел по ssh на vCenter и запустил скрипт vCert.sh , с помощью которого проверил статус сертификатов.  В отчете  работы скрипта показывалось несколько ошибок. Путем некоторых манипуляций я перевыпустил еще раз «STS Signing Certificate». При такой манипуляции скрипт выпустил сертификат уже только на 2 года, при этом некоторые ошибки все еще висели:
«Checking VMDir certificate» и «Check STS VECS store configuration»

Для решения проблемы с «Checking VMDir certificate» я для начала выгрузил  отчет, который может сгенерировать скрипт vCert. В нем нашел такой сертификат:
Service Principal (Solution User) Certificates
Service Principal: WebClient_2014.05.19_021659
Issuer: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMWARE/emailAddress=support@vmware.com
Subject: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMware default certificate/emailAddress=support@vmware.com
Not Before: May 18 09:18:50 2014 GMT
Not After : May 16 09:18:57 2024 GMT
SHA1 Fingerprint : C6:7A:73:97:5C:CB:42:AC:48:55:72:0B:5E:8D:C7:5E:7B:0B:D9:FD
Signature Algorithm: sha256WithRSAEncryption
Subject Key Identifier:
Key Usage:
|_Digital Signature
|_Key Encipherment
|_Data Encipherment
Extended Key Usage:
|_TLS Web Server Authentication
Subject Alternative Name entries:
|_DNS:VMWARE
Other Information:
|_Is a Certificate Authority: No
|_Issuing CA in VMware Directory/VECS: No

Из-за него и возникала эта ошибка. Для его удаления я зашел в пункты меню 3 и затем 10, где скрипт vCert ругался на неиспользуемый сертификат (смотри скриншот ниже).  Я его удалил и после этого ошибка «Checking VMDir certificate» пропала

С ошибкой «Check STS VECS store configuration LEGACY» побороться оказалось также просто,  необходимо выполнить  команды
sed -i 's/STS_INTERNAL_SSL_CERT/MACHINE_SSL_CERT/' /usr/lib/vmware-sso/vmware-sts/conf/server.xml
/usr/lib/vmware-vmafd/bin/vecs-cli store delete --name STS_INTERNAL_SSL_CERT

и затем рестартовать одну из служб

service-control --restart vmware-stsd

vROPS не синхронизирует Metadata (vSphere Tags) из VMware vSphere

Боролся с такой проблемой — перестал получать обновления vSphere Tags  в систему VMware Aria Operations (vRops).  Нашел статью у вендора, где решается подобная проблема. В логах я не нашел такую ошибку как указано в статье, но мне помогла рекомендация рестартовать службу. В 7 версии Vsphere она называется «vAPI Endpoint». Её перезагрузка мне и помогла.

Ошибка «Unable To Reach The AWCP Endpoint : https://awcp.air-watch.com/provisioningportal/CSRGenerationHandler.aws/v1»

Столкнулся с такой ошибкой при попытке обновления сертификата APNs на Workspace One:Статья на сайте разработчика мне никак не помогала, т.к. она была старая и решение той проблемы было выполнено давно.
Я начал проверять сетевой трафик Wireshark и обнаружил такое поведение:
на стандартное приветствие TLS Handshake: Hello


удаленный сервер awcp.air-watch.com отвечает Handshake Failure

После этого вспомнили, что на серверах Workspace One ранее были отключены старые ключи шифрования. Включили их снова и после этого ошибка пропала.

Долгий запрос сертификата APNs (Apple MDM) в Workspace One

Обнаружил недавно проблему при запросе сертификата APNs в продукте Workspace ONE (бывший Airwatch) — он выполняется слишком долго (самый первый шаг).
Начал смотреть Procmon куда лезет в файловой системе этот продукт при запросе сертификата и выяснил, что он долго обрабатывает каталог C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates. Зашел в него и оказалось что там около 500 тыс. файлов. Через поиск в интернете быстро находится статья о проблеме со старыми версиями Airwatch https://kb.omnissa.com/s/article/82553 В результате, с помощью скрипта https://github.com/sntcz/Clear-MachineKeys  перенес файлы в другой каталог и проблема медленного запроса сертификата больше не проявлялась.

Ошибка Failed to call RPC function ‘Vss.GetFileFromGADir’: Error code: 0x80070005

Привет! При бекапе виртуальной машины на виртуализации VMware vSphere средствами Veeam Backup возникла неожиданная ошибка:

Failed to prepare VM for processing from storage snapshot, failing over to using VM snapshot. Details: Failed to call RPC function 'Vss.GetFileFromGADir': Error code: 0x80070005. Failed to invoke func [GetFileFromGADir]: Access is denied.. Failed to download the object. RPC function call failed. Function name: [FcGetItemInfo]. Target machine: [имя виртуальной машины]. RPC error:Access is denied. Code: 5.

Данный сервер бекапится у меня не только как виртуальная машина но и как сервер MS SQL.
Решение проблемы оказалось неожиданным: на этой проблемной виртуальной машине установлены пакеты Veeam:
Veeam Transaction LogBackup Service 12.1.0.2131
Veeam Guest agent 12.1.0.2131
Veeam Installer Service 9.5.0.1536

Удалив все их и выключив/включив задачу бекапа (для остановки бекапа логов) проблема устранилась.

Ошибка при обновлении ESXi «Error while waiting for untar process»

Столкнулся с очередной ошибкой при установке патча VMware-ESXi-7.0U3q-23794027:

esxupdate: ERROR: esximage.Errors.InstallationError: VMware_locker_tools-light_12.3.5.22544099-23794019: Error while waiting for untar process ‘[‘/bin/tar’, ‘xzf’, ‘-‘, ‘-C’, ‘/locker/packages/’]’: Timeout (30 seconds) expired waiting for output from command ‘[‘/bin/tar’, ‘xzf’, ‘-‘, ‘-C’, ‘/locker/packages/’]’

На сайте Broadcom появилась свежая статья с описанием и решением данной проблемы. Повторять ее не вижу смысла, хотелось лишь только добавить, что после последнего шага
vsish -e set /config/VisorFS/intOpts/VisorFSPristineTardisk 1
необходимо установить проблемный vib вручную (в статье это сказано по моему не однозначно)
esxcli software vib install -v /vmfs/volumes/../VMware_locker_tools-light_12.3.5.22544099-23794019.vib
Пакет VMware_locker_tools-light_12.3.5.22544099-23794019.vib скачивается отсюда.

Ошибка «Vmkernel module necessary for this vsi call not loaded» при добавлении NFS-датастора на ESXi

Привет! Если после перезагрузки у вас на ESXi пропали датасторы или не добавляются с ошибкой
An error occurred during host configuration.
Operation failed, diagnostics report: Unable to complete Sysinfo operation. Please see the VMkernel log file for more details.: Vmkernel module necessary for this vsi call not loaded


проделайте следующие действия:

  1. Зайдите на проблемный ESXi-хост по SSH и выполните команду:
    esxcli storage nfs list если ошибка аналогичная, то это скорее все наш случай, переходим к следующим шагам
  2. Проверяем что модули nfs не загружены в ядро
    vmkload_mod -l | grep 'nfs'
  3. Загружаем модули NFS в ядро
    vmkload_mod nfs41client
    vmkload_mod nfsclient
  4. Включаем загрузку модуля при включении ESXi
    esxcfg-module -e nfs41client
    esxcfg-module -e nfsclient
  5. Выполняем команду
    esxcli storage nfs list, теперь она должна выполниться успешно. Если там есть NFS-датасторы в отключенном состоянии, то удаляем их командой esxcli storage nfs remove -v "Volume Name"
  6. Перезагружаем ESXi
    reboot
  7. После перезагрузки добавляем NFS-датасторы, ошибок теперь быть не должно.

Veeam Backup error: Skipping database located on excluded virtual disk

Если в процессе бекапа логов по расписанию с виртуальной машины, на которой крутится  база данных MS SQL средствами Veeam Backup столкнетесь с ошибкой:
Skipping database located on excluded virtual disk
и при этом никаких исключений не создано в задаче бекапа, то в первую очередь проверьте что у вас не включена фича MPIO на проблемном сервере. Она осталась включенной после того, как сервер был виртуализован из физического, а роль не была удалена. После ее удаления и полного бекапа сервера, бекап логов по расписанию заработал.

Ошибка в задаче бекапа Veeam Agent

Veeam агент версии — 6.1.0.349
Veeam сервер версии — 12.1.1.56
При бекапе агентом одного из физических серверов возникла ошибка:
Error: AgentManagerService: Failed to start agent, Host ‘MBX01’. The remote procedure call was cancelled. RPC function call failed. Function name: [DoRpc]. Target machine: [::1]
В логах Veeam ничего дополнительного не нашел. Для устранения этой ошибки помог перезапуск сервиса VeeamEndpointBackupSvc на проблемном сервере. Причем сервис не хотел останавливаться, пришлось останавливать процесс Veeam.EndPoint.Service.exe вручную через Task Manager