Преференциален консултант. Ветерани. Пенсионери. Хора с увреждания. деца. семейство. Новини

Използване на ключ за разширение на сертификата. Къде мога да получа информация за инсталиране на SSL сертификат? Международен съюз по телекомуникации

Това приложение описва стандартите, към които се придържа Windows 2000 Certificate Services и конкретното приложение на тези стандарти. Той също така описва как и къде тези стандарти се използват от сертифициращите органи. Тези теми са обхванати в следните подраздели:

Международен съюз по телекомуникации

Международният съюз по телекомуникации (ITU) е организация, която определя стандарти за комуникационната индустрия. Нейни членове са повече от 150 държави. ITU предоставя на правителствата и частния сектормеханизъм, чрез който е възможно координираното развитие на глобалните телекомуникационни мрежи и системи. ITU-T е секторът на ITU, който отговаря за телекомуникационните стандарти. ITU-T отговаря за разработването на стандарти за мрежови протоколи, за системи за факсимилно предаване и за разработване на стандарти за изграждане и работа на модем.

X.509 версия 3 сертификати

Повечето използвани днес сертификати са базирани на стандарта ITU-T X.509. При работа с Windows сертификати 2000 се придържа към този стандарт.

Сертификатът X.509 съдържа публичен ключ и информация за лицето или юридическото лице, на което е издаден сертификатът, информация за самия сертификат и допълнителна информация за сертифициращия орган (CA), който е издал сертификата. Информацията за собственика може да включва името на субекта (името, получило сертификата), публичния ключ, алгоритъма на публичния ключ и, като опция, уникалния идентификатор на собственика. Разширенията на стандарта ви позволяват да добавите информация към сертификат X.509 версия 3, свързана с идентификатори на ключове, информация за използване на ключове, политика за сертификати, допълнителни имена и атрибути, ограничения на пътя на сертифициране и разширения за анулиране на сертификат, включително причини за анулиране и разделяне на CRL извършва се при актуализиране на сертифициращия орган (CA).

Използването на индустриален стандарт X.509 версия 3 формати на сертификати и отворени интерфейси позволява на Windows 2000 Certificate Services да взаимодействат с много други продукти и технологии, които поддържат използването на базирани на криптография публични ключовеи инфраструктура с публичен ключ.

Общност на IETF

Общността на Internet Engineering Task Force (IETF) е отворена международна общност от мрежови дизайнери, оператори, производители и изследователи, интересуващи се от развитието на интернет архитектурата. Общността на IETF е разделена на няколко работни групи според тематичните области. Всяка работна група разработва стандарти за Интернет в съответствие със собствените си теми. Всеки стандарт е публикуван в RFC документ (RFC - Request for Comments) под определен номер. Впоследствие стандартът може да бъде преработен, което води до публикуване на RFC под нов номер и оригиналния документ да се счита за остарял.

Работна група IETF, насочен към разработване на рамката за оперативна съвместимост на инфраструктура с публичен ключ, се нарича PKIX. (Адресът на уебсайта на PKIX е предоставен в раздела „Допълнителна информация“). Стандартите за инфраструктура с публичен ключ за Интернет все още се разработват. Въпреки това Microsoft е проектирала сертификатни услуги, за да се придържа към съществуващите стандарти, за да осигури съвместимост с инфраструктурата на публичния ключ. По-специално, Microsoft гарантира, че услугите за сертификати на Windows 2000 отговарят на изискванията на RFC 2459 (описан по-късно).

Документ RFC 2459

Спецификацията RFC 2459 е един от стандартите, които описват използването на X.509 публичен ключ инфраструктурен сертификат в Интернет. Характеристиките на RFC 2459 са описани в следните подраздели:

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

В съответствие с RFC 2459, сертифициращите органи на Windows 2000 (CA) записват информация в полетата за име на субект, име на издател, алтернативно име на субект и имена на алтернативни издатели в специфично кодиране RFC 2459 дефинира три типа кодиране за използване в сертификати: PrintableString, BMPStringИ Unicode Transformation Format 8 (UTF-8). Използване на кодирането TeletexStringсъщо така е разрешено да предоставя поддръжка за клиенти, които не отговарят на този RFC. Всеки тип кодиране поддържа различни набори от знаци. Наборът от знаци, използван в сертификатите, определя вида на кодирането, което трябва да се използва.

Стандартното кодиране е PrintableString. Набор от знаци, които се поддържат от кодирането PrintableString, са подмножество от ASCII знаци. Подгрупата е представена със следните символи:

Ако наборът от символи PrintableStringне е подходящ за употреба, тогава нанесете BMPString. BMPStringизползва набора от знаци Unicode, така че може да се използва за въвеждане на знаци от повечето международни набори от знаци (Unicode използва два байта за кодиране на всеки знак, което позволява 65 536 комбинации от знаци). В случай, че е невъзможно да се използва набор от знаци PrintableStringи ако е известно, че клиентът не поддържа Unicode при прилагане, се използва наборът от символи TeletexString. Платформата Windows 2000 в момента не поддържа кодиране UTF-8.

Някои инфраструктурни продукти с публичен ключ не поддържат Unicode в сертификати. Липсата на такава поддръжка може да доведе до проблеми със съвместимостта, които са трудни за идентифициране. Повечето производители са изразили намерението си да поддържат RFC 2459 в своите продукти. Колкото повече продукти се актуализират, за да поддържат този тип кодиране, толкова по-малко проблеми ще има. В момента, преди да използвате знаци, които не са включени в сертификатите, PrintableStringВажно е да проверите дали всички PKI продукти, които използват сертификати на сертифициращия орган (CA) на Windows 2000, могат да поддържат Unicode кодирането, използвано в сертификатите.

Разширения на сертификати

RFC 2459 дефинира голям брой разширения, повечето от които са незадължителни. Повечето разширения включват допълнителни настройки. Едно от най-големите предизвикателства, свързани с оперативната съвместимост на инфраструктурни продукти с публичен ключ, базирани на RFC 2459, е големият брой пермутации на параметри, които стандартът позволява.

Таблица 2 изброява всички разширения на RFC 2459, които Windows 2000 Сертифициращи органи (CA) използват в сертификати, когато са създадени.

Таблица 2 - Разширения на сертификат RFC 2459, използвани от сертифициращия орган на Windows 2000 (CA)

Тип сертификат Корпоративни сертифициращи органи (CA) Изолирани сертифициращи органи (CA)
Сертификат корен центърсертифициране (CA) (Основни ограничения)

Основни ограничения

Използване на ключ

(Идентификатор на ключ на тема)
ID на ключа собственик


(Шаблон на сертификат)

Шаблон за удостоверение
(CA версия)

(Основни ограничения)
Основни ограничения

(Използване на ключ)
Използване на ключ

(Идентификатор на ключ на тема)
ID на ключа на собственика

(CRL точка на разпространение (CDP))
Точка за разпространение на списък за отмяна (CDP)

(Шаблон на сертификат)

Шаблон за удостоверение
(CA версия)

Версия на сертифициращия орган (CA).

Сертификат на подчинен сертифициращ орган (CA). (Основни ограничения)
Основни ограничения

Използване на ключ

(CRL точка на разпространение (CDP))

Точка за разпространение на списък за отмяна (CDP)
(Идентификационен номер на ключ на орган)


(Достъп до информация на органа, AIA)

Достъп до информация за центрове сертифициране (AIA)
(Шаблон на сертификат)

Шаблон за удостоверение
(CA версия)

Версия на сертифициращия орган (CA).

(Основни ограничения)
Основни ограничения

(Използване на ключ)
Използване на ключ

(CRL точка на разпространение (CDP))

Точка за разпространение на списък за отмяна (CDP)
(Идентификационен номер на ключ на орган)
Идентификатор на ключ на сертифициращия орган (CA).

(Достъп до информация на органа (AIA))
Достъп до информация за центрове сертифициране (AIA)
(CA версия)

Версия на сертифициращия орган (CA).

Сертификат за окончателен собственик (Използване на ключ)

Използване на ключ
(Подобрено използване на ключ)

Използване на разширен ключ
(CRL точка на разпространение (CDP))

Точка за разпространение на списък за отмяна (CDP)
(Идентификационен номер на ключ на орган)

Идентификатор на ключ на сертифициращия орган (CA).

(Алтернативно име на тема)

Алтернативно име на собственик

(Шаблон на сертификат)

Шаблон за удостоверение

(Използване на ключ)

Използване на ключ
(Подобрено използване на ключ)

Използване на разширен ключ
(CRL точка на разпространение (CDP))

Точка за разпространение на списък за отмяна (CDP)
(Идентификационен номер на ключ на орган)

Идентификатор на ключ на сертифициращия орган (CA).
(Достъп до информация на органа, AIA)

Информация за органа за достъп (AIA)


Разширения на сертификати и CRL

Следното е описание на някои от най-важните разширения на сертификати и CRL:

  • Разширение Основни ограниченияИзползва се само за сертификати на сертифициращи органи (CA). Той съдържа булев флаг за указване на сертификата на сертифициращ орган (CA). Това разширение е маркирано като критично в сертификата. IN в момента Windows 2000 корпоративни сертифициращи органи (CA) и самостоятелни сертифициращи органи (CA) не поддържат опцията за дължина на пътя в това разширение.

    Разширение Използване на ключдефинира криптографските операции, за които могат да се използват двойки ключове. Възможни са следните опции за използване:

    • Цифров подпис
    • Неотказност
    • Ключово криптиране
    • Криптиране на данни
    • Ключово споразумение
    • Сертификати за подписване
    • Подписване на списък за анулиране (CRL)
    Разширението за използване на ключ в сертификатите на сертифициращия орган (CA) позволява цифрово подписване, подписване на сертификати и подписване на списък за анулиране (CRL). Освен това цифровите подписи са разрешени с подписване на сертификат и списък за анулиране (CRL), защото понякога сертифициращ орган (CA) трябва да подпише обекти, различни от сертификати и списъци за анулиране (CRL). Сертификатите за краен потребител могат да се използват в следните случаи:
    • Само за подписване.Цифровият подпис е разрешен само за сертификати, предназначени за подпис.
    • Само за обмен на ключове.За сертификати, които могат да се използват само за обмен на ключове. В този случай ключовете и данните се криптират с помощта на RSA ключове. Windows 2000 Сертифициращи органи (CA) не поддържат публични ключове на Diffie-Hellman.
    • Както за подписване, така и за обмен на ключове.За сертификати, които се използват както при подписване, така и при обмен на ключове, е разрешено цифрово подписване и криптиране на ключ и данни.
  • Точки за разпространение на списъка за отмяна (CDP - CRL точки за разпространение).Разширението CDP показва къде е публикуван CRL. Мястото на публикуване съдържа статуса на анулиране на сертификата. Сертифициращите органи (CA) на Windows 2000 използват URI различни видове. По подразбиране корпоративният сертифициращ орган (CA) използва LDAP и HTTP URI. Изолиран сертифициращ орган (CA) използва HTTP и FILE URI. Ако трябва да посочите допълнителни местоположения, трябва да редактирате списъка с URI с помощта на конзолната добавка Сертифициращ орган (CA) MMC конзоли.
  • Идентификатор на ключ на органа (AKI).Разширението AKI ви позволява да определите кой ключ е използван за подписване на сертификата. Това може да бъде много полезно, ако сертифициращият орган (CA) е актуализиран и може да има множество ключове. Освен това сертифициращите органи на Windows 2000 (CA) могат допълнително да включват информация за издателя и сериен номерсертификат, който ви позволява точно да идентифицирате сертифициращия орган (CA), който е издал сертификата. Тази функция може да бъде полезна за използване в много надеждни приложения.
  • Достъп до информация за сертифициращи органи (Authority Information Access, AIA).Разширението AIA ви позволява да намерите сертифициращия орган (CA), издал сертификата. Повечето инфраструктурни протоколи с публичен ключ включват пълна веригасертификати, но това не е гарантирано. Windows 2000 Сертифициращи органи (CA) използват различни типове URI. По подразбиране корпоративният сертифициращ орган (CA) използва LDAP и HTTP URI. Изолиран сертифициращ орган (CA) използва HTTP и FILE URI. Ако трябва да посочите допълнителни местоположения, трябва да редактирате списъка с URI с помощта на конзолната добавка Сертифициращ орган (CA) MMC конзоли.
  • Алтернативно име на собственик.Потребителските сертификати имат много видове имена, за да ги идентифицират. Корпоративни сертифициращи органи (CA) в това разширение могат да използват Kerberos имена и адрес имейл.
  • Специални разширения на Windows 2000

    Windows 2000 корпоративни сертифициращи органи (CA) включват две специфични разширения на Microsoft. Тези разширения се използват в контролни задачи:

    Година 2000 и сертификати

    Сертификатите и CRL съдържат датата. За сертификати датата показва срока на валидност. За CRL датата показва кога е създаден CRL и кога се очаква да бъде публикуван следващият CRL. RFC 2459 уточнява, че датите между 1949 и 2050 г. ще използват двуцифрена нотация за година. За дати след 2050 г. ще се използва четирицифрен запис. Windows 2000 Certificate Services отговаря напълно на тези насоки.

    Международни набори от символи и DNS имена

    Общността на IETF гарантира, че всички нови RFC включват поддръжка за международни набори от символи, позволяват използването на UTF-8 или посочват времева рамка, в рамките на която трябва да бъде осигурена поддръжка на UTF-8 (стандартите PKI уточняват, че трябва да се предостави пълна поддръжка на UTF-8 до 2003 г.). Не всички етапи от този процес все още са завършени. Въпросът как да се използва международният набор от символи в URI остава неразрешен. Когато Windows 2000 Certificate Services беше завършен, все още нямаше стандарт, който да описва това. URI адресите са посочени в сертификатите, за да идентифицират къде са публикувани CRL и сертификатите на сертифициращия орган (CA). URI се извличат отчасти от DNS името на сертифициращия орган (CA). Следователно сертифициращите органи (CA) на Windows 2000 не поддържат използването на международния набор от символи в DNS името на сървъра.

    Стандарти за криптография с публичен ключ (PKCS)

    Стандартите за криптография с публичен ключ (PKCS) са семейство стандарти за криптиране с публичен ключ, разработени от RSA Laboratories в сътрудничество с Apple, Digital, Lotus, Microsoft, MIT, Northern Telecom, Novell и Sun. Стандартите PKCS описват синтаксиса за многобройни структури от данни, използвани при криптиране с публичен ключ.

    По-конкретно стандартите PKCS описват синтаксис за:

    Цифрово подпишете съобщение.Стандартите определят как да се подпише съобщение цифров подпистака че другите да могат да проверят кой е подписал това съобщение и дали е променено след подписването му.
    Шифроване на съобщения.Стандартите определят как едно съобщение може да бъде криптирано без предварителна комуникация с получателя на съобщението, така че никой друг освен получателя да не може да дешифрира съобщението.
    Гарантиране, че заявителят има частния ключ.Стандартите определят как да направите заявка до сертифициращ орган (CA), така че той да може да провери дали съобщението е подписано с ключа, съдържащ се в заявката, като по този начин се гарантира, че заявителят има частния ключ.

    Всички стандарти се отличават с техните номера (от 1 до 15). Windows 2000 Certificate Services използва следните PKCS стандарти:

    PKCS-1. IN този стандартописва създаването на цифрови подписи, базирани на алгоритъма за публичен ключ RSA във връзка с алгоритми за хеширане. Той също така описва как симетричните ключове се криптират с помощта на алгоритъма за обмен на ключове RSA. Този стандарт се използва и във връзка със стандарта PKCS-7, за да се определи как се създават подписани съобщения. Този стандарт също така описва предоставянето на RSA публични ключове и частни ключове. Windows 2000 Certificate Services се придържа към RFC 2459, който препраща към стандарта PKCS-1 относно това как да се подписват сертификати X.509 с RSA и кога да се включват публични ключове RSA в тях.
    PKCS-7.Този стандарт описва как всеки блок от данни е цифрово подписан и криптиран. Той също така описва възможността за включване на допълнителна информация в съобщение (например часа, когато съобщението е подписано) и защитата му със същия цифров подпис. Той също така описва използването на специална форма на PKCS-7 съобщение, известно като изродено съобщение, за транспортиране на сертификати и CRL. PKCS-7 също така определя как се криптират данните с помощта на алгоритъм за криптиране на симетричен ключ (като алгоритъм за криптиране на съдържание) и публични ключове RSA за криптиране на симетричен ключ (като алгоритъм за обмен на ключове)).
    PKCS-10.Този стандарт описва как се генерира съобщение за искане на сертификат. Заявката за сертификат се състои от публичен ключ и допълнителен набор от атрибути. Например, те могат да бъдат: отличителното име или имейл адрес на искащата страна, подписан с частен ключ, който съответства на публичния ключ, посочен в заявката. Съобщението PKCS-10 е стандартът, към който се придържа Windows 2000 Certificate Services, за да получи заявка за сертификат. След като бъде получена заявка, Windows 2000 Certificate Services я обработва и или я отхвърля, или издава X.509 сертификат на заявителя. Информацията, която заявителят получава, ще бъде под формата или на един сертификат X.509, или на сертификат и цялата верига от сертификати до основен сертификат. IN в този случайинформацията ще бъде под формата на изродено PKCS-7 съобщение.

    Допълнителна информация

    За най-нова информация относно Windows 2000 Server посетете http://www.microsoft.com/windows2000/.

    За повече информация разгледайте:

    Практик върху основите на криптографията: Шнайер, Брус. „Приложна криптография: протоколи, алгоритми, източници в C“, второ издание, John Wiley & Sons, 1995 (Schneier, Bruce. Приложна криптография: протоколи, алгоритми и изходен код в C. 2-ро изд. John Wiley & Sons, 1995) (EN).

    Официален документ: " Отстраняване на неизправности при внедряването на инфраструктурата на публичния ключ (PKI) на Windows 2000 и проблеми с влизането в смарт картата"Отстраняване на неизправности при внедряване на Windows 2000 PKI и влизане със смарт карта (EN).

    Официален документ: " Архитектура на Active Directory"Архитектура на Active Directory (EN).

    1 Windows 2000 използва списък за контрол на достъпа (ACL), който е списък с ограничения за сигурност, които се прилагат към цял обект, набор от свойства на обект или едно свойство на обект. Всеки обект на Active Directory има два свързани с него ACL: дискреционен списък за контрол на достъпа (DACL) и списък за контрол на достъпа до системата (SACL). Списъците на DACL сметкипотребители, групи и компютри, на които е разрешен (или отказан) достъп до обекта. DACL се състои от ACE (записи за контрол на достъпа), всеки от които представлява разрешение или отказ за потребителите, групите или компютрите, изброени в DACL. ACE записът съдържа идентификатор за сигурност (SID) с права за достъп, като четене, запис или пълен контрол. SACL е отговорен за проверка на регистрационния файл на сигурността на подходящи действия върху обект (например достъп до файл) от потребители или групи.
    2 LDAP е протокол за директория, който работи върху TCP/IP. Това е прост протокол за достъп до директория, използван за добавяне, модифициране и изтриване на информация, съхранявана в Active Directory. Използва се и за запитване и извличане на данни от Active Directory. Клиентите на Active Directory трябва да използват LDAP, за да извличат информация от Active Directory или да съхраняват информация в Active Directory. Active Directory използва този протокол за комуникация с LDAP-съвместими клиентски приложения. Ако имате подходящите разрешения, можете да използвате всяко LDAP-съвместимо клиентско приложение, за да преглеждате, заявявате, добавяте, променяте или изтривате информация в Active Directory.
    3 MIME е метод за предаване на нетекстови данни по интернет чрез имейл. MIME кодира нетекстови данни с помощта на ASCII знаци и след това ги преобразува в оригиналната им форма в приемащия край. S/MIME е MIME разширение, което поддържа защитена поща. S/MIME позволява на подателя да подпише цифрово съобщение, за да гарантира, че произходът на съобщението и целостта на данните могат да бъдат потвърдени. S/MIME позволява съобщенията да се изпращат криптирани, за да се гарантира поверителност.
    4 SSL (Secure Sockets Layer, SSL) е отворен стандарт, предложен от Netscape Communications за установяване на защитен комуникационен канал за предотвратяване на подслушване важна информация, например като числа кредитни карти. Първоначално е разработен, за да осигури сигурност за цифровия обмен на финансови данни през Интернет, но сега може да се използва в други интернет услуги.
    5 TLS протоколЗащитата на транспортния слой (TLS) е стандартен протокол, използван за осигуряване на сигурни уеб връзки в интернет и интранет. Позволява на клиентите да удостоверяват сървъри или сървърите да удостоверяват клиенти (последното е опция). За целите на поверителността той също така защитава канала чрез криптиране.
    6 Файловата система EFS е нова възможноств Windows 2000, който защитава чувствителни данни, съхранявани във файлове на NTFS дялове. За да гарантира поверителността на тези файлове, EFS използва криптиране със симетричен ключ във връзка с технологията на публичния ключ.
    7 Центърът за разпределение на ключове Kerberos (KDC) е мрежова услуга, която доставя билети за сесии и временни ключове за сесии, използвани в протокола за удостоверяване на Kerberos. В Windows 2000 KDC работи като привилегирован процес на всички домейн контролери. KDC използва Active Directory за управление на поверителна информация за идентификационни данни, като пароли за акаунти.
    8 Контекстът на сигурността се отнася до атрибутите или правилата за сигурност, които са в сила в момента. Например, правилата, които определят какви действия може да извърши потребителят върху защитен обект, се определят от информацията за защита в токена за достъп на потребителя и в дескриптора за защита на обекта. Заедно токенът за достъп и дескрипторът на сигурността образуват контекста на сигурността за действията на потребителя върху даден обект.
    9 Да получаваш обща информацияотносно репликацията на Active Directory, моля, вижте официален документ („Архитектура на Active Directory“) (EN), връзката към която е дадена по-горе в този раздел. За подробности, моля, вижте документа „Репликация на Active Directory“(„Репликация на Active Directory“) (EN) в интернет.
    10 URI е низ от знаци, използван за идентифициране на ресурс (като файл) по неговия тип и местоположение от всяко място в Интернет. URI включват унифицирани имена на ресурси (URN) и унифицирани локатори на ресурси (URL).
    11 SGC обикновено са достъпни за квалифицирани банкови и финансови институции по целия свят. Изключение правят банките и финансовите институции, разположени в страни, подложени на ембарго от САЩ (списъкът с ембарго включва Куба, Иран, Ирак, Либия, Северна Корея, Сирия и Судан), както и няколко други дестинации (списъкът включва Русия и Китайска народна република).
    12 Сигурният канал (schannel - Secure Channel) на пакета за сигурност поддържа протоколи, базирани на публични ключове SSL (Secure Sockets Layer, SSL) версии 2 и 3, както и TLS (Transport Layer Security, TLS). Протоколът TLS е стандарт на IETF за SSL и за протокола PCT (Технология за частна комуникация). Schannel определя кой от тези протоколи да се използва при комуникация с друг компютър. Протоколите SSL, TLS и PCT използват сертификати за доказване на автентичност. IIS 5.0 се доставя на международни клиенти с файл SCHANNEL.DLL, който поддържа стандартни 40-битови схеми за криптиране. Освен това, ако IIS сървърът получи SGC сертификат от сертифициращ орган (CA), SCHANNEL.DLL поддържа създаването на 128-битов канал с помощта на ключовете на SGC сертификата.
    13 Всеки обект на Active Directory има LDAP отличително име (понякога съкратено DN - отличително име). За информация как Active Directory обработва LDAP DN имена, моля, вижте официалния документ „Архитектура на Active Directory“(„Архитектура на Active Directory“) (EN), връзката към която е дадена по-горе в този раздел.

Изпращат се данни за инсталиране на SSL сертификата след освобождаването муИ активиране. Те се изпращат на имейла за контакт на сертификата. Някои данни (CSR заявка и частен ключ) се генерират само по време на закупуването на SSL сертификат и не се изпращат в имейл.

Как мога да разбера на кой имейл за контакт е изпратено съобщение?

Ако SSL сертификатът е поръчан през партньорски уебсайт, имейлът за контакт е посочен на партньорския уебсайт.

Готови! Разпознали сте имейла, на който са изпратени данните за SSL сертификата.

Данни за монтаж в писмото

Начало на писмото с данни за монтаж

В писмото ще намерите:

  • SSL сертификат(посочено след думите „Вашият сертификат е предоставен по-долу“);
  • Основен сертификат;
  • Междинен сертификат(използва се във верига с основен сертификат. Това означава, че по време на инсталацията първо се вмъква основният сертификат, а след това междинният на нов ред);
  • Заявка за сертификат— въз основа на него удостоверителният център генерира и издава SSL сертификат;
  • Личен ключ(За безплатен сертификат) - след думите „Запазете личния ключ на вашия локален компютър.“ Частният ключ за платения сертификат трябва да бъде запазен на етап поръчка.

внимание!

Частният ключ на сертификата не се съхранява на сървърите на сайта. Копирайте личния ключ от писмото, поставете го в празен текстов файл и го запазете във формата .txtили .ключ.

Ако сте загубили или компрометирали частния си ключ, текущият ви SSL сертификат не може да бъде използван. За да разрешите проблема, издайте повторно SSL сертификата според инструкциите: .

Данни в Личен акаунт

Някои данни ( Сертификат, основен + междинен сертификат и заявка за CSR) се дублират във вашия личен акаунт. Те идват под формата на файлове, които можете да изтеглите и след това да качите, когато инсталирате SSL сертификата на сървъра.

Инсталиране на сертификат и частен ключ

Ще опишем инсталирането на сертификата електронен подписи частен ключ за операционни системи Windows. По време на процеса на настройка ще ни трябват права на администратор (така че може да се нуждаем от системен администратор, ако имате такъв).

Ако все още не сте разбрали какво е електронен подпис, моля, прочетете Or ако все още не сте получили електронен подпис, свържете се със Сертификационния център, препоръчваме SKB-Kontur.

Е, да предположим, че вече имате електронен подпис (токен или флаш устройство), но OpenSRO съобщава, че вашият сертификат не е инсталиран, тази ситуация може да възникне, ако решите да конфигурирате втория или третия си компютър (разбира се, подписът не „расте ” само на един компютър и може да се използва на множество компютри). Обикновено първоначалната настройка се извършва с помощта на техническата поддръжка на Сертификационния център, но да кажем, че това не е нашият случай, така че да тръгваме.

1. Уверете се, че CryptoPro CSP 4 е инсталиран на вашия компютър

За да направите това, отидете в менюто Започнете КРИПТО-ПРО CryptoPro CSPстартирайте го и се уверете, че версията на програмата не е по-ниска от 4.

Ако не е там, изтеглете, инсталирайте и рестартирайте браузъра.

2. Ако имате токен (Rutoken например)

Преди системата да може да работи с него, ще трябва да инсталирате необходимия драйвер.

  • Шофьори Рутокен: https://www.rutoken.ru/support/download/drivers-for-windows/
  • Шофьори eToken: https://www.aladdin-rd.ru/support/downloads/etoken
  • Шофьори JaCarta: https://www.aladdin-rd.ru/support/downloads/jacarta

Алгоритъмът е следният: (1) Изтегляне; (2) Инсталирайте.

3. Ако личният ключ е под формата на файлове

Частният ключ може да бъде под формата на 6 файла: header.key, masks.key, masks2.key, name.key, primary.key, primary2.key

Тук има една тънкостако се записват тези файлове твърд дисквашия компютър, тогава CryptoPro CSP няма да може да ги прочете, така че всички действия трябва да се извършат, като първо ги запишете на флаш устройство (сменяем носител) и трябва да ги поставите в папка от първо ниво, например: E :\Andrey\(файлове), ако е поставен в E :\Andrey\ ключове\(файлове), тогава няма да работи.

(Ако не се страхувате от командния ред, тогава сменяемото хранилище може да се емулира по следния начин: subst x: C:\tmp ще се появи нов диск (X:), който ще съдържа съдържанието на папката C:\tmp , той ще изчезне след рестартиране. Този метод може да се използва, ако планирате да инсталирате ключове в системния регистър).

Намерихме файловете, записахме ги на флашка и продължихме към следващата стъпка.

4. Инсталиране на сертификат от частен ключ

Сега трябва да получим сертификат, можем да направим това по следния начин:

  1. Отваряне CryptoPro CSP
  2. Отидете в раздела Обслужване
  3. Натиснете бутона Преглед на сертификати в контейнер, натиснете Прегледи тук (ако сме направили всичко правилно в предишните стъпки) ще имаме нашия контейнер. Натиснете бутона Следваща, ще се появи информация за сертификата и след това щракнете върху бутона Инсталирайте(програмата може да попита дали да предостави връзка към частния ключ, отговорете „Да“)
  4. След това сертификатът ще бъде инсталиран в хранилището и ще можете да подписвате документи (в същото време, в момента на подписване на документа, ще е необходимо флашката или токена да бъдат поставени в компютъра)

5. Използване на електронен подпис без токен или флашка (инсталация в регистъра)

Ако скоростта и лекотата на използване са малко по-високи за вас от сигурността, тогава можете да инсталирате личния си ключ в системния регистър на Windows. За да направите това, трябва да направите няколко прости стъпки:

  1. Извършете подготовката на частния ключ, описана в стъпки (2) или (3)
  2. След това отваряме CryptoPro CSP
  3. Отидете в раздела Обслужване
  4. Натиснете бутона копие
  5. С помощта на бутона Прегледизберете нашия ключ
  6. Натиснете бутона Следваща, тогава ще измислим някакво име, например „Pupkin, LLC Romashka“ и натиснете бутона Готови
  7. Ще се появи прозорец, в който ще бъдете помолени да изберете медия, изберете регистър,щракнете добре
  8. Системата ще попита Задайте паролаза контейнера, измислете парола, щракнете добре

Важна забележка:порталът OpenSRO няма да „види“ сертификата, ако срокът му на валидност е изтекъл.

За да инсталирате личен сертификат с връзка към частния ключ, използвайте приложението CryptoPro CSP. Можете да го стартирате в Windows OS, като отидете на Старт >> Всички програми >> CRYPTO-PRO >> CryptoPro CSP. В прозореца на приложението, който се показва, изберете раздела Обслужванеи натиснете бутона там Инсталирайте личен сертификат . След това трябва да посочите местоположението на файла със сертификата (файл с разширение .cer) и да щракнете върху бутона Следваща. Прозорецът със свойства на сертификата ви позволява да се уверите, че сте избрали правилен сертификат; След проверка натиснете отново бутона Следваща .

В следващия прозорец трябва да посочите ключов контейнер, съдържащ частни ключовепотребител.

ВАЖНО! Тази стъпка използва само сменяеми USB устройства или смарт карти и регистъра на операционната система.

Приложение CryptoPRO CSPверсия 3.9 ви позволява автоматично да намерите контейнера, като поставите отметка в съответното поле; по-ранни версии след щракване върху бутона Прегледпредоставя списък с налични носители, от които трябва да изберете този, от който се нуждаете. След като изберете контейнера, щракнете Следваща. Следващият прозорец ви позволява да зададете параметри за инсталиране на сертификата в магазина. След като изберете необходимото хранилище, щракнете върху бутона Следваща .

Следващата стъпка е окончателна и не изисква никакви действия освен натискане на бутон Готови .



Свързани публикации