SSL сертификат уеб-сайтове и тяхното използване от центъра на сертифициране и експлоатация сертификати

Това съдържание е част от поредица: SSL сертификати на уеб сайтове и тяхното използване

Останете на линия за предстоящите статии в тази серия.

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

Назначаване на SSL сертификати

Често използвани съкращения.

SSL - Secure Sockets Layer (защитен слой гнездо);
CA - сертифициращ орган (в центъра на властта);
КСО - искане за сертифициране (заявка за подписване на сертификат);
CRL - CRL (сертификат списък отнемане);
PKCS - стандартни криптографски публичен ключ (публично-ключовите стандарти криптография).

След като създадете свой собствен CA единен център, подписването ще се появи в компанията на която сертификатът ще има същата сила, както подпис VeriSign, но в рамките на организацията. Това е достатъчно, за да бъде удължен до всички компютри и мобилни устройства, самостоятелно подписан сертификат "родния" Калифорния, обявявайки своя корен, както и всички ключове, които са били или ще бъдат подписани в бъдеще, те автоматично ще бъдат "безопасни", защото те принадлежат към може да бъде проверена. Тя също така ще даде възможност да се създаде списък с прекратени удостоверения, които се проверяват автоматично при създаване на защитена връзка.

VeriSign собствено вземане

Като цяло, процедурата е следната: клиентът, който желае да получи удостоверение, генерира CSR (по този начин също така да създадете ключ сертификат) и изпраща на КСО на СО CA получи CSR, влезте него и да създадете свой собствен сертификат, който се изпраща обратно на клиента. Има и друг вариант: клиент веднага генерира ключ сертификат, сертификат, и всичко това заедно с удостоверение CA опаковани файлов формат PKCS # 12 (.p12 разширение), защитен с парола и се изпраща на клиента.

При създаването на своя собствена Калифорния ще трябва да се създаде структура директория за съхранение на следните данни:

получени искания за сертифициране (КСО);
подписани сертификати (CRT);
Списъкът с анулирани сертификати (CRL);
собствен частен ключ CA. сертификат

Обява 1 показва структурата на директориите създаден модул apache1 mod_ssl, но може да се използва всяко име.

Обява 1. Създайте директория за АК

След създаването на необходимите директории трябва да се направят промени в OpenSSL конфигурационния файл. Обява 2 показва три фрагмента openssl.cnf файл: стандарт CA_default и две допълнителни раздел ssl_server и ssl_client.

Обява 2. конфигурация файл фрагмент openssl.cnf

В Обявата 2, с изключение на инсталационни пътеки по подразбиране, се добавят две нови секции - [ssl_server] и [ssl_client]. което определя параметрите на сертификати, в зависимост от режима на работа на програмата, която ще го използвате. Web-сървър и сървър за електронна поща се предположи сертификата на сървъра, както и клиенти за електронна поща - напротив, на клиента.

Настройка параметри в секции [ssl_server] и [ssl_client], произведено в съответствие с мъж x509v3_config. При използване на crlDistributionPoints параметър стойност трябва да съдържа връзка към обществена CRL на CA. CRL ще бъде използвано от програмите, които имат такава възможност (например, уеб браузъри), за да се провери списъците с невалидните сертификати, както и когато се опитате да използвате отнет сертификат връзка се установява, няма да има, вместо това, ще получите съобщение за грешка.

В Обява 2, името на файла на сертификата за Калифорния - caserv.crt. име на файла на сертификата за Калифорния с ключ - caserv.key и името на файла от референтната лаборатория на Общността - cacrl.pem. Програми не са в състояние да използват CRL файл, като се използва т.нар файл MCF (обединен контрол на файла - комбинираното устройство за управление на файлове), който е прост поредна сертификат и CRL за CA. MCF-файл е създаден от командата котка. както е показано по-долу:

След промяна на конфигурационния файл, трябва да създадете майсторско свидетелство Калифорния, който ще подпише всички други сертификати. процес на създаване е показано на Обявата 3:

Обява 3. Създаване на майсторско свидетелство CA

След създаването caserv.key файл трябва да бъде поставен в ssl.key директория. задаване на разрешения 0400 и го защитават от неоторизиран достъп. caserv.crt файл. напротив, трябва да се предоставят на разположение на обществеността и поставя като основен сертификат за всички устройства, които имат достъп до корпоративната мрежа.

Също така трябва да се създаде индекс файл от базата данни с подписания сертификат (името на този файл е посочена в раздела за параметър на базата данни [CA_default]) и файл с текущата серийния номер (на името на този файл е посочено в [CA_default] параметър сериен раздел). Обява 4 показва командите, за да се създадат два файла.

Обява 4. Създайте индексен файл и файла на текущата сериен номер CA

След тези стъпки, за да се създаде сертификат от сертифициращ орган е готов за подписване.

Създаване на сертификати

Първият начин за създаване на удостоверението се използва, когато има възможност за създаване на КСО директно на клиентската машина - това е обикновено компютри, работещи UNIX или Linux. Обява 5 показва командата за създаване на КСО.

Обява 5. Създаване на CSR директно на клиентски компютър

Обява 5 създава нова КСО, която ще бъде записана в myfile.pem файл. и сертификат RSA ключ, с дължина 1024 бита. CSR контролна се изчислява, като се използва алгоритъм SHA1. Най-важният параметър е -nodes на параметрите. което показва, че ключът е защитена с парола (за сървър обикновено се зарежда при стартирането на съответните програми и подкана за парола може да спре процеса на стартиране). По време на създаването на КСО ще бъде много въпроси, отговорите на които ще бъдат включени в КСО, а впоследствие се използват.

Генериран КСО файл myfile.pem бъдат прехвърлени към сървъра, на който е инсталиран на СО, и въведена в поддиректория ssl.csr. След това можете да подпише сертификата, както е показано в пример 6.

Обява 6. Client Client подписа на сертификата по свой собствен CA

Защото в -extensions параметър определя името на секцията за сертификат на сървъра ssl_server. и за сертификата за клиентската - ssl_client. Създаден само две опции за сертификати: а текстовата част - myfile.pem и без текстовата част - myfile.crt. със сертификата в същия формат може да се превърне в друг формат. За да подпише сертификата трябва да въведете паролата от главния CA даден сертификат. След като се регистрирате всички готови сертификат (или и двете) може да бъде изпратен обратно на клиента за използване в програми.

Вторият начин за създаване на сертификати, използвани при създаването на КСО директно на клиентския компютър не е възможно (не-UNIX системи, мобилни устройства, разнообразие от мрежово оборудване). В този случай, на компютъра, на който работи ТЗ създава КСО, и подписан сертификат (екипът създаде КСО и сертификат за подписване е идентична с по-горе, само -extensions име параметър се използва ssl_client раздел). След създаването на сертификат създадени файлове, както и удостоверение от ТЗ ще архивирате PKCS # 12 формат и се изпраща на клиента. Това е най-уязвими от гледна точка на сигурността на мястото: удостоверението се изпраща заедно с ключа, и защитен с парола архив само! Командата за създаване на PKCS # 12 файла е показана на Обява 7:

Обява 7. Създаване на PKCS # 12 файл

Обява 7 създава архив myfile.p12 в парола 123456. сертификат, съдържащ myfile.crt. myfile.key ключ сертификат и ключ CA caserv.crt. Този файл се изпраща на клиента и да зададете инструменти на операционната система на клиента.

Преглед на сертификати. Списък с анулирани сертификати

Моля, имайте предвид, че само по себе си не генерира мнения експлоатация и актуализации този списък, тъй като произвежда само на необходимите операции в индекс файла, посочени в раздел CA_default параметъра база данни. Изисква се едно действие да се извърши актуализиране на списъка. оттегляне се извършва по начина, показан по-долу:

В този пример, сертификат за отмяна е в myfile.pem файла наред с други сертификати, подписани от CA. Като причина за отмяна (crl_reason), можете да зададете следните стойности:

неуточнено - тази опция се използва, когато стойността на параметъра е неправилна или пропуснато;
keycompromise, cacompromise / - компромис ключов или CA;
affilationchanged - преминаване към друг СА;
заменено - подмяна сертификат (например след изтичане);
cessationofoperation - прекратяване на служебното правоотношение.

След отмяната е необходимо да се актуализира списъка с анулирани сертификати, или да го създаде, ако тя все още не е бил няма коментари, както е показано по-долу: