Издадохме нова книга „Маркетинг на съдържанието в социалните медии: Как да влезете в главите на абонатите и да се влюбите във вашата марка“.

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

Какво е HTTPS

Това е защитен протокол за връзка. Той криптира информацията, обменяна между сървъра и браузъра на потребителя - това помага за защита на данните за пароли, номера на кредитни карти и имейл адреси. Използването на HTTPS е мощно и го прави малко по-привлекателен в очите на търсачките – Google класира защитените сайтове по-високо от незащитените. За да активирате HTTPS на вашия сайт, първо трябва да инсталирате SSL сертификат на сървъра.

За какво е SSL сертификат?

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

• домейн на сайта;
• пълно юридическо наименование на фирмата собственик;
• физическия адрес на фирмата;
• срок на валидност на сертификата;
• Подробности за SSL разработчик.

Ще ви е необходим и сертификат, за да се свържете с която и да е платежна система, например Yandex.Money. Логиката е проста – никой няма да ви позволи да рискувате парите на други хора.

Как да изберем SSL сертификат

Те са разделени на два вида, в зависимост от степента на защита и.

SSL за валидиране на домейн

Най-лесният вариант. Той ще работи, след като потвърдите собствеността на домейна. Това може да стане по три начина:

• Чрез имейл. Ще получите имейл с инструкции за потвърждение. Като адрес за изпращане е избрана или поща от домейна Whois, или пощенските кутии на администратора или уеб администратора.

• Чрез DNS запис. Ако имате конфигуриран имейл сървър, създайте персонализиран DNS запис. Системата ще го използва, за да потвърди, че наистина сте собственик на сайта. Методът е автоматизиран и е подходящ за тези, които имат скрита Whois поща в настройките си.

• Чрез хеш файл. Поставете специалния .txt файл на вашия сървър, така че сертифициращият орган да определи присъствието му.

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

Бизнес валидиране

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

• SSL с разширено валидиране. Това са сертификати за разширена валидация. Те са необходими на всеки, който работи с голяма сума пари: банки, големи онлайн магазини, финансови компании, платежни системи.

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

• САН ССл. Основното предимство на този тип сертификат е поддръжката на алтернативни имена на домейни: външни и вътрешни.

• SSL за подписване на код. Валидира кода и софтуерните продукти от сайта. Подходящ за разработчици на всякакви приложения.

Мога ли да инсталирам безплатен SSL сертификат на моя сайт?

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

Инсталирайте SSL сертификат

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

В процеса на генериране на CSR ключ трябва да посочите:

• Име на сървъра: "site.com" или "* .site.com", ако получите сертификат WIldcard. Звездичка означава произволен брой всякакви знаци преди точка.
• Код на държавата: RU, UA, KZ и така нататък.
• Регион, например Саратовска област.
• град.
• Пълното име на организацията или името на собственика на сайта.

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

След това трябва да инсталирате сертификата на уеб сървъра. Нека разгледаме случаите с Apache и nginx.

Apache

За да направите това, трябва да качите всички сертификати на сървъра: основни и междинни. На първо място, имате нужда от последното в директорията / usr / local / ssl / crt (използва се по подразбиране, във вашия случай може да е различно). Всички сертификати ще се съхраняват в него.

След това изтеглете основния сертификат, отворете го във всеки текстов редактор и напълно копирайте съдържанието заедно с редовете "BEGIN" и "END".

В директорията / ssl / crt / създайте файл vashsite.crt и поставете съдържанието на сертификата в него.

Преместете файла с частен ключ в директорията /usr / local / ssl / private /

Във вашия VirtualHost файл добавете редовете:

SSLEngine е включен

SSLCertificateKeyFile /usr/local/ssl/private/private.key

SSLCertificateFile /usr/local/ssl/crt/vashsite.crt

SSLCertificateChainFile /usr/local/ssl/crt/intermediate.crt

Трябва да посочите валидни пътища до файловете. Запазете промените и рестартирайте сървъра.

nginx

Тук процесът за инсталиране на SSL сертификат е малко по-различен. Първо, трябва да комбинирате основния, междинния и SSL сертификата в едно. За да направите това, създайте файл vashsite.crt и поставете там съдържанието на сертификатите заедно с редовете "BEGIN" и "END" (ред: SSL, междинен, root). Не трябва да има празни редове.

Трябва да направите почти същото с частния ключ - създайте файл vashsite.key и прехвърлете съдържанието на ключа, изтеглен от уебсайта на доставчика.

Поставете и двата файла (vashsite.crt и vashsite.key) в директорията / etc / ssl / (използва се по подразбиране, но може да се различава).

В конфигурационния файл редактирайте VirtualHost. добавете:

сървър (
слушай 443;
ssl включен;

ssl_certificate /etc/ssl/vashsite.crt;
ssl_certificate_key /etc/ssl/vashsite.key;
име на сървъра vashsite.com;

Ако директорията със сертификата и ключа е различна от тази по подразбиране, променете я.

Сега запазете промените и рестартирайте nginx.

Как да получите работеща HTTPS връзка

След инсталиране на SSL сертификати, сайтът ще бъде достъпен на два адреса: http://vashsite.com и https://vashsite.com. Трябва само да оставите последния. За да направите това, настройте файл robots.txt и направете 301 пренасочване от стария сайт.

В "роботи" трябва да актуализирате хоста. Пример: Хост: https://vashsite.com. За да настроите пренасочване, добавете следните редове към файла .htacsess:

RewriteCond% (SERVER_PORT)! ^ 443 $

RewriteRule ^ (. *) $ Https://vashsite.com/$1.

Сега остава да информираме търсачките за промените. В "Уеб администратора" на "Яндекс" добавете страница с https и я посочете като основна за стария сайт.

Резултати

Разбрахме какво е https, как да го инсталираме на вашия уебсайт и как да конфигурирате всичко правилно. Този протокол вече се превърна в стандарт за връзка и с течение на времето всички сайтове на живо ще преминат към него. Този процес се насърчава от търсачките – наличието на сигурен протокол за HTTPS връзка се превърна в един от факторите за класиране. Следователно, ако искате да стигнете до върха, ще трябва да го инсталирате.

Приятни новини от ноември 2016 г. за нашите скъпи клиенти и потребители на сайта. Нашият онлайн магазин не стои на едно място, като редовно актуализира не само гамата от продуктови предложения, но и разширява функционалността на сайта, неговата безопасност за потребителите и значението му в глобалната интернет система. И така, на 26 септември 2016 г. сайтът на онлайн магазина получи SSL сертификат с разширена проверка, а от 1 ноември 2016 г., след тестване и подобряване на алгоритмите, свързахме платежни системи към сайта!

Сега нека разгледаме по-отблизо необходимостта от тези действия и какви предимства получават нашите ценни клиенти от това?

Основното визуално предимство, което всеки клиент може да забележи е възможността да плати ОНЛАЙН с банкова карта всяка поръчка от нашия онлайн магазин и да я занесе на удобен адрес. Що се отнася до вътрешното, скрито достойнство на актуализациите на сайта - SSL сертификатът е специален начин за криптиране на сайт между глобалния интернет, браузър и потребител на сайта, с други думи, това е, че сайтът вече е защитен от възможността за атака и изземване на вашата платежна (и дори контактна) информация на трети страни. За да получи SSL сертификат, нашият сайт трябваше да премине през проверка на реалното съществуване на организацията, потвърждение за получаване и обвързване на сертификата към домейна и интегриране на новата система за защитен сайт в познатия на всички сайт. Оттук нататък потребителите на нашия сайт могат да бъдат напълно уверени в безопасността на използването на нашия удобен и модерен сайт, да правят покупки и да не се страхуват от изтичане на данните си на трети страни.

Между другото, ние също не стоим неподвижни в разширяването на възможностите за получаване на нашите поръчки, а през есента на 2016 г. започнахме да предлагаме на нашите клиенти възможността да получават поръчки по нови методи за доставка - куриерската услуга CDEK и чрез колет inPost терминали. И двете услуги присъстват в много големи градове на Русия, цената на техните услуги е много демократична, а скоростта на работа понякога удивлява дори феновете на скъпи и висококачествени куриерски услуги! Съветваме ви да изпробвате нови начини за доставка, това ще ви спести време и пари и ще ви даде приятно изживяване при получаване на стоката.

Сайтът на нашия онлайн магазин е модерна, динамично развиваща се компания, предлагаща на нашите клиенти най-модерните и безопасни начини за плащане и получаване на нашите поръчки. Следете за актуализации, които ще бъдат грандиозни и глобални, както за разширяване на асортимента, така и за предоставяне на повече възможности за нашите ценни клиенти !!

Можете да започнете малък бизнес. Например организирайте препродажбата на домейни и SSL сертификати. Намирате клиенти за съществуващи продавачи и получавате възнаграждение под формата на отстъпки и маржове - с други думи, вие ставате дистрибутор. Можете бързо да настроите домейни на дистрибутори и SSL сертификати, като използвате софтуера на ISPsystem.

Важно!Препоръчваме да започнете не с техническата реализация, а с бизнес модела и правната страна на въпроса. Определете целевата аудитория и начините да я привлечете, разработете ценова политика, която е от полза за вас и вашите клиенти. Проучете правната и счетоводна рамка. Едва след това пристъпете към техническото изпълнение на плана.

Какво ви трябва, за да започнете

За да станете търговец на домейни и SSL сертификати, ще ви трябва:

1. виртуален сървър (VPS/VDS),
2. споразумение с продавачите на домейни и SSL сертификати,
3. споразумение с платежната система,
4. платформа за фактуриране за приемане на плащания,
5. уебсайт за продажба на услуги.

Инсталиране и конфигуриране на софтуер

За да препродадете домейни и SSL сертификати, ще трябва да инсталирате BILLmanager на нает виртуален сървър.

Интеграция с продавачи на домейни и SSL

За да настроите интеграцията, използвайте данни от търговците на домейна и SSL, с които сте сключили споразумение. Обикновено интеграцията изисква URL за достъп до API, код на дистрибутора и ключ за оторизация на API. Данните могат да варират в зависимост от компанията.

След това в BILLmanager в менюто Интеграция - Манипулатори на услугище можете да настроите препродажба.

Можете също да започнете да препродавате SSL сертификати чрез ISPsystem. Няма да е необходимо да преговаряте директно с регистратора. За да направите това, в секцията „Обработващи услуги“ изберете BILLmanager 5 и въведете данните за личния си акаунт my.ispsystem.com.

Свързване на платежни системи

За да позволите на клиентите да плащат за услуги, настройте методи на плащане. BILLmanager съдържа повече 30 модулаплащане: Yandex.Money, WebMoney, PayMaster, Qiwi, PayPal, Банков превод и други.

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

Клиентите ще прехвърлят средства от своята сметка към вашата. Получаването на средства ще бъде отразено във вашата сметка и в клиентската сметка в BILLmanager.

За да получавате плащания от физически лица, можете да свържете прости електронни системи като Yandex.Checkout или WebMoney. Юридическите лица плащат за услуги по банков път според фактурата, следователно, за да работите с тях, свържете метода на плащане с банков превод (Руска банка). Попълнете банковите данни на вашата организация. Връзка с платежни системи.

Настройка на шаблони на документи

BILLmanager има предварително дефинирани шаблони на документи: фактури, сертификат за завършена работа, сертификат за съгласуване, споразумение за услуги, анекси към споразумението. Моля, редактирайте ги според вашите условия за ползване.

За да спазвате законовите изисквания, създайте и публикувайте на вашия сайт Политика за поверителности Условия за ползване... Добавете връзка към тези документи към менюто Настройки - Настройки на марката - Авторско право... Когато изготвяте политика за обработка на лични данни, следвайте препоръките на Роскомнадзор. Персонализиране на шаблони за документи и съобщения

Персонализиране на шаблони за поща и съобщения

BILLmanager съдържа над 60 шаблона за създаване на бюлетини. Клиентите ще получават писма при регистрация, поръчка на услуги, фактуриране. Billing ще ви уведоми за края на услугата. Можете също да персонализирате шаблони за SMS съобщения и масови съобщения. В панела можете да промените типа на съобщенията.

Настройване на интеграция на сайта

Интеграция със сайта

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

Карти за продукти и услуги

Можете бързо да поставите цени на сайта с помощта на инструмента за витрина. Инструментът ви позволява да добавите карта с една или няколко услуги към сайта, така че потребителят да може да избере тази, от която се нуждае и да поръча. Цените в картите се актуализират автоматично.

За да добавите карта, трябва да поставите специален скрипт на мястото, където искате да я покажете. Скриптът може да бъде намерен в документацията: Интегриране на магазина в съществуващ сайт.

Брандиране

Когато преминават от вашия уебсайт към личния си акаунт в BILLmanager, клиентите може да почувстват несъответствие: уебсайтът и фактурирането са проектирани по различен начин, адресът за фактуриране съдържа IP адреса на сървъра и се различава от адреса на уебсайта.

За да „изравните“ стиловете, конфигурирайте марката: добавете логото си към фактурирането, променете цвета на интерфейса, публикувайте връзки към сайта. За да направите URL адреса за фактуриране същият като на уебсайта, конфигурирайте адреса за BILLmanager. Например CloudLite има адрес на уебсайт cloudlite.ru, адрес на плащане - myvdc.cloudlite.ru.

Напоследък трябва да се справяме с HTTPS / SSL със завидна редовност. Всеки път обаче, когато дойде такъв проект, успявам да забравя как се прави. За да улесня възстановяването на знания в паметта, реших да преведа материали от тук. Постепенно обаче преводът се отдалечава от оригинала.

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

Симетричният ключ се генерира по време на ръкостискането и е валиден само за една SSL сесия. Ако сесията не остане активна, ключът изтича (изтича). Максималното време, след което SSL сесията изтича (изтича), може да се посочи. След изтичане на сесията ръкостискането трябва да се повтори отначало. Настройката на сесията води до нов симетричен ключ.

Сертификати и ключове

Преди да се потопим в детайлите на SSL, трябва да представим концепцията за ключове и сертификати. SSL / TLS използва асиметрично криптиране за удостоверяване и симетричен обмен на ключове, които ще се използват за криптиране на данни по време на сесия.

Използване на асиметрично криптиране двойки ключовеза криптиране - частен ключ и съответен публичен ключ. Данните, криптирани с един ключ, могат да бъдат декриптирани с двоен ключ. По същия начин данните, подписани с един ключ, могат да бъдат проверени с втори ключ. Частният ключ, както подсказва името му, трябва да се пази в тайна.

Сертификати.

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

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

Има два вида сертификати.

• Официално издадени сертификати, подписани от организация на сертифициращ орган
• Самоподписани сертификати

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

Доверие

Ключовата концепция за SSL връзка е концепцията за доверие на сертификат. Важен е начинът за получаване на сертификата, използван за връзката. Ако получите сертификат от доверен източник, например лично от собственика на сайта, можете да сте сигурни, че сертификатът е истински и че наистина се свързвате с този сайт. Въпреки това, когато се установява връзка от уеб браузър, например, сертификатът на сървъра може да бъде получен от самия сървър, към който се свързвате. Възниква въпросът за автентичността на сертификата. Ами ако хакер създаде своя собствена асиметрична двойка ключове и след това направи свой собствен сертификат, за да излъже сървъра на банката?

Моделът на доверие е прост. Всеки клиент или сървър решава, че има доверие на определени сертифициращи органи (CA) за издаване на сертификати. Да се ​​доверите на CA означава да вярвате, че всички издадени от CA сертификати са законни и че идентифициращата информация в сертификата е правилна и надеждна. Verisign е пример за CA, който подписва много сертификати за големи интернет компании. Всички браузъри се доверяват на Verisign по подразбиране. Идентичността на сертификата съдържа цифров подпис, генериран от CA. Клиентът или сървърът се доверява на CA, като добавя сертификата към файл на магазина, наречен 'truststore'. Съхраняването на сертификата на CA в truststore позволява на Java да провери цифровия подпис на сертификата, генериран от CA, и да реши дали да се довери на сертификата или не.

Ако хакер постави фалшив сертификат за банката на Barclay, вашият браузър ще се опита да провери цифровия подпис на сертификата. Тази проверка ще бъде неуспешна, защото няма сертификат в хранилището за доверие, което е подписало сертификата на нападателя.

Верига от сертификати

На практика форматът на сертификатите е такъв, че в сертификат могат да бъдат включени множество подписи. Сертификатът съдържа не един подпис, а определена "верига от сертификати"

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

По-късно, след генериране на заявка за подписване на сертификат (CSR) и получаване на отговор от сертифициращия орган (CA), самоподписаният сертификат се заменя с верига от сертификати. Към веригата се добавя сертификат от CA, който потвърждава автентичността на публичния ключ, последван от сертификат, който потвърждава автентичността на публичния ключ на CA.

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

Нека да разгледаме по-задълбочено SSL. Има два вида SSL връзки.

Проста автентификация (еднопосочно SSL удостоверяване)

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

Клиентът проверява самоличността на сървъра, преди да установи криптирана връзка.

Двупосочна SSL автентификация

При този тип удостоверяване както сървърът, така и клиентът предоставят сертификати за взаимно удостоверяване, преди да установят криптирана връзка.

Проверка на сертификат

При еднопосочно удостоверяване (първият тип) сървърът има сертификат със сдвоен частен ключ. Данните, криптирани с публичния ключ на сървъра, могат да бъдат декриптирани с частния ключ на сървъра. Клиент, който желае да установи връзка със сървър, проверява сертификата на сървъра, преди да продължи да установява криптирана връзка. Клиентът трябва да провери следното:

• валиден ли е сертификатът (датата на изтичане)
• Сертификатът, предоставен от сървъра, наистина съответства на неговото име на хост.
• Има ли организация, която е издала сертификата на CA в списъка, на който клиентът има доверие?
• Проверете цифровия подпис на сертификата

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

При двупосочно удостоверяване клиентът и сървърът притежават частните ключове и сертификати. И двамата проверяват взаимно сертификатите си, преди да установят криптирана връзка. Клиентът извършва описаните по-горе проверки и сървърът извършва същите действия върху клиентския сертификат.

Заявка за подписване и подписване на сертификати

Създаването на ключове и сертификати е регламентирано от стандарти.

Ключовете се генерират според PKCS....

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

Ако CA (сертифициращ орган) реши да се довери на заявката за подписване на сертификат (CSR), резултатът е издаването на подписан сертификат с идентичността, предоставена в CSR. Сертификатът се регулира от стандарта X.509.

SSL СИГУРНО ЦИФРОВО СЕРТИФИКАЦИЯ

За сигурно предаване на данни между браузъра и уеб сървъра се използва протоколът за пренос на данни https, който се основава на защитена SSL връзка.

Тази статия предоставя преглед на криптирането с публичен ключ, цифровите сертификати, инфраструктурата на публичните ключове (PKI), създаване на CA, конфигуриране на Apache Tomcat и JBoss сервлет контейнери за установяване на еднопосочни и двупосочни защитени връзки, генериране на хранилище за сертификати и как за да създадете SSL сертификат с помощта на помощната програма keytool. Ще научите също за начините за проверка на отменени сертификати в Java (CRL списъци, OCSP протокол) и конфигуриране на браузъра да работи със сертификати.

Криптирането с публичен ключ е модерен начин за сигурно предаване на съобщения през мрежата. Същността на метода се крие в наличието на двойка ключове: публичен и частен. Публичният и частният ключ са алгоритми за преобразуване на оригиналното съобщение в криптираното и криптираното съобщение в оригиналното.

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

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

Съобщение, криптирано с частен ключ, може да бъде декриптирано от всички притежатели на публичния ключ.

На базата на този алгоритъм за криптиране се създава защитена SSL връзка.

Цифров сертификат

Цифровият сертификат е електронен документ, който идентифицира собственика. Той съдържа основна информация за собственика, публичния ключ на собственика, датите на валидност, цифров подпис на издателя (издателя) и друга необходима информация. Цифровият сертификат има секция за разширения (по избор), която съдържа точки за разпространение на списък за анулиране, информация за издателя и др. Цифровият сертификат ви позволява да установите защитена SSL връзка. Как да създадете SSL сертификат е описано по-долу в тази статия.

Основни характеристики на горните сертификати:

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

SSL сертификатите на сървъра в полето CN (общо име) трябва да съдържат името на домейна или ip-адреса, на който е адресиран сървърът, в противен случай сертификатът ще бъде анулиран;

Клиентските SSL сертификати съдържат имейл адреса на клиента, име и фамилия. За разлика от сертификат за сървър, полето CN не е критично за съдържанието и може да съдържа както име, така и фамилия и имейл адрес.

Цифров SSL сертификат се счита за валиден в рамките на срока на валидност, посочен в неговите полета. По този начин сертификатът не може да се използва преди началната дата на валидност и след датата на изтичане, т.к системите, които влизат в контакт с него, ще докладват за недоверие към него.

Има ситуации, когато потребител или издател на сертификат трябва да спре или напълно да спре неговата валидност. Да кажем, че частен ключ, който трябва да се съхранява сигурно, е загубен или достъпен от хакери. В такава ситуация потребителят трябва да се свърже с издателя (издателя) на сертификата, за да може последният да отмени действието си. Също така, издателят може да отмени сертификата, ако се окаже, че клиентът е предоставил фалшива информация за себе си. За тези цели се създава специален списък, наречен списък с отменени (анулирани) сертификати (English Certificate revocation list, CRL). Този списък съдържа серийния номер на сертификата, датата на изтичане и причината за анулирането. От момента, в който сертификатът влезе в CRL, той се счита за невалиден и издателят не носи отговорност за съдържанието на такъв сертификат. Един от методите за проверка на CRL списъка е OCSP протоколът, но това изисква присъствието на CA на OCSP отговорника.

Инфраструктура за публичен ключ (PKI)

Основната цел на инфраструктурата с публичен ключ (PKI) е да дефинира политика за издаване на цифрови сертификати.

За издаване и отмяна на SSL сертификати, генериране на списъци за анулиране (CRL), имате нужда от специален софтуер (софтуер). Примери за такъв софтуер са Microsoft CA (включен в MS Windows Server 2000/2003/2008), OpenSSL (разпространяван на unix-подобни операционни системи). Този софтуер се намира на оборудването на сертифициращия център.

Сертифициращият орган (CA) е организация, която издава цифрови SSL сертификати въз основа на данните, предоставени от клиента. Сертифициращият орган носи пълна отговорност за точността на данните, представени в SSL сертификата, което означава, че собственикът на сертификата е точно този, за когото се представя.

Най-често срещаните CA в света са Verisign и Comodo. На тези CA се доверяват 99% от браузърите и повечето сървърен софтуер. Създаването на сертифициращ орган е описано по-долу.

SSL защитена връзка с двупосочна автентификация

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

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

Фигурата е диаграма, която показва стъпките за създаване на защитена SSL връзка.

Фигура 1 - Схема за създаване на защитена SSL връзка с двупосочна автентификация

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

В тази схема предаваните данни са двойно криптирани. Клиентът криптира съобщението с публичния ключ на сървъра и след това със собствен частен ключ. След получаване на съобщението сървърът декриптира съобщението с публичния ключ на клиента и след това със собствен частен ключ. По този начин сървърът и клиентът се удостоверяват един пред друг, тъй като само те могат да дешифрират получените данни.

Трябва да се отбележи, че използването на тази техника намалява скоростта на обмен на данни, т.к операциите по криптиране/декриптиране изискват допълнително време и скоростта на тяхното изпълнение зависи от мощността на изчислителните ресурси.

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

За целите на тестване или когато е непрактично да закупите цифров сертификат, трябва да създадете свой собствен CA.

Root CA е CA, на който всички вярват. Той притежава SSL сертификат, който е подписан от собствения му частен ключ. Такива SSL сертификати се наричат ​​самоподписани.

Частният ключ на основния CA трябва да се съхранява много сигурно, т.к ако бъде загубен или откраднат, доверието във всички подчинени SSL сертификати се губи.

Подчинен CA - CA, който издава SSL сертификати на клиенти. Сертификатът на подчинения CA е подписан с частния ключ на по-висшестоящия CA. Като клиенти на подчинения сертифициращ орган могат да действат сертифициращи органи, уеб сървъри, уеб браузъри, пощенски клиенти, за които се генерират сертификати от необходимия тип. Видовете сертификати се определят от политиката на сертифициращия орган.

От горното следва, че се създава верига от сертификати от основния CA до крайния клиентски сертификат.

Фигура 2 - Верига от сертификати

За да създадем CA, ще използваме двустепенната схема, показана на фигура 3. В тази схема има главен CA и подчинен CA (издаване CA). Основният CA подписва свой собствен SSL сертификат и SSL сертификати на подчинени CA. Трябва да се отбележи, че колкото повече слоеве се използват, толкова по-сигурна е схемата.

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

Фигура 3 - Двустепенна схема на сертифициращия център

Пример за организиране на сертифициращ орган на базата на CA на Microsoft може да бъде намерен в статията „Разгръщане на верига от сертифициращи органи, базирани на CA на Microsoft“.

Получаване на сървърен SSL сертификат от сертифициращ орган и конфигуриране на контейнера за сървлет

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

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

Основното поле, което трябва да бъде попълнено правилно, се нарича Common Name (CN). В това поле трябва да посочите името на домейна или IP адреса на хоста, където се намира контейнерът за сървлет.

Можете да използвате помощната програма keytool от JDK (кит за разработка на Java), за да генерирате частни и публични ключове и да поискате SSL сертификат.

В командния ред въведете следната команда:

$ JAVA_HOME \ bin> keytool -genkey -псевдоним -keyalg -хранилище за ключове

Фигура 4 - Създаване на хранилище за SSL сертификати с помощта на помощната програма keytool

Тази команда keytool създава хранилище за сертификати с име , който съхранява частния ключ и самоподписан SSL сертификат, криптиран с помощта на RSA алгоритъма. Можете да се обърнете към SSL сертификата по име .

По време на създаването на хранилището, помощната програма keytool ще ви помоли да въведете парола за достъп до трезора, информация за организацията и парола за секретния (частен) ключ. Когато отговаряте на въпроса за помощната програма keytool "Какво е вашето име и фамилия?" трябва да въведете името на домейна или ip-адреса на хоста, т.к стойността на отговора ще се използва като полето CN на SSL сертификата.

След като помощната програма keytool генерира хранилище с ключове, трябва да генерирате заявка до сертифициращия орган за подписване на SSL сертификат. Това става с командата:

$ JAVA_HOME \ bin> keytool -certreq -keyalg RSA -псевдоним -файл -магазин за ключове

Във файла заявката за сертификат е запазена. След това на сайта на сертифициращия център се попълва специален формуляр, в едно от полетата на което се копира съдържанието на този файл.

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

Фигура 5 - Схема за получаване на сървърен сертификат

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

1) добавяне на сертификата на основния сертифициращ орган с помощта на помощната програма keytool: $ JAVA_HOME \ bin> keytool -import -trustcacerts -alias rootca -file -магазин за ключове

2) добавяне на сертификата на междинния сертифициращ орган с помощта на помощната програма keytool: $ JAVA_HOME \ bin> keytool -import -trustcacerts -alias subca -file -магазин за ключове

3) замяна на самоподписания сертификат със сертификат, подписан в сертифициращия орган (посочена е стойността на параметъра псевдоним, който е бил използван при създаването на хранилището): $ JAVA_HOME \ bin> keytool -import -trustcacerts -alias -файл -магазин за ключове

За да могат приложенията да използват защитена SSL връзка, контейнерът за сървлет трябва да бъде конфигуриран. За Apache Tomcat и JBoss добавете следното съдържание във файла server.xml:

clientAuth = "false" sslProtocol = "TLS"

keystoreFile = " "

keystorePass = " "

keystoreType = "JKS"

keyAlias ​​= " "

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

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

maxThreads = "150" схема = "https" secure = "true"

clientAuth = "true" sslProtocol = "TLS"

keystoreFile = "

keystorePass = " "

keystoreType = "JKS"

keyAlias ​​= " "

truststoreFile = "

truststorePass = " "truststoreType =" JKS "

В тази конфигурация е зададен параметърът clientAuth = "true" и хранилището за доверие е свързано. Помощната програма keytool създава хранилище от доверени SSL сертификати по същия начин като обикновеното хранилище. Той трябва да добави сертификати на CA, които издават цифрови сертификати, на които контейнерът за сървлет трябва да има доверие. В противен случай предоставените SSL сертификати ще бъдат отхвърлени от контейнера за сървлет по време на удостоверяване. няма да има доверие в тях.

Проверка на анулирани сертификати на сървъра

Има 3 начина да проверите сертификат за анулиране: статична CRL проверка, динамична CRL проверка, OCSP проверка. Нека разгледаме тези методи по-подробно.

1) Статична проверка на CRL

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

За да свържете CRL в Apache Tomcat и Jboss servlet контейнери, добавете атрибут към ssl конектора:

crlFile = ”

Недостатъкът на този метод е необходимостта администраторът постоянно да следи актуализацията на CRL файла.

2) Динамична проверка на CRL

Този метод позволява автоматична проверка на CRL. Това изисква атрибутът CRLDistributionPoint да бъде посочен в секцията за разширения, предоставена от SSL клиента, който посочва URL адреса, където се намира списъкът за анулиране на сертификати (CRL).

За да може клиентският SSL сертификат да бъде валидиран в CRL, трябва да бъдат конфигурирани два параметъра за виртуалната машина на Java. Тези параметри могат да бъдат посочени в скрипта за стартиране на контейнера на сървлет. За Apache Tomcat и Jboss на Windows това изглежда така:

задайте JAVA_OPTS =% JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation = true

Dcom.sun.security.enableCRLDP = true -Djava.security.debug = certpath

Параметърът java.security.debug = certpath ви позволява да наблюдавате удостоверяването на сертификата в конзолата на работещия контейнер.

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

3) Проверка с помощта на протокола OCSP

Протоколът за статус на онлайн сертификат (OCSP) е разработен като алтернатива на CRL. Тази проверка се поддържа от JSSE (Java Secure Socket Extension) технология от JDK 5. OCSP работи във връзка с CRL. До CRL се осъществява достъп, когато възникне грешка по време на комуникация през OCSP. Ако OCSP е определил състоянието на SSL сертификат, CRL проверката не се извършва. Сертификатът може да има един от трите статуса: анулиран, нормален, неизвестен.

За валидиране на OCSP сертификатът трябва да има атрибут AuthorityInfoAccess в секцията за разширения със стойността на URL адреса на OCSP отговора.

OCSP-responder - софтуер, разположен в мрежов ресурс на сертифициращ орган, който обработва заявки за определяне на статуса на сертификат и предоставя резултати от проверка.

За да може виртуалната машина на Java да извърши проверка на OCSP, свойството ocsp.enable трябва да бъде настроено на true. Това свойство е конфигурирано във файла JAVA_HOME \ jre \ lib \ security \ java.security. В този файл можете да регистрирате адреса на OCSP отговорника в свойството ocsp.responderURL. Това свойство ще се използва, ако в SSL сертификата няма URL адрес на отговор.

Получаване на клиентски SSL сертификат от центъра за сертифициране и конфигуриране на уеб браузъра

Има ситуации, когато не само сървърът трябва да потвърди, че е този, за когото твърди, че е, но и когато сървърът изисква от клиента да потвърди самоличността си с цифров сертификат.

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

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

Фигура 6 - Схема за получаване на SSL клиентски сертификат

Като пример ще инсталираме клиентския SSL сертификат в уеб браузъра на Microsoft Internet Explorer. За да направите това, изберете Инструменти> Интернет опции от менюто. В раздела "Съдържание" изберете "Сертификати ...".

Фигура 7 - Управление на SSL сертификати в MS Internet Explorer

Стартирайте съветника за импортиране на сертификати, като щракнете върху бутона "Импортиране...". В този съветник указваме пътя към сертификата на основния сертифициращ орган. След това изберете магазина "Доверени коренни сертифициращи органи", за да добавите сертификат към него.

По същия начин междинните CA сертификати се добавят към хранилището на междинните удостоверяващи органи, а сертификатът на клиента към личния магазин.

Фигура 8 - Верига за сертифициране

За да видите съдържанието на сертификата, изберете необходимия SSL сертификат и щракнете върху бутона „Преглед“.

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

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

Проверка на анулирани сертификати на клиента

Ако клиентът използва уеб браузъра MS Internet Explorer, тогава той може да бъде конфигуриран да проверява изпратените сертификати в CRL. За да направите това, отидете в раздела „Разширени“ в свойствата на браузъра и проверете двата атрибута „Проверка за анулиране на сертификати на издатели“ и „Проверка за анулиране на сертификати на сървъра“.