Смикаємо ланцюжок сертифікатів

Вчора, мабуть, був https шабаш і клієнти стали масово надсилати сертифікати. Зрозуміло ні кореневих ні проміжних не докладалося і прохання їх вислати викликало таке ж здивування, як зустрічний потік біля білявки на дорозі з одностороннім рухом.

На 4-му сертифікаті смикати їх вручну стало ліньки (а я лінивий по натурі), тому накидав «самокат» вичіпляє видавця і формує chain-файл для згодовування nginx'у. Напевно він не ідеальний і перевірений лише на півторадесятках сертифікатів, але чим багаті.

Про пристрій x.509 багато сказано (у тому числі на хабрі), тому не буду повторюватися.

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

Отже, припустимо, що ми маємо PEM-сертифікат сайту. Для прикладу ми візьмемо сертфікат ya.ru (не тільки пінгувати його).

Крім самого кодованого запиту, версії, підпису тощо. у ньому є ряд розширень. Одне з якихAuthority Information Accessнас і цікавить:

ПараметрCA Issuersтаки містить наступний у ланцюжку сертифікат. Як правило, цей сертифікат або вPEM, або вDER(як у нашому випадку) форматах.

НасправдіPEMформат не більше ніжbase64поданняDERі отриматиPEMзDERможна зробившиbase64 ./ycasha2.cer ./ycasha2.pemі обрамивши кодований текст"-----BEGIN CERTIFICATE-----","-----END CERTIFICATE--- --". Однак, логічніше і простіше зробити це перетворення засобамиopenssl:

Їдемо далі і дивимося наступний сертифікат у ланцюжку:

Перетворюємо та його:

У даному сертифікаті (бо він кореневий) відсутнє розширенняAuthorityInformation Access:

Тобто на ньому і закінчимо витягування ланцюжка. Залишилося зібрати це все в chain-файл:

Начебто тепер можна ставити (якщо є Private Key), але зупинюся ще на парі нюансів. Встановивши свій сертифікат на свій Яндекс, перевіряємо його:

Все добре, але це лише тому, що в дефолтних шляхах-CApath, -CAfileмогоopensslзнайшли потрібні хеші сертифікатів. Якщо ми їх змінимо, або по дефолтних шляхах їх немає, або вони просто застаріли, або у когось версіяopensslз багом, в якій не чіплялися default CApath (якщо не помиляюся з 1.0.1с по 1.0.1e), то отримаємо неприємність у вигляді:

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

І тепер наша система довіряє ya.ru:

Зрозуміло робити руками щоразу ліньки, тому злегка автоматизуємо:

Якось так ... Зрозуміло скрипт не універсальний, все нашвидкуруч напередодні грандіозного шухера. Коментарі/побажання вітаються, але відповідати навряд чи зможу — у нас тут (у Білорусі) безглуздо деномінація.

Хардкорна конфа за С++. Ми запрошуємо лише профі.