Базовий контроль сертифіката Базовий контроль сертифіката виконується всім сертифікатів послідовності і складається з низки перевірок . Перевірки, що використовують кожну з чотирьох груп змінних стану, виконуються, щоб визначити, чи не є

Перевірка терміну дії сертифіката Ця перевірка завершується успішно, якщо поточна дата та час на момент валідації знаходяться в межах терміну дії

Перевірка статусу сертифіката Ця перевірка завершується успішно, якщо видавець не анулював цей сертифікат. Основним засобом перевірки статусу сертифіката є списки САС, але можуть використовуватись інші альтернативні засоби

Перевірка підпису сертифіката Підпис сертифіката може бути перевірена на базі першої групи змінних стану за допомогою відкритого ключа видавця сертифіката, використання коректних параметрів та алгоритму цифрової

Підготовка наступного сертифіката Спершу виконується деяка проста перевірка сертифіката УЦ. Потім оновлюються змінні стани, щоб вони могли відображати значення полів додатків сертифіката. Існує кілька доповнень, що зустрічаються

Завершення обробки сертифіката Коли завершується обробка сертифіката кінцевого суб'єкта, на підставі значень змінних стану встановлюються вихідні значення. Коригування змінних стану верифікації цифрового підпису. У полі інформації про

3.3.1. Формат RSS Читати новини можна по-різному. Найпростіший спосіб – заходити час від часу на сайт та переглядати нові повідомлення. Можна поставити програму, яка підключається до каналу новин і сама отримує заголовки або анотації новин, за

Формат сертифіката Х.509 Х.509 – це інший дуже поширений формат. Усі сертифікати Х.509 відповідають міжнародному стандарту ITU-T X.509; таким чином (теоретично) сертифікат Х.509, створений для однієї програми, може бути використаний в будь-якому іншому,

Анулювання сертифіката Застосування сертифіката допустиме, доки він достовірний. Небезпечно сподіватися, що сертифікат буде захищений і надійний вічно. У більшості організацій і всіх PKI сертифікат має обмежений термін "життя". Це звужує період, коли

Повідомлення про анулювання сертифіката Після анулювання сертифіката дуже важливо сповістити всіх потенційних кореспондентів, що він є недійсним. Найпростіший спосіб оповіщення у середовищі PGP - це розміщення анульованого сертифіката на

Формат ELF Формат ELF має файли кількох типів, які досі ми називали по-різному, наприклад виконуваний файл або об'єктний файл. Проте стандарт ELF розрізняє такі типи:1. Переміщуваний файл (relocatable file), що зберігає інструкції та дані, які можуть бути

Існують два види криптографічних систем: системи із секретним ключем (симетричні) та системи з відкритим ключем (несиметричні). Говорячи досить грубо, але зрозуміло, симетричні системи використовують один і той же ключ для операцій шифрування і розшифровки, а несиметричні системи — різні.

У симетричних системах існує проблема розподілу секретного ключа захищеним способом: обидві сторони, що обмінюються інформацією, повинні знати цей ключ, але ніхто інший цим ключем не повинен володіти.

Несиметричні системи влаштовані так, що в них є два числа:

• "відкритий ключ користувача A", який використовується для зашифрування повідомлення, призначеного користувачеві A,
• "закритий ключ користувача A", який використовується цим користувачем для розшифровки спрямованих йому повідомлень.

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

Користувач повинен тримати свій закритий ключ у секреті від сторонніх: хочеться, щоб користувач міг розшифровувати повідомлення, які йому були направлені. Більше того, вимога секретності закритого ключа дуже важлива у зв'язку з поняттям цифрового підпису, який обговорюється трохи нижче. Забігаючи вперед, скажемо, що секретність закритого ключа важлива і тому що тільки користувач повинен мати можливість створювати свій цифровий підпис, який залежить від значення закритого ключа.

Досить часто закритий ключ зберігається на носії в зашифрованому вигляді і розшифровується тільки на час виконання якихось дій, що вимагають знання закритого ключа. Це трохи підвищує надійність зберігання закритого ключа, але створює незручність, якщо закритий ключ потрібен якомусь автоматичному сервісу: (щонайменше) при кожному запуску цього сервісу потрібно вводити пароль для розшифровки ключа.

Ще існують смарт-карти, які вміють робити криптографічні операції в собі, віддаючи на вихід тільки результат, але не розкриваючи вміст закритого ключа. Викрасти закритий ключ із правильно реалізованої смарт-картки має бути дуже складно. Закритий ключ, навіть збережений на смарт-карті, може бути захищений паролем. Якщо пароля немає, то будь-хто, хто має смарт-карту у себе в руках, може зробити дії, для яких потрібно знання закритого ключа: значення закритого ключа залишиться секретом, але буде можливо проводити з ним будь-які передбачені дії.

Цифровий підпис

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

Схема концептуально проста: користувач A, використовуючи свій закритий ключ, робить деяку операцію над даними, які хоче підписати і передає результат разом із вихідними даними будь-якому іншому об'єкту. І цей об'єкт, використовуючи лише відкритий ключ користувача A, може легко переконатися, що цифровий підпис вірний.

Ще раз підкреслимо, що умова доступності даного закритого ключа лише його власнику, відіграє дуже важливу роль: якщо воно виконується, то користувач не може відмовитись від свого цифрового підпису. Це називається non-repudiation.

Одне із застосувань цифрового підпису – автентифікація об'єкта. Аутентифікація — це встановлення «особистості» об'єкта. Зрозуміло, що якщо об'єкт може поставити цифровий підпис, цей підпис може бути перевірена, а об'єкт пов'язаний зі своїм відкритим ключем. Останній інгредієнт, якого не вистачає в цій схемі для аутентифікації, - це момент зв'язування відкритого ключа і самого об'єкта: ми повинні точно знати, хто володіє цим відкритим ключем.

Центр, що засвідчує (Certification Authority)

Проблема зв'язування відкритого ключа і об'єкта може вирішуватися різними способами. Один із найпростіших підходів – це скласти список відповідності відкритих ключів та «імен» об'єктів. Як ім'я може бути будь-який ідентифікатор, наприклад доменне ім'я машини, повні ім'я, прізвище та по батькові людини тощо; проблема унікальності імен, яка обов'язково має з'являється - це окрема труднощі, яка зазвичай вирішується адміністративними способами типу ієрархічної системи простору імен та деякою системою вирішення конфліктів імен усередині одного підпростору імен. Тут ця проблема більше не висвітлюватиметься.

Але підхід, заснований на списку відповідностей, має дуже слабке масштабування, оскільки ці списки повинні бути синхронізовані всюди у світі (вірніше, в тій частині світу, де ці списки використовуються).

Тому було введено поняття X.509-сертифіката та центру, що засвідчує. X.509-сертифікат (далі, просто сертифікат) - це конгломерат з відкритого ключа користувача, інформації користувача, імені сертифіката, званого Distungiushed Name (DN) і цифрового підпису засвідчувального центру, яка скріплює всі ці дані один з одним. Тобто з'являється можливість зв'язати відкритий ключ і DN користувача, що може бути шуканим інгредієнтом процесу аутентифікації, якщо як ідентифікатор користувача використовується Distinguished Name його сертифіката. До речі, сертифікат має термін дії, який обмежує термін відповідності, що створюється посвідчувальним центром.

Звичайно, проблема просто переноситься в інше місце — замість підтримки великого списку відповідності ми тепер маємо тримати значно менший список відкритих ключів центрів, що засвідчують. При цьому ключу центру, що засвідчує, виявляється досить велика довіра: засвідчуючий центр підтверджує зв'язок тисяч імен користувача з відповідними відкритими ключами.

Навіщо потрібна автентифікація? Одного шифрування недостатньо?

Ну, по-перше, аутентифікація цінна сама по собі: комп'ютерним системам потрібно аутентифікувати своїх користувачів, щоб потім вирішувати питання авторизації їх доступу до різних ресурсів.

Але якщо ви берете відкритий ключ якогось користувача і хочете надіслати йому зашифроване повідомлення, то вам швидше за все захочеться переконатися, що ви шифруєте повідомлення правильним відкритим ключем, особливо якщо ви берете цей ключ із загальнодоступних джерел. Адже атакуючий може помістити свій відкритий ключ, але вказати, що ключ належить вашому адресату. І якщо ви не аутентифікуєте відкритий ключ, атакуючий, перехопивши ваше зашифроване повідомлення, зможе його без проблем розшифрувати.

Тобто введення посвідчувального центру дозволяє нам аутентифікувати об'єкт, який володіє цим сертифікатом. Звичайно, перед цим ми повинні довіритися відкритого ключа центру, що засвідчує. Це має на увазі дві речі:

1. довіра засвідчувальному центру взагалі, тобто довіра його репутації,
2. впевненість у тому, що той відкритий ключ, який до вас потрапив, дійсно є відкритим ключем цього центру, що засвідчує.

• дзвонити в центр, що засвідчує, і звіряти вміст відкритого ключа по телефону,
• приїжджати в сам посвідчувальний центр і забирати відкритий ключ на якомусь носії,
• довірятися тим відкритим ключам центрів, що засвідчують, які вже присутні у складі якогось програмного пакету
• і безліч інших способів, які ще незручніші вже названих;))

Proxy-сертифікати

Відмінно: тепер у нас є довірені центри, що їх засвідчують, їх відкриті ключі, сертифікати користувачів і їх закриті ключі. Ми можемо шифрувати повідомлення і може створювати цифрові підписи, відмовитися від виробництва яких досить складно.

Що ще? У багатокомпонентних системах дуже зручно те, що називається Single Sign-On - можливість аутентифікуватися вручну лише один раз, а решта операцій аутентифікації будуть проводитися автоматично. Зазвичай, це актуально в системах, які спочатку вас аутентифікують, а потім система починає виконувати дії від вашої особи, наприклад, отримувати дані, запускати завдання, публікувати їх результати і т.д. Це називається делегуванням.

Делегування, засноване на proxy-сертифікатах, функціонує так: після взаємної автентифікації користувача та сервісу, який надалі працюватиме від імені користувача, сервіс створює нову ключову пару та відправляє відкритий ключ на підпис користувачеві. Користувач підписує цей відкритий ключ так само, як це робить центр посвідчення, але при цьому використовується закритий ключ користувача. Сертифікат, що з'явився в результаті, і називається proxy-сертифікатом.

Після цього сервіс, який виступає від імені користувача, може автентифікуватися, використовуючи свій (лише створений) закритий ключ і сертифікат, підписаний користувачем. Процес аутентифікації відбувається приблизно так.

1. Перевіряється підпис, створений сервісом. При цьому використовується відкритий ключ, який було передано разом із підписом.
2. Аутентифікується відкритий ключ, яким було перевірено підпис. Спочатку перевіряється підпис на proxy-сертифікаті, який був створений за допомогою закритого ключа користувача. Це робиться за допомогою відкритого ключа користувача.
3. Так само аутентифікується відкритий ключ самого користувача, але тут вже використовуються дані про центр, що засвідчує.

За допомогою такого ж механізму, сервіс, якому спочатку було видано proxy-сертифікат, може підписати ще один proxy-сертифікат, делегувавши повноваження користувача по ланцюжку іншого сервісу. Саме так і реалізується Single Sign-On.

• X.509 Style Guide, написаний Пітером Гутманом. Там багато технічних деталей, але декому почитати варто.

Формат та структура сертифіката ключа підпису

Детальний опис структури сертифіката, включаючи перелік обмежень використання СКП та порядок використання полів кваліфікованого сертифікату ЕП, виданого УЦ ФК (далі – Опис СКП), затверджується УЦ ФК у вигляді окремого документа, що є невід'ємною частиною цього Регламенту.

Сертифікат ключа перевірки електронного підписув електронній формі являє собою електронний документ, що має структуру, що відповідає стандарту Міжнародного союзу телекомунікацій ITU-T X.509 версії 3 та рекомендацій IETF (Internet Engineering Task Force) RFC 3280 та 5280 та представлений у кодуванні Base64.

Структура сертифікатів ключів підпису, що виготовляються УЦ, визначається такою таблицею:

Common Name або CN використовується в SSL Certificates. CN is used to define the name server which will be used for secure SSL connection. Зазвичай цей SSL certificate використовується для надійного зв'язку між HTTP/S-сервером і клієнтом браузера як Chrome, Explorer, Firefox.

Common Name використовується як спеціаліст з host or server identity. Коли клієнт намагається підключитися до remote server як HTTP-сервер це буде першим отримати SSL certificate of this server. Коли compare the Host name або domain name it want to connect with the Name Name, що надається в SSL certificate. Якщо вони самі використовуються, буде використовувати SSL certificate для підключення до екрана.

Common name technicalle represented as commonName field в X.509 certificate specification. X.509 specification is used в SSL certificates which is the same.

We can formulate Command Name like below.

Common Name = Domain Name + Host Name

Ви можете використовувати наступний домашній і host names as Common Name.

сайт www.сайт *.сайт

Fully Qualified Domain Name (FQDN)

Fully Qualified Domain Name або FQDN використовується з Command Name interchangeable. Fully qualified name is used to define the host name in a strict manner. Більше details про FQDN може бути зроблено в наступному візерунку.

Organization Name

Organization name може бути сприйнятою з Common Name. Організація Name is the name of the organization where the IT infrastrure belongs. Organization name shouldn't be used for common name, який буде створювати security problems.

OS: Linux Debian/Ubuntu.
Application: OpenSSL, Nginx, Apache2.

Тут найпростіша шпаргалка процедури підготовки до придбання SSL/TLS-сертифіката, перевірки його коректності та застосування у web-сервісі, розширена деякими поясненнями.

Генеруємо закритий та відкритий ключі.

Роботи з компонентами сертифіката дуже бажано проводити в місці, закритому від сторонніх доступу:

$ mkdir -p ./make-cert

$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048

Мішанина символів, яку ми бачимо в текстовому файлі ключів насправді є контейнером обфусцованого набору блоків згенерованих відповідно до алгоритму RSA унікальних шифрів, і один з цих блоків - "modulus" - є "відкритим" ключем зв'язування асиметричного шифрування, що використовується у всіх компоненти сертифіката. Весь інший вміст - "закритий" ключ.

$ openssl rsa -noout -text -in ./example.net.key

Треба відзначити, що на практиці, коли SSL-сертфікат застосовується лише для перекладу на HTTPS ряду сайтів, більшість воліє не возитися з запароленим контейнером ключів, а одразу звільняє його від цього захисту, створюючи поруч ще один - "безпарольний":

$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt

Сама по собі підсистема захисту потоку трафіку за допомогою SSL/TLS зазвичай реалізується на сесійних симетричних ключах, що виробляються web-сервером і браузером клієнта при первинному узгодженні з'єднання, і якісь спеціальні встановлені ключі шифрування для цього не потрібні (хоча і полегшують процедуру погодження -key, наприклад). А сертифікат (стандарту X.509), набір компонентів якого ми тут поетапно формуємо, призначений для свого роду підтвердження справжності web-ресурсу в інтернет-інфраструктурі, де умовно довірений центр сертифікації гарантує зв'язок зазначених у сертифікаті "відкритого" ключа та опису ресурсу за допомогою електронної підпису такого вмісту.

Для передачі центру сертифікації нашого "публічного" ключа (не всього вмісту "приватного" ключа, а лише його блоку "modulus"!) та відомостей про ресурс, справжність якого ми підтверджуємо, призначений спеціальний CSR-контейнер (Certificate Signing Request). Створюємо його, вказуючи як джерело "відкритого" ключа контейнер таких:

$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr

"Country Name" - двосимвольний код країни згідно з ISO-3166 (RU - для Росії);
"State or Province Name" - назва області чи регіону;
"Locality Name" - назва міста чи населеного пункту;
"Organization Name" – назва організації;
"Organizational Unit Name" – назва підрозділу (необов'язкове поле);
"Common Name" - повністю певне доменне ім'я ресурсу (FQDN), для якого запитується сертифікат;
"Email Address" - контактна електронна адреса адміністратора доменного імені (необов'язкове поле);
"A challenge password" - (необов'язкове поле, що не заповнюється);
"An optional company name" - альтернативне ім'я компанії (необов'язкове поле не заповнюється).

Ті, хто цікавиться, можуть подивитися, що приховано в коді CSR-контейнера:

$ openssl req -noout -text -in ./example.net.csr

Придбання сертифіката SSL/TLS (X.509).

Нюанси вибору постачальника сертифіката, процедури оформлення замовлення та оплати тут не розглядаються, це не є технічним питанням. Один з важливих моментів - не пропустити вибір між сертифікатом, призначеним для одного домену і "wildcard", що покриває своїми гарантіями всі піддомени наступного рівня.

Генерування самопідписаного сертифіката X.509 (опціонально).

Як варіант, для використання виключно в локальній мережі, можна створити необхідний сертифікат самостійно, підписавши його своїм "закритим" ключем замість довіреного центрусертифікації - так званий "self-signed" (самопідписаний):

$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt

Перевірка коректності сертифікатів та ключів.

В отриманому SSL/TLS-сертифікаті зафіксована як мінімум така інформація:

Версія сертифікату;
Серійний номер сертифікату;
Алгоритм підпису;
Повне (унікальне) ім'я власника сертифікату;
Відкритий ключ власника сертифіката;
Дата видачі сертифіката;
Дата закінчення дії сертифіката;
Повне (унікальне) ім'я центру сертифікації;
Цифровий підпис видавця.

$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt

Найпростіший спосіб перевірки коректності зв'язки "приватного" ключа, CSR-запиту та фінального X.509-сертифіката полягає у звірці контрольної суми "публічного" ключа (блоку "modulus"), що міститься у всіх цих контейнерах:

$openssl rsa -noout-modulus-in./example.net.key | openssl md5
$openssl req-noout-modulus-in./example.net.csr | openssl md5
$openssl x509 -noout-modulus-in./example.net.crt | openssl md5

Формуємо типовий набір файлів сертифікатів та ключів.

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

Загалом, у процесі в нас може накопичитися кілька файлів, які я маю відповідно до їх функціоналу, приблизно так:

"example.net.key" - контейнер із "закритим" та "відкритим" ключами (захищений паролем);
"example.net.key.decrypt" - незахищений паролем контейнер із "закритим" та "відкритим" ключами;
"example.net.csr" - CSR-запит, який використовувався під час замовлення сертифіката;
"example.net.crt" – безпосередньо наш X.509-сертифікат;
"intermediate.crt" - сертифікат (або ланцюжок таких) центру сертифікації;
"root.crt" - сертифікат кореневого центрувід якого починається ланцюг довіри.

$ cd ./make-cert
$cat./example.net.crt >>./example.net-chain.crt
$ сat ./intermediate.crt >> ./example.net-chain.crt
$cat./root.crt >>./example.net-chain.crt

У Linux для сертифікатів і ключів шифрування вже передбачені місця у файловій системі. Розподіляємо файли та захищаємо їх від доступу сторонніх:

# mkdir -p /etc/ssl/certs
# mkdir -p /etc/ssl/private

# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/

# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl

У найпростішому випадку застосування SSL-сертифіката в web-сервері "Nginx" реалізується приблизно так:

# vi /etc/nginx/sites-enabled/example.net.conf

....

server (
listen 443 ssl;
server_name example.net;
....

ssl on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;

ssl_certificate /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....

У web-сервері "Apache" SSL-сертифікат застосовується приблизно так:

# vi /etc/apache2/sites-enabled/example.net.conf

....
# Опис робочого оточення доступного за HTTPS web-сайтом

ServerName example.net
....

# Рекомендовані узагальнені налаштування протоколу
SSLEngine on
SSLProtocol all -SSLv2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
SSLCompression off

# Файли сертифікатів та ключів
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt

....