Форум КриптоПро
»
КриптоПро УЦ
»
КриптоПро УЦ 2.0
»
0x80092023 — CRYPT_E_INVALID_X500_STRING
offshore |
|
|
Статус: Активный участник Группы: Участники Сказал «Спасибо»: 6 раз |
Здравствуйте! Проблема конечно избитая но всё же. Ошибка возникла у одного из наших клиентов. При попытке созданиязапроса сертификата через интерфейс Веб-УЦ появляется ошибка. Введён недопустимый символ. Сообщите об ошибке, поскольку это должно было быть обнаружено при проверке. Клиент: Сервер: Насколько я понял проблема заключается в: «The string contains an invalid X500 name attribute key, OID, value or delimiter. Был пакет исправлений для Windows Server 2003, но у нас 2008… Название орг-ии в кавычках АО «Фирма», лишних символов, запятых не вижу… UPD: В логах по этому случаю: Отредактировано пользователем 11 апреля 2017 г. 7:08:26(UTC) |
 |
|
web-uc.jpg |
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 36 раз |
Здравствуйте. Проблема в клиенте, в том что это XP и старая версия IE. Создавайте заявку на портале ТП — https://support.cryptopro.ru |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
batmandarkside |
|
|
Статус: Участник Группы: Участники
|
Добрый день! Была похожая проблема на windows 10 и ie 11. Убрал их и все взлетело! |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 36 раз |
Проблема экранирование кавычек решена в новой сборке УЦ 2.0.6142.0100 |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
batmandarkside |
|
|
Статус: Участник Группы: Участники
|
проблема не в УЦ: по на стороне клиента при генерации запроса на сертификат. Если есть ковычки в тексте — ( Операционный офис «Смоленский» ), по плагин выдаст ошибку — The string contains an invalid X500 name attribute key, oid, value or delimiter. (0x80092023) |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 36 раз |
Какая версия плагина? |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
batmandarkside |
|
|
Статус: Участник Группы: Участники
|
windows 10 Цитата: const DistinguishedName = yield window.cadesplugin.CreateObjectAsync(‘X509Enrollment.CX500DistinguishedName’); branchName === ‘Операционный офис «Смоленский»‘ если заменить на — Операционный офис, то все работает Отредактировано пользователем 15 августа 2017 г. 11:40:53(UTC) |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 36 раз |
Рисунка не видно, прикрепите его здесь на портале. |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
batmandarkside |
|
|
Статус: Участник Группы: Участники
|
плагина в браузере или ПО CryptoPro CSP ? |
|
|
|
|
batmandarkside |
|
|
Статус: Участник Группы: Участники
|
Плагин последней версии |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Форум КриптоПро
»
КриптоПро УЦ
»
КриптоПро УЦ 2.0
»
0x80092023 — CRYPT_E_INVALID_X500_STRING
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Будем строить отказоустойчивую репликацию между 5 хостами hyper-v 2012 r2 в 2 разных доменах, домены доверенные, но авторизацию для брокера реплики будем использовать на основе wildcard сертификатов.
Суть в том, что для каждого домена нужно создать сертификат корневого центра сертификации rootca.<domainname>.cer и им подписать 2-й созданный сертификат для хостов servers.<domainname>.cer
Готовим сертификаты:
Код ниже выполняем через cmd, перед выполнением нужно достать makecert, он есть по адресу Windows Kits8.1binx64 либо, для 2012r2 можно скачать makecert с моего сайта
Я выполнял команды на первых хостах hyper-v каждого домена, при этом они сразу же импортируются в нужные хранилища текущего сервера.
-------------------------------------- 1 домен ---------------------- makecert -pe -n "CN=*.domain1.ru" -ss root -sr LocalMachine -sky signature -r "rootca.domain1.ru.cer" makecert -pe -n "CN=*.domain1.ru" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "*.domain1.ru" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 servers.domain1.ru.cer --------------------- 2 домен --------------------- makecert -pe -n "CN=*.domain2.com" -ss root -sr LocalMachine -sky signature -r "rootca.domain2.com.cer" makecert -pe -n "CN=*.domain2.com" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "*.domain2.com" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 servers.domain2.com.cer
На каждом хосте меняем реестр:
reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationFailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Во время выполнения могут возникнуть ошибки:
Error: CryptCertStrToNameW failed => 0x80092023 (-2146885597) Failed
Это означает что вы скачали не тот makecert или не из того SDK. Для Windows Server 2012 нужен SDK для Windows 8. А для 2012 r2 нужен от 8.1. Все доступные SDK можно скачать тут
Error: There are more than one matching certificate in the issuer's root cert st ore Failed
Эта ошибка означает, что в хранилище сертификатов уже есть одноименный, сертификат либо сертификат с таким же отпечатком, нужно зайти в оснастку сертификаты, и аккуратно удалить неправильный старый сертификат.
После того, как сгенерировали все сертификаты нужно обменяться ими между хостами, НО перед этим, на каждом сервере нужно экспортировать рутовый и персональный сертификаты с закрытым ключем в файл .pfx
Открываем оснастку сертификаты — Локальный ПК, переходим в Личное — Сертификаты, находим там сертификат с ключиком и экспортируем в файл, тоже самое делаем в Доверенные корневые центры сертификации — Сертификаты, тут экспортируем хостовый сертификат с закрытым ключем.
После экспорта на всех хостах, нужно импортировать все сертификаты на все хосты в правильные папки, рутовые в Доверенные корневые центры сертификации и хостовые в Личные.
После этого можно начинать настраивать репликацию.
Еще может возникнуть вот такая ошибка: 0x00002EFD
Это означает, что с сертификатами что то не так, не правильное имя домена или еще что то…
Нужно делать либо WildCard сертификаты для авторизации Hyper-v Replica, либо сертификаты с дополнительным полем SAN (Subject Alternative Name) в котором прописывать имена всех хостов, имена брокера реплики (обязательно fqdn). Но сертификат с SAN в Windows можно подготовить только с помощью центра сертификации.
Why would you want a HyperV server in a workgroup environment?
Well if your Domain Controller is a VM you really don’t want to add the HyperV server to the domain as it will boot before the DC comes up. This type of setup is ripe for domain issues, so we’re left with a server that is only in a workgroup. Also if you are doing cross site replication, you might be replicating from/to different domains, this is where the self signed certificate authentication comes in to play as it is domain agnostic.
Kerberos authentication does not work in this setup, so we need to use a certificate authority as a means of authenticating the two servers with each other. The Primary server is where all the VMs are, and the Replica server is where the VMs will be copied to. HyperV replication is native and built into Server 2012 +, so there are no extra licenses necessary.
What are the steps involved?:
- Change the DNS suffix on both Primary and Replica servers.
- Reboot both servers.
- Create self signed certificates on both servers.
- Open the Certificate MMC snap-in on the Primary server and export the certificate to a .pfx file.
- Copy the export file and RootCA certificate from the Primary to the Replica server.
- Import the Primary RootCA certificate file on the Replica server.
- Import the .pfx file on the Replica server.
- Copy the RootCA certificate from the Replica to the Primary server and import it.
- Disable Certificate Revocation Check on both servers for replication and fail over replication.
- Setup the Replica server as a replica in HyperV.
- Start replication of a Server on the Primary server.
First we need to change the server names, or rather add a DNS suffix to them. Bring up System Properties in the Control Panel, under the Computer Name tab click change. In the Computer Name/Domain Changes window click More…
In the DNS Suffix and NetBIOS Computer Name add a Primary DNS suffix. Something along the lines of “hypervreplica.local”, it doesn’t matter call it what you will.
Click OK and save all the changes. Note that you will be required to reboot the server in order for changes to take effect. Do this to both the Primary and Replica server.
Primary is the server where your VMs reside, and Replica is where your VMs will be replicated or copied to.
Next we need to create a self signed certificate. For this you will either need Visual Studio or the Windwos SDK(https://www.microsoft.com/en-us/download/details.aspx?id=8442).
What we really need out of either of these is the makecert.exe file.
If you have VS installed the makecert.exe file is located under C:Program Files (x86)Windows Kits8.1binx64, or a similar path, the 8.1 will change depending on the version of Visual Studio you have installed.
Copy the makecert.exe file from here to the primary and the replica servers.
On both those servers create an empty directory somewhere, place the makecert file in there. This is also where we will create and store the self signed certificates.
On the Replica server open up an elevated command prompt and navigate to the directory where the “mekecert.exe” file is located and type in the following:
makecert -pe -n “CN=ReplicaRootCA” -ss root -sr LocalMachine -sky signature -r “ReplicaRootCA.cer”
The above command assigns a signature certificate issuer name to the replica server of “ReplicaRootCa”
Followed by:
makecert -pe -n “CN=replicahostname” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “ReplicaRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 ReplicaCert.cer
…where the replicahostname is replaced by the name of the server with the DNS suffix and all. Ex. hostname.domain.local.
Now move over to the Primary server, open up an elevated command prompt and navigate over to the folder where “makecert.exe” is located, and type the following:
makecert -pe -n “CN=PrimaryRootCA” -ss root -sr LocalMachine -sky signature -r “PrimaryRootCA.cer”
Followed by:
makecert -pe -n “CN=primaryhostname” -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in “PrimaryRootCA” -is root -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 PrimaryCert.cer
… where the primaryhostname reflects the name of the Primary server with the added DNS suffix. The above 4 commands will create two files on each server.
On the Primary server run > mmc, click File and select Add/Remove Snap-in…
Select the Certificates snap in and click Add>, on the next windows select Computer Account, click Next>, and then select Local computer:. Click Finish.
In the Certificates snap in, expand the Personal store and then click on Certificates.
You should have a certificate here with the Replica serve name and Issued by ReplicaRootCa.
Right click this certificate, select All Tasks and select Export…
This will open the Certificate Export Wizard, when prompted select Yes, export the private key.
Export File Format, use Personal Information Exchange…. (.PFX), Include all certificates and the certification path if possible.
On the Security page check the password box, and input a password you will remember.
Click the Browse button to save the export in a *.pfx file format, give it a file name (PrimaryServer.pfx) and click save.
Double check all your settings on the final page and click Finish.
Copy the PrimaryRootCA.cer file and the PrimaryServer.pfx files to the Replica server. Put it in the folder where you created your Replica Server certificates.
On the Replica server we will now import the cer and pfx files. Open up an elevated command prompt and navigate to the file location. Type in the follwing:
certutil -addstore -f Root “PrimaryRootCA.cer”
The quotes are only necessary if you have spaces or special characters in the file name.
Open up MMC, expand the Personal section, right click on Certificates and select All Tasks > Import.
The Certificate Import Wizard will open up. Click Next. On the File to Import page click Browse…
You might have to change the file type to view the pfx file.
Navigate over to the location of your PrimaryServer.pfx file and select it, click Open. Click Next. On the next screen enter the password for the Private Key. You can mark the key as exportable if you’d like, this means you can export it at a later time if you do not keep a copy of it somewhere. Also check off Include all extended properties. Click Next.
Place the certificate in the Personal certificate store. Click Next. On the final page inspect all the details and make they are correct. Finally click Finish.
*Please be aware that for fail over replication you will more than likely need to export the certificate in the pfx format from both servers and then copy them over and import them on both servers as well. The reason for this is that replication is only one way, where as fail over replication goes both ways. Something to think about.
Now copy the ReplicaRootCA.cer file over to the primary server, place it in the folder with all the other certificate files. In and elevated command prompt add it to the certificate store.
certutil -addstore -f Root “ReplicaRootCA.cer”
Run the following two commands on both servers in an elevated command prompt.
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationFailoverReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
reg add “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationReplication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f
Note that the only difference between the two registry commands is FailoverReplication and Replication. You shouldn’t need to restart either of the servers after these commands.
Next you need to enable the Replica server as the replica.
On the Replica server open the HyperV manager.
Select HyperV Replication Configuration, in the configuration window check off Enable this computer as a Replica server. Check off Use certificate-based Authentication (HTTPS). It should prompt you to select a certificate, if not click on Select Certificate… you should have the option to select the certificate you created on the Replica server. Select it and click Apply.
*Note, that you will get a prompt about the Windows Firewall, I have mine disabled on all servers so this message never applied to my setup. However if you have your fire wall turned on I would recommend adding a rule to it to allow the traffic on port 443 to pass.
Now the real test, go to your Primary HyperV server and attempt to enable replication. Open up HyperV manager, select a virtual machine, right click it and slect Enable Replication…
You will be presented with a Before You Begin page, click Next >.
On the Specify Replica Server page, type in the FQDN of the replica server, for example, replicahostname.domain.local, or whatever the hostname and dns suffix that you assigned to your replica server is. Click Next >.
On the Specify Connection Parameters, make sure that certificate-based authentication is selected. Kerberos authentication only works on a domain. You may need to select the proper certificate, this will be the Primary server certificate. Also check off Compress the data that is transmitted over the network. If you see a yellow exclamation sign with the text “Could not get configuration details of the specified server.” at the bottom, don’t worry about it, if everything is setup properly it should not impact the replication in any way, shape, or form. Click Next >.
Choose Replication VHDs, here you can pick and choose which storage attached to the server you want to replicate. Select the storage you want and click Next >.
Configure Replication Frequency. The options here are 30 seconds, 5 minutes, or 15 minutes. Depending on how mission critical your data is choose accordingly. Note that replication frequency differs from Server 2012 to Server 2012 R2.
Configure Additional Recovery Points. Depending on how many recovery points you require here is where you set that up. You can setup additional hourly recovery points and even use VSS for snapshots. Hourly recovery points provide granularity, no only can you recover form the last replication point, but with this option enabled you can go back hours. You also have the option of VSS snapshots which, from personal experience, can fail. I don’t have experience with VSS on replication, but VSS on backups and more often than not VSS was always the culprit for failed backups. VSS has a tendency to fail, not ofter but every once in a while. Either way I usually only maintain the latest recovery point. Again the number of recovery points differs from 2012 to 2012 R2, 15 vs 24.
Pick your poison and click Next >.
Choose Initial Replication Method. These options are self explanatory. Chose your replication method and when. I usually just send it over the network, I find that the impact is minimal. You can also start the initial replication at a defined time, perhaps when your system is not as busy at night etc.
*One thing to note about replication and this is important, replication creates an avhdx file. This is a HyperV change file, and during the initial replication this can grow quite large in size. On a normal active system I have observed that this file can grow to 33% size of the original VHDX/VHD file. So be careful and be warned, because if the storage medium runs out of space it will pause the VM.
Click Next >. Confirm your settings and click Finish. Your replication should now begin.
This blog post is the second in a series of three which will demonstrate how to configure a Point-to-Site VPN step-by-step. In my first blog post, I demonstrated how to configure a virtual network and a dynamic routing gateway. Today’s post will be about creating certificates.
CREATING CERTIFICATES
At this step, we will create and upload a certificate. This certificate will be used to authenticate the VPN clients and are performed in few steps:
- Generate the certificate
- Upload the root certificate to the Azure Management Portal
- Generate a client certificate
- Export and install the client certificate
Let’s start …
- We will need to use the MakeCert tool. MakeCert is part of “Microsoft Visual Studio Express”.
- After successfully downloading the tool, start the setup and follow the installation steps. Note that you can generate this certificate in any computer, not only in the computer where you are configuring the VPN.
After the installation, you can find MakeCert at:- C:Program Files (x86)Windows Kits8.1binx64
- C:Program Files (x86)Windows Kits8.1binx86
- Launch the command prompt as Administrator. Point the path to one of the folders referred in the previous step and execute the following command (note: keep the command line opened):
makecert -sky exchange -r -n “CN=RootCertificateMurilo” -pe -a sha1 -len 2048 -ss My “RootCertificateMurilo.cer”
(where “RootCertificateMurilo” is teh certificate name).
This command will create and install a root certificate in the Personal certificate store and create the define RootCertificateMurilo.cer file in the same directory that you are executing the command.
Note: Store this certificate in a safe location. - Now, go to the Windows Azure Management Portal https://manage.windowsazure.com/ in order to upload the certificate.
- In the networks section, select the previously created network and go to the certificate page.
- Click Upload a root certificate, select your certificate, and click in the check mark.
- Depending on the time zone of the server where you created the certificate, you might receive an error message, “The certificate is not valid yet, effective date is [date and time].” To work around this, delete the created certificate, and create another one adding the following parameter (change the date):-b “07/30/2014″It will be valid form 00:00:00 hours for the day you set.
- Now we need to create a Client Certificate. We will use the Root Certificate to do this.
In the same command line window, opened before, execute the following command:makecert.exe -n “CN=ClientCertificateMurilo” -pe -sky exchange -m 96 -ss My -in “RootCertificateMurilo” -is my -a sha1This certificate will be stored in your personal certificate store. - Now we need to export this certificate, as this should be installed on each computer that needs to be connected to the virtual network. To achieve this, enter the command “mmc”, still in the opened command line. The following window will be shown:
- To export the certificate, right click the Client certificate and click on “All Tasks->Export…”, as shown:
- A wizard will be presented. Choose Yes, export the private key and click.
- Leave this as default, and click Next.
- Choose a strong password (try to remember this) and click Next.
- Now you need to set the path to store you .pfx file.
- Click Next, then Finish.
- To finalize the “Certificates part”, we will need to install the certificate on all the servers where we want to setup the VPN.To accomplish this, you just need to:
- Copy the exported .pfx file (step 13) to all the servers.
- Double-click the pfx on all the servers.
- Enter the password.
- Proceed with the installation, maintaining the default location.
Note: Store this certificate in a safe location.
Stay tuned for my next blog post on how to configure the VPN client.
Want to talk with an expert? Schedule a call with our team to get the conversation started.