субота, 14 лютого 2009 р.

HTTPS і власний центр сертифікації: розбір старого CA.sh-прикладу

Ця нотатка зберігає стару процедуру створення власного центру сертифікації та сертифіката сервера через допоміжний скрипт OpenSSL CA.sh. Вона не є готовою конфігурацією для сучасної Ubuntu або Apache.

Історична послідовність:

cd /usr/local/ssl/misc

# Створення власного центру сертифікації
./CA.sh -newca

# Створення запиту сервера
./CA.sh -newreq

# Підписання запиту власним центром
./CA.sh -sign

# Команди копіювання з оригіналу — див. уточнення нижче
cp newreq.pem /usr/local/etc/apache/sslkey/server.key
cp newcert.pem /usr/local/etc/apache/ssl.crt/server.crt

У джерелі також зазначалося розповсюдження сертифіката центру ./demoCA/cacert.pem на клієнтські комп'ютери. Довіра до власного центру має встановлюватися свідомо й контрольовано: такий центр не стає загальнодовіреним лише через створення сертифіката.

Важливе уточнення щодо файлів

Не можна автоматично вважати newreq.pem приватним ключем. Наприклад, у документованому CA.pl -newreq приватний ключ записується в newkey.pem, а запит — у newreq.pem. Поведінку конкретного старого CA.sh потрібно перевіряти за його версією та вмістом файлів перед налаштуванням Apache.

Для сучасного розгортання окремо перевіряють відповідність ключа сертифікату, імена хостів, строк дії, ланцюжок довіри й права на приватний ключ. Саме виконання архівних команд не підтверджує коректної конфігурації HTTPS.

Первісні адреси: http://www.opennet.ru/tips/info/681.shtml та http://www.opennet.ru/base/net/apache_mod_ssl.txt.html. Довідка для зіставлення: OpenSSL CA.pl.

Немає коментарів:

K2 Chat — навіщо бізнесу ще один месенджер, особливо під час війни?

«Де файл?» — «У чаті». — «У якому із семи?» Знайома ситуація? Коли робочі домовленості розпорошені між месенджерами, команді складніше знах...