Що таке сертифікат номіналом

Що таке персональний цифровий сертифікат

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

У статті розповімо, що таке персональні цифрові сертифікати, умови отримання та порядок їх оформлення.

Концепція

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

Виходячи з цього стану речей, у 2019 році в рамках Національного проекту «Цифрова економіка» Мінцифри та Університетом 20.35 була розроблена програма навчання громадян РФ найбільш затребуваним і дефіцитним в даний час спеціальностям.

Будьте в курсі всіх подій та тенденцій ринку житла!

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

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

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

Для чого потрібні

Цифровізація економіки – процес незворотній, тому підготовка кадрів у цій галузі є вкрай нагальним питанням.

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

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

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

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

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

Особливу популярність спеціальностей цифрової економіки довів досвід, отриманий у період пандемії covid-19. При цьому використання сучасних методів дистанційної роботи стало не тільки фахівцям високотехнологічних галузей, а й представникам більшості традиційних професій.

Номінал

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

Номінал цифрового сертифіката спочатку становив 15 тисяч рублів. На сьогодні фінансова його забезпеченість може значно відрізнятися залежно від програми та тривалості навчання.

Напрями навчання

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

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

Отже, програми підготовки полягають у навчанні в рамках наступних напрямків:

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

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

Відбір освітніх програм для проекту

Відповідно до умов програми, навчання проводиться на базі діючих в Росії ВНЗ та середньо-спеціальних навчальних закладів. Вони обов'язково повинні мати ліцензію та акредитацію. Форма власності навчального закладу (приватна чи державна) не має значення, важливо лише наявність дозволу на надання освітніх послуг за програмами додаткової освіти.

Відбір ведеться на підставі заявок навчальних закладів, які пропонують свої програми у рамках чинного проекту. Сьогодні більшість учасників є освітні установи з регіонів Росії. Московських ВНЗ чи СУНЗ у переліку практично немає.

Формат та тривалість навчання

В рамках програми персональних цифрових сертифікатів допускається винятково дистанційний формат навчання.

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

Тривалість навчання становить щонайменше 72 годин. Конкретні навчальні плани складає навчальний заклад, а оператор програми узгоджує їх.

Умови отримання

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

вік – від 18 до 60 років (жінки) або 65 років (чоловіки), тобто працездатні особи;
освіта – не нижче середньої професійної.

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

Процес оформлення

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

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

Якщо заявку було схвалено, то протягом кількох днів з користувачем пов'язується навчальний заклад, представники якого роз'яснять порядок зарахування на курси.. Крім іншого, від громадянина потрібно буде надіслати скани всіх необхідних документів, таких як: паспорти, дипломи про освіту, СНІЛЗ та ін.

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

Можливі труднощі

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

Крім цього, раніше дія програми поширювалася не на всі регіони країни. Однак зараз цю проблему по суті вже вирішено.

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

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

Відео на тему статті:

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

Навіщо потрібні сертифікати¶

Отже, сертифікат (certificate) — це файл, що містить інформацію про персону чи організацію та підписаний цифровим підписом, щось на зразок паспорта персони чи організації. Головний вміст сертифікату - це публічний ключ шифрування. У будь-якого сертифіката існує його автор-творець і цей автор має секретний ключ шифрування. По суті сертифікат - це лише обгортка над публічним ключем, де крім власне ключа міститься різноманітна додаткова інформація: ім'я персони або організації, країна, телефон, емейл і так далі.

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

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

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

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

Якщо для SSH схема із заздалегідь збереженим сертифікатом більш-менш працює, то для HTTPS у браузері вона вже не годиться, абсолютно неможливо отримати сертифікати для всіх сайтів в інтернеті. Тому в HTTPS використовується інша схема, яка називається інфраструктурою публічних ключів або англійською Public Key Infrastructure, скорочено PKI.

Суть PKI дуже проста: у браузері зберігаються не сертифікати браузерів, а сертифікати так званих посвідчувальних центрів (англійською Certificate Authority, скорочено CA). Призначення CA - це підписування всіх інших сертифікатів, це означає, що коли ваш браузер отримує сертифікат сайту при встановленні з'єднання, він бачить крім адреси сайту ще й «адресу» центру, що засвідчує, а також цифровий підпис, який згенерував посвідчувальний центр з використанням свого секретного ключа. Далі браузер бере з локального сховища сертифікат центру, що посвідчує, дістає з нього публічний ключ і за допомогою нього перевіряє підпис у сертифікаті сайту. Якщо підпис правильний, з'єднання успішно встановлюється.

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

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

Технічні подробиці¶

А тепер найголовніше, навіщо ця стаття й писалася — технічні подробиці, стандарти та особливості реалізації системи сертифікатів.

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

Секретний ключ¶

Головний компонент всього – криптографія, точніше криптографічні алгоритми.

Все починається з генерації пари ключів: секретного та публічного. Спочатку за допомогою математичної та комп'ютерної магії генерується секретний ключ, а потім із нього обчислюється публічний. Найчастіше для сертифікатів використовується алгоритм RSA, як це робиться в консолі через програму openssl:

[user@shell]$ openssl genrsa  2048
Generating RSA private key, 2048 bit long modulus
. +++
. +++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAtqYUwQ3QwKf8l9St1IK2jNyZiL7PDVKdaWo8BoY0a7zZLyST
a5lS09k0Jcdsh3pV0X9PkNb1x+m4YGETjNfZUsd2O1/IwP1Fj+w3y75cy/ON4/so
6oxrUrIYwCbu9i2IxvevQJpClmn105QbIF4d+Pp5pMSfivngNl/BGLm4O5uyqhfn
LaouOCOroY9b77vNVHBkbq+eQjZBwvIFz1DzVfGVXsS1oCt36nTI38txHGTaCqgi
cxznqj7GBiaJi1b7jCvWLUoZi64AGCK4gWFkijNLuDsnR4h0WUJ90wge9Xt+srii
/iElvo2P1U9feL1znj4PZumZNJ3BzYU3qNWJ8wIDAQABAoIBAQCzb3X0Mx5iJqaA
gvBDVicBO7eaH9pJvF/or/VIc5AMR/sV1Vj+3CIC/d+9Pa3has3kgq4oHQZY38PC
65vJQkS+jjYZHoCbGDa+rdIi12FS/HLpBlWsF0dYdp7aJ2WbdCBrV+lUDjhcjLx0
n4wGwG+xqmDW/lO+tL0QrgGFyO61nxdEsltgvjlGFhUu4ugskwOvL3QoWv4SghHm
6oIyDhlGo3W6WpGV+Xt3/IR5bWFF0bn5bt9arHDiow1Vg0MeBxB+iuMYuctlXHaJ
O5UMs/BgqidV2m4wjoQxWg41tdeKEWmetWOm7LVZinmC7EIugug7xKrGVGAAexaj
fENVOxgBAoGBAN/9sB9BSZsA+C9DYtbKHTEO5IY+nBYGzxigyj8JlqwsibpN9dyZ
ZXML/UvgspYbKS8nafip/GQpdxIPeAhqKJSI3dVeml6MxKTwJj7HCr+0iuXg5m9d
AwLBLxHi+6hEN7TJb7JONB07QB9y78eAk94y9q4exAYh3Pnzn1lZR9JJAoGBANC/
9iiMFagQrvCkcKCRiQr1cD6J2FdyXl0jMAK250ZQ3Kxg5vmpFVhk3EYR+/5tb5S0
QeG7VqumXONTPnAzt6IHRHQyUzaLuy99zIOekKzlVGPOKbJGJQsKuRXc8nRnDN8Y
fl7C8kPHwahQqiJL3Sa6fvTVINdxkFa+VvRhX3pbAoGAVHlMTr1EkRyQfOKhB/g5
giLntGkwXG489EDPhW6MUGqLlqOIMaX4SKcg49jeARZFNe9bW9hfwzaQHVOQJTxE
CaCEaM/A0B+umbWn9s0CFMJ2D7P9s8oUNJm+srQzzIXNrHS7lzc/GDccO8ARBeBL
4+S8e3ZG3zkuKWXjlsLA/2ECgYB7XrfQRtoVtaZuOgEGJHzlqSBpFXZyV/lE+iLJ
t+b/O5LvnWVkb3VaBGHaV46iU3L6Y338NoeGco+7Gdtw3F/OtpTSR1u+hN5ftu1D
bFb8l5xET/d8kNAbsn6oWShBexW0U/l7b6NWQ5xEKUgjdMqCtP2LHNqH+WngmiUx
0MpouQKBgAkW/zgeXt5BiexQ9QLHOkpZQNdT48WTKOFDxM5b7R87E7rG6Phyx01W
tVEs5BJ9a1DizingvL2TAMglP0t5WETmkNEwIDfH8ey2KZBsfrB9Mb9BsV4xZP78
3sM6yJXbWTOMfUXByxWKdxNx9EFjes0WP0rhFgPQGCBvTZjxtAkj
-----END RSA PRIVATE KEY-----

У цьому прикладі ми згенерували секретний ключ алгоритму RSA. Власне сам ключ знаходиться між спеціальними маркерами -----BEGIN RSA PRIVATE KEY----- і -----END RSA PRIVATE KEY-----. Щоб при генерації ключа зберегти його одразу у файл, додайте аргумент -out private.pem :

[user@shell]$ openssl genrsa -out private.pem  2048
Generating RSA private key, 2048 bit long modulus
. +++
. +++
e is 65537 (0x10001)

З подібним форматом представлення криптографічних даних вам доведеться зіштовхуватися постійно, називається він PEM, що розшифровується як Privacy-enhanced Electronic Mail. Його призначення - кодувати бінарні криптографічні дані у вигляді ASCII-тексту. І фактично між маркерами з мінусів знаходяться закодовані в base64 бінарні дані, в даному випадку секретний ключ.

Ми можемо за допомогою openssl сконвертувати секретний ключ із текстового формату PEM у початковий бінарний, збережемо його у файлі private.der:

[user@shell]$ openssl rsa -inform PEM -outform DER -in private.pem -out private.der  writing RSA key

Ім'я формату даних DER розшифровується як Distinguished Encoding Rules та є частиною стандарту ASN.1. У стандарті ASN.1 описуються правила та структури для кодування, розкодування та передачі даних по телекомунікаційних та комп'ютерних мережах.Насправді можна вважати ASN.1 форматом для серіалізації структурованих бінарних даних. Існує спеціальний компілятор, який із формальних специфікацій ASN.1 генерує C-код для роботи з бінарними даними такої структури.

Також існує консольна програма dumpasn1 для перегляду бінарних даних, в дебіані/убунті вона ставиться через sudo apt-get install dumpasn1 , для макос можна поставити через macports, через homebrew (інструкція), або скомпілювати самостійно з вихідників.

Ось так, наприклад, виглядає дамп нашого створеного секретного ключа:

[user@shell]$ dumpasn1 private.der  0 1186: SEQUENCE    4 1: INTEGER 0
7 257: INTEGER
: 00 CB F8 C1 9B 6E 29 63 39 3C 24 9B 2D A3 7D 00
: B0 B8 5C E8 D6 96 5D E4 76 67 7F 04 8F 48 D4 F4
: 35 64 68 57 10 3D 38 CE A0 B5 DC B2 FC DD 34 FF
: 2B AC 48 EE D1 05 37 65 4A 2F AE 8A E0 F8 1D CE
: 63 EB 2E C6 7A 09 4B B1 85 71 1E FA FF 55 17 0C
: 05 23 71 87 43 21 66 C4 70 6D E8 A8 B4 74 EA E4
: C1 75 7B AB 33 5B 8B 8D DB D4 67 BA DC B4 AD 50
: 12 AB FB 3E 74 44 AC 48 BE 94 C2 DD 4D 16 D6 0F
: [ Another 129 bytes skipped ]
268 3: INTEGER 65537
273 256: INTEGER
: 07 01 7D 4C E4 64 C1 86 B6 BD 1F 23 5B 29 30 FB
: E0 E9 38 0A 1E D2 0C C5 D0 5A 39 82 DE 62 8A 1C
: C7 5D 1A 18 71 B1 E0 CE FE 50 1D 49 B8 23 58 DC
: 5C 27 89 24 5E C4 7F 53 23 FE 1F C1 08 64 A5 B1
: 22 E3 D1 67 61 A8 5A E9 95 70 15 F8 ED 28 44 7E
: 6C B0 3A 90 20 B6 91 EA B6 AB B6 17 B4 A8 58 C1
: 18 52 EE 17 6E 7E 85 99 D6 5A D5 BD 3C EB 73 03
: A1 2A 99 03 8F 54 47 8F 5C 36 B1 39 33 9E 98 9D
: [ Another 128 bytes skipped ]
533 129: INTEGER
: 00 E7 D9 F7 E8 B2 FC A4 07 93 29 B8 60 75 02 80
: 10 EE C0 00 CF DA D8 C4 8C D0 B9 44 87 B9 ED 15
: 3D 60 17 1E 70 1E A0 E6 31 CA 2D CB D7 2B 05 1C
: FF 3F 21 57 44 87 47 92 90 11 8E 7C 1D D5 57 C5
: FC 9B 3D 22 E2 A0 E9 5E 4E 38 B7 E8 BC B0 AC 61
: AB 84 C6 19 C4 2C E6 64 0A 57 54 03 D6 2A EE CD
: 21 A1 FD BE AD B3 9B E7 2B C1 BF 37 80 84 18 A3
: 1E D0 CF 44 12 AA B6 3A 05 3B B0 5F DF 32 B2 AE
: 71
665 129: INTEGER
: 00 E1 37 68 C5 C0 92 F7 0F 2E 99 C0 74 13 04 79
: DD A7 EF 56 46 A2 C9 A7 96 41 5E 4A 43 F3 57 7E
: 3E 98 0D C6 B1 AF 85 F6 29 B9 F0 2A D2 54 8C CE
: C8 DB FA 67 2E 5E 56 AB CC 7B E4 F1 3B EC 55 EE
: 10 0E B1 6F 76 A8 59 5B 2B B2 FF E2 E8 9A E5 9B
: F1 90 D1 65 DC 6D AD DB B3 B5 EC 39 8C 20 88 1F
: CA 87 E6 5A 6C 92 B1 75 F5 15 2E B1 41 0C AA 88
: 75 88 77 E9 B2 F4 8D B6 16 E2 13 5F EF 89 20 40
: E5
797 128: INTEGER
: 27 3A D1 60 B5 50 5C 2C CF F0 C2 3A C7 F1 A9 5B
: B4 1A 16 C9 14 BD 92 DC 44 C0 E4 60 96 CC 0F C8
: F7 C6 51 A7 24 F7 92 9B A0 1B 09 9F 99 AE DE CE
: 2D 8F 65 A5 B9 C2 19 81 79 07 03 E7 44 5E FA A8
: 18 58 4A DB CF E0 4C CD AD 79 28 CF 2C 91 AE 61
: 08 31 40 D0 D9 CC 0D E7 56 09 68 30 C7 C8 EA 3A
: A3 9F 3C B1 45 6F BE B8 BF AA AC 28 79 B1 75 80
: 54 52 8D B1 1E E3 80 83 BC 2A C6 BE 0C 65 01 71
928 128: INTEGER
: 14 BC 57 47 2D CD DA 35 69 A2 FA 57 35 91 09 EF
: 60 90 E6 AE A6 3A 4E D5 C4 BA FB B7 79 E6 2A 57
: 75 04 7F B0 C8 6A 5B 19 C8 66 D6 6A 7B 22 63 BF
: 96 91 5D 82 A5 68 F1 74 68 4B D1 F2 24 76 5C EE
: D9 8B 78 A9 C2 22 48 04 A3 FC 6F 55 DF 3D 18 B8
: 8B 0E DC 84 09 0D 22 D7 4E FE AA E5 BD F1 0A 8C
: 49 2A EA 54 68 C5 32 09 18 A4 2D E9 C1 52 CA 31
: 98 19 02 49 59 BE DA 6F 0C ED 9F BD 9C 30 7E 09
1059 128: INTEGER
: 75 97 A2 6D 60 94 68 EF AB B4 3A 63 10 21 B8 AA
: 2B 98 13 9C 0E 58 B2 FF 29 13 AB 38 18 0E FE DF
: C2 7D 08 46 0F D9 70 0C EA AC 86 57 C5 A3 0E EF
: 31 C7 7A 13 8D 9B F6 5A 60 C5 1B 1C 0F C3 C3 D3
: C7 90 5A E2 1E A1 F0 91 CA E4 6D 6D 89 64 ED 63
: C8 D2 F1 8E A4 D4 56 6A 99 17 38 A6 2A 3B 35 D1
: 92 2E 35 01 5C BF 85 31 25 F3 11 6F 73 7D F1 63
: 99 D6 9A AC D1 B1 80 17 E7 50 2C 3A AB 88 86 58
: >
0 warnings, 0 errors.

У нашому файлі секретного ключа «упаковано» дев'ять цілих чисел, структура ключа для алгоритму RSA дуже проста і описана, наприклад, RFC 3447, в секції A.1.2 RSA private key syntax.

Ну і щоб двічі не вставати, витягнемо із секретного ключа публічний ключ у файл public.der, закодований у бінарний формат DER, openssl вміє робити і це теж:

[user@shell]$ openssl rsa -inform DER -outform DER -in private.der -pubout -out public.der  writing RSA key

І відразу ж подивимося на його структуру через dumpasn1:

[user@shell]$ dumpasn1 public.der  0 290: SEQUENCE    4 13: SEQUENCE    6 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
17 0: NULL
: >
19 271: BIT STRING, encapsulates    24 266: SEQUENCE    28 257: INTEGER
: 00 CB F8 C1 9B 6E 29 63 39 3C 24 9B 2D A3 7D 00
: B0 B8 5C E8 D6 96 5D E4 76 67 7F 04 8F 48 D4 F4
: 35 64 68 57 10 3D 38 CE A0 B5 DC B2 FC DD 34 FF
: 2B AC 48 EE D1 05 37 65 4A 2F AE 8A E0 F8 1D CE
: 63 EB 2E C6 7A 09 4B B1 85 71 1E FA FF 55 17 0C
: 05 23 71 87 43 21 66 C4 70 6D E8 A8 B4 74 EA E4
: C1 75 7B AB 33 5B 8B 8D DB D4 67 BA DC B4 AD 50
: 12 AB FB 3E 74 44 AC 48 BE 94 C2 DD 4D 16 D6 0F
: [ Another 129 bytes skipped ]
289 3: INTEGER 65537
: >
: >
: >

Структура публічного ключа також описана RFC3447, в секції A.1.1, якщо ви туди подивіться, то побачите, що дамп файлу public.der не відповідає цьому опису. Вітаю з першими граблями в openssl, з ними вам теж доведеться стикатися постійно. У цьому випадку навіщось додається заголовок, що вказує, що далі буде RSA, і на цьому заголовку багатьом бібліотекам зриває дах.

Для маніпуляціями публічними та секретними ключами можна також використовувати команду pkey, вона дозволяє працювати з довільними типами ключів, що підтримуються. Ось як виглядає її виклик для витягування публічного ключа з приватного:

[user@shell]$ openssl pkey -inform DER -outform DER -in private.der -pubout -out public.der

Сертифікат¶

Але вистачить про ключі, поговоримо тепер про сертифікати. Нагадаю, що сертифікат – це обгортка над публічним ключем. Неформально файл сертифіката складається з двох частин: даних сертифіката (DATA) та цифрового підпису (SIGNATURE).

CERTIFICATE +--------------------------+ | DATA | | | | Version: | | Subject: | | Subject Public Key Info: | | . | +--------------------------+ | SIGNATURE | +------------------------- +

У секції DATA міститься смислова частина сертифіката, головне поле там - Subject (він же Суб'єкт), це власник сертифіката, саме його публічний ключ знаходиться у полі Subject Public Key Info. Також у сертифікат входять інші поля, про які ми поговоримо пізніше, коли розглядатимемо уточнену схему.

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

Звичайно, вся робота з сертифікатами регламентується міжнародними стандартами, саме для наших сертифікатів використовується стандарт X.509, його офіційний сайт: http://www.itu.int/rec/T-REC-X.509. X.509 описує безліч аспектів PKI, як формати даних, а й алгоритми.

Для опису структур даних використовується вже знайома нам нотація ASN.1 вона досить проста і виразна.

Ось так визначається сертифікат (розділ 4.1. Basic Certificate Fields):

 Certificate ::= SEQUENCE

Це все означає, що сертифікат складається з трьох компонентів: tbsCertificate, signatureAlgorithm та signatureValue

tbsCertificate власне тіло сертифіката, його дані, літери tbs у назві поля розшифровуються як «to be signed», тобто блок даних, який буде підписаний, описується ASN.1 стуктурою TBSCertificate ; signatureAlgorithm у цьому полі задається алгоритм підпису, що визначається ASN.1 структурою AlgorithmIdentifier ; signatureValue а в цьому полі знаходиться бінарний неструктурований блок із власне підписом.

Перед тим як занурюватися в структуру тіла сертифіката, розглянемо поле signatureAlgorithm, в його описі фігурує дуже важливий для подальшого розуміння елемент, але спочатку формальний ASN.1-опис (розділ 4.1.1.2. signatureAlgorithm):

 AlgorithmIdentifier ::= SEQUENCE

Тут ми бачимо елемент з «типом» OBJECT IDENTIFIER, це дуже важлива сутність, яка буде зустрічатися скрізь. OBJECT IDENTIFIER часто скорочується до OID і означає буквально ідентифікатор об'єкта. Усі OID є «словниковими», тобто визначені десь у якомусь стандарті, де також описана вся супутня семантика. У нашому випадку через OID визначається криптографічний алгоритм, що використовується для створення цифрового підпису сертифіката.

Як і інші породження ASN.1/X.509, OID має чітко задану структуру, якою можна однозначно ідентифікувати тип і властивості об'єкта. Існують різні способи представлення OID. Розглянемо їх у простому прикладі. Для генерації цифрового підпису можна використовувати алгоритм, який неформально можна описати так: порахуємо SHA256 тіла сертифіката і далі зашифруємо це значення приватним ключем центру авторизації. Для цього алгоритму існує OID, цей OID має кілька рівнозначних способів подання:

1.2.840.113549.1.1.11
/ISO/Member-Body/840/113549/1/1/11

Всі ці методи відбивають ієрархічну сутність OID, по компонентам можна визначити, наприклад, хто вніс цей OID до Реєстру, яка країна, яка організація тощо. Існує спеціальний сайт - http://www.oid-info.com, - на якому ведеться великий реєстр усіляких OID. В принципі, таких сайтів є кілька, але цей найпопулярніший. Ось, наприклад, сторінка OID для алгоритму sha256WithRSAEncryption: http://www.oid-info.com/get/1.2.840.113549.1.1.11.

Повернемося тепер до сертифікату, розглянемо ASN.1-структуру TBSCertificate, ось її визначення разом із супутніми структурами:

 TBSCertificate ::= SEQUENCE < version [0] EXPLICIT Version DEFAULT v1, SerialNumber v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 >Version ::= INTEGER < v1(0), v2 (1), v3(2) >CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE < notBefore Time, notAfter Time >Time ::= CHOICE < utcTime UTCTime, generalTime GeneralizedTime >UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE < algoritm AlgorithmIdentifier, subjectPublicKey BIT STRING >Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE

Я не повністю описуватиму семантику цих полів, це все наводиться з подробицями в розділі 4.1. Basic Certificate Fields RFC 5280. Так, коротко пробіжимося основними полями.

У полі signature має бути те саме значення, що і в полі signatureAlgorithm, тобто алгоритм, яким CA підписує сертифікат.

У полі issuer знаходиться ім'я центру авторизації, у полі subject - Ім'я власника сертифіката. Обидва ці імені також є структурованими (ASN.1-структура Name) і повинні бути непустими, їх тип визначається стандартом X.501 і має назву distinguished name, скорочено DN. Це той самий DN, що і в LDAP.

Поля структури Name також задаються через OID. Ось невеликий приклад, як поле issue «розгортається» з текстового подання до строго формалізованого. Візьмемо DN-фрагмент реального сертифікату (https://google.ru):

C=US, O=Google Inc, CN=Google Internet Authority G2

Невеликий хінт, як завантажити сертифікат із сайту і відразу конвертувати його в DER у файл certificate.der:

openssl s_client -connect google.ru:443

А ось, в яку ASN.1-структуру «розгортається» цей текст:

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

Для подальшого вивчення теми нам знадобиться справжній сертифікат. Я взяв сертифікат c twitter.com, ви можете завантажити його самі (якщо знаєте, як це зробити вашим браузером) або взяти збережену мною версію у вигляді DER-файлу (завантажити збережену версію).

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

[user@shell]$ openssl x509 -inform DER -in certificate-twitter.com.der -noout -text  Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1a:c8:5e:b7:ae:c3:51:3c:d8:0d:85:38:5e:cf:d2:08
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 EV SSL CA - G3
Validity
Not Before: Sep 10 00:00:00 2014 GMT
Not After : May 9 23:59:59 2016 GMT
Subject: 1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/
businessCategory=Private Organization/serialNumber=4337446, C=US/postalCode=94103-1307,
ST=California, L=San Francisco/street=1355 Market St, O=Twitter, Inc.,
OU=Twitter Security, CN=twitter.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:e3:ac:59:34:07:dc:11:f8:1c:ca:b3:0f:93:44:
8a:54:34:76:90:6a:c0:22:00:be:95:9a:da:58:3c:
6c:38:31:a2:a2:1f:3b:64:e2:9d:e0:f5:c2:ab:07:
90:5b:7c:fe:f9:88:8c:6a:9d:69:3b:e0:23:65:b7:
11:d6:e8:88:d6:3e:6d:8b:ed:ca:ea:58:0b:fe:4d:
bf:2a:95:ca:bb:21:bb:ce:d6:e2:10:02:11:21:68:
26:f7:92:7e:9c:a3:80:b1:82:d7:e5:a6:a0:86:47:
42:1a:c6:5b:04:d9:c3:b5:b2:9b:38:d4:a1:6d:3b:
bd:d8:05:f0:51:9b:bd:95:77:7f:e9:02:8e:60:a3:
7a:65:20:52:23:db:8d:01:27:24:c2:00:66:0d:14:
66:b3:52:2b:cc:6b:5b:a5:44:2f:e2:40:6d:da:21:
a1:92:5a:57:12:d3:47:01:ef:e9:df:af:c6:91:8c:
21:af:77:65:13:36:1c:63:7a:2d:05:e6:63:c5:0b:
d8:39:e9:ac:f2:3b:ff:9d:c5:a7:46:0a:6e:1a:66:
10:1e:4a:e7:ba:c7:89:79:1f:ae:f1:f3:84:03:ca:
e7:50:8a:19:63:bf:3c:20:10:78:c5:f4:53:3c:7d:
5e:0d:af:96:70:89:92:b9:7f:9a:19:0c:f6:78:6a:
8f:73
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS: twitter.com, DNS: www.twitter.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://d.symcb.com/cps
User Notice:
Explicit Text: https://d.symcb.com/rpa
X509v3 Authority Key Identifier:
keyid:01:59:AB:E7:DD:3A:0B:59:A6:64:63:D6:CF:20:07:57:D5:91:E7:6A
X509v3 CRL Distribution Points:
URI:http://sr.symcb.com/sr.crl
Authority Information Access:
OCSP - URI: http://sr.symcd.com
CA Issuers - URI: http://sr.symcb.com/sr.crt
Signature Algorithm: sha256WithRSAEncryption
d1:53:68:e9:d6:20:d0:56:7a:10:80:b8:e9:7e:00:c9:9e:d5:
35:4a:a2:d2:a0:16:8a:e2:fb:eb:96:88:77:c2:6e:35:f4:a7:
a9:aa:dc:35:7b:c6:7d:5e:3c:f6:c9:5b:a0:d1:58:ae:7d:96:
e7:54:02:5c:69:1b:56:92:26:ad:06:2c:c1:5a:ff:59:f3:8a:
8c:94:32:0d:1a:42:d1:6e:bc:1c:bd:a8:c6:08:01:1b:73:17:
93:28:30:ae:ce:4d:4e:2d:4b:bf:22:af:9a:61:32:7a:a8:68:
25:19:3c:6d:fb:67:cc:29:3f:5b:f5:d1:af:4c:bf:67:a3:60:
c4:dd:b0:fb:83:55:6d:b5:2c:a9:7d:34:ad:b0:08:c7:2c:f0:
cb:4c:d8:2b:79:f4:e9:da:7f:6e:c0:de:55:7c:d6:d6:47:cf:
c4:90:ef:4f:be:eb:c9:3d:05:71:6b:5e:c7:36:8d:4f:0c:3c:
47:83:a5:11:88:22:f8:46:e0:f8:9b:1a:fe:e9:a2:df:90:81:
10:71:f3:97:9c:b7:69:60:77:20:d6:87:85:ee:5a:77:d2:92:
ec:d9:5d:1f:31:3b:3a:e2:5b:35:d1:92:36:db:44:d4:79:d9:
6c:03:24:87:5d:c3:86:c6:10:e2:ea:65:7c:cf:b8:ef:c2:31:
02:55:72:12

Розберемо послідовно поля сертифікату.

Version: 3 (0x2) Це версія не саме цього сертифіката, а використовуваного «профайлу», на даний момент таких версій лише три: 1, 2, 3; найчастіше використовується 3. Фактичне значення поля - 2, так як нумерація версій йде з нуля. Serial Number: 1a:c8:5e:b7:ae:c3:51:3c:d8:0d:85:38:5e:cf:d2:08 Це серійний номер сертифіката, по суті він є унікальним ідентифікатором у базі CA, для кожного підписаного сертифіката цей номер має бути свій. Signature Algorithm: sha256WithRSAEncryption Це ми вже знаємо: для підписування сертифіката використовується алгоритм sha256WithRSAEncryption Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 EV SSL CA - G3 Це ім'я (distinguished name, DN) центру авторизації, є по суті ідентифікатором у браузерній базі CA-сертифікатів, і щоб коректно перевірити серверний сертифікат, браузер повинен мати CA-сертифікат, в полі subject якого стоїть точно таке ж значення, як тут . Validity У цьому полі дві дати, з якої та за якою сертифікат вважається валідним. Це поле є головною годівницею центрів авторизації: щороку чи два потрібно виписувати (=підписувати у центру авторизації) новий сертифікат, не безкоштовно, звичайно. Subject: 1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=4337446, C=US/postalCode=94 =California, L=San Francisco/street=1355 Market St, O=Twitter, Inc., OU=Twitter Security, CN=twitter.com Суб'єкт. Той, кому виписано сертифікат. Це DN, тобто структуроване поле. Зверніть увагу на найперші компоненти - 1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware , в яких ми бачимо, що openssl не зміг розпізнати ці OID і вивели їх у «сиром» вигляді.Ось вони в репозиторії OID: 1.3.6.1.4.1.311.60.2.1.3 jurisdictionOfIncorporationCountryName, 1.3.6.1.4.1.311.60.2.1.2 jurisdictionOfIncorporationStateOrProvinceName. Далі йдуть вже розпізнані компоненти, як роздільник компонентів використовується кома або слєш, такі особливості виведення openssl. Зверніть увагу на компонент CN, це Common name, саме тут є ім'я домену, для якого виписується сертифікат. Subject Public Key Info Цей блок містить публічний ключ суб'єкта, синтаксично там два поля: OID алгоритму шифрування і власне тіло публічного ключа. Openssl під час показу сертифіката намагається показати деталі публічного ключа, у разі він показує модуль і експоненту RSA-ключа. Нижче я покажу, як openssl справляється із сертифікатами, з алгоритмами яких він не знайомий. X509v3 extensions У цьому блоці містяться так звані розширення сертифіката. Хоча структура сертифіката дуже жорстка, в ній були залишені точки розширення, щоб можна було до сертифіката додавати додаткові дані, які спочатку не передбачили. Фактично, блок з розширеннями – це набір пар OID-значення, де тип значення залежить від конкретного OID. Розширення допускаються лише для сертифікатів версії 3. Зазвичай розширення вказують додаткові параметри сертифіката. Наприклад, у полі X509v3 Subject Alternative Name вказуються додаткові доменні адреси сайту, для яких можна застосувати сертифікат. Або, наприклад, у полі X509v3 Basic Constraints, вказуються обмеження в застосовності сертифіката, в даному випадку зазначено, що сертифікат не може використовуватися як сертифікат центру, що посвідчує. Signature Algorithm Цим блоком сертифікат завжди завершується, у ньому міститься ідентифікатор алгоритму підпису і підпис вищого блоку.

Далі я рекомендую виконати команду dumpasn1 certificate-twitter.com.der і порівняти щойно прочитане з показаним у дампі, паралельно корисно тримати відкритими RFC 5280 та RF 3280.

Ланцюжки сертифікатів, що засвідчують¶

Центр може видати сертифікат, в якому в полі X509v3 Basic Constraints дозволяється його використання як посвідчувача. Цим сертифікатом також можна підписувати «доменні» сертифікати. Таким чином, всі CA-сертифікати утворюють ланцюжок, а загалом дерево. У вершині цього дерева знаходиться найголовніший сертифікат, він називається кореневим сертифікатом (англійською root certificate).

Система довіри PKI будується таким чином, що довіреним CA-сертифікатом є той, який підписаний іншим довіреним кореневим сертифікатом CA. Вебсайт може разом зі своїм сертифікатом віддати браузеру також і CA-сертифікат, яким він був підписаний. І якщо цей CA-сертифікат підписаний кимось із довірених центрів, що засвідчують, він автоматично стає довіреним.

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

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

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

Сфера застосування сертифікатів не обмежується браузером, звісно. Теоретично будь-який клієнт може сам вибирати, кому він довіряє, а кому ні. У програму може бути жорстко вшитий сертифікат, яким вона перевіряє інші сертифікати, наприклад.

Як вручну перевірити ланцюжок сертифікатів¶

Іноді виникає необхідність перевірити, чи підписано один сертифікат іншим. Це можна зробити через openssl.

Візьмемо три сертифікати з Go Daddy, ось вони: GD_root.pem (це кореневий сертифікат Go Daddy), GD_good.pem, GD_bad.pem. Нам потрібно перевірити, чи підписані сертифікати GD_good.pem та GD_bad.pem кореневим сертифікатом Go Daddy.

Для верифікації використовуємо команду openssl verify , в ній ми повинні вказати файл із «довіреними» сертифікатами, у нашому випадку це один сертифікат GD_root.pem, що вказується через аргумент -CAfile GD_root.pem . Також ми вказуємо свідомо неіснуючий шлях до головного сховища сертифікатів центрів, що засвідчують, щоб у процесі верифікації брав участь лише один сертифікат, це робиться через аргумент -CApath /nope . У нових версіях openssl (починаючи з 1.1.0) введено новий спеціальний параметр -no-CApath .

[user@shell]$ % openssl verify -verbose -x509_strict -CApath /nope -CAfile GD_root.pem GD_bad.pem  GD_bad.pem: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = https://certs.godaddy.com/repository/,
CN = Go Daddy Root Certificate Authority - G2
error 20 at 0 depth lookup:unable to get local issuer certificate

[user@shell]$ % openssl verify -verbose -x509_strict -CApath /nope -CAfile GD_root.pem GD_good.pem  GD_good.pem: OK

І альтернативний варіант (попередній у нових версіях не працює):

[user@shell]$ % openssl verify -verbose -x509_strict -no-CApath -CAfile GD_root.pem GD_bad.pem  C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = https://certs.godaddy.com/repository/, CN = Go Daddy Root Certificate Authority - G2
error 20 at 0 depth lookup: unable to get local issuer certificate
error GD_bad.pem: verification failed

[user@shell]$ % openssl verify -verbose -x509_strict -no-CApath -CAfile GD_root.pem GD_good.pem  GD_good.pem: OK

І ще про сертифікати¶

Невелика демонстрація, як openssl працює з сертифікатами, алгоритми для яких він не знає. Візьмемо цей сертифікат, це кореневий сертифікат Казахстанського центру міжбанківських розрахунків національного банку Республіки Казахстан.

Ось як виглядає спроба роздрукувати його як текст:

[user@shell]$ % openssl x509 -inform DER -in KISC_ROOT_CA_GOST.der -noout -text  Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1e:97:16:12:b3:4f:8d:e4:e8:39:8b:da:34:f5:1e:f5:3f:c6:0f:b8:29:cf:7a:07:c0: 7a:db:f5:9f:e9:12:0b
Signature Algorithm: 1.3.6.1.4.1.6801.1.2.2
Issuer: CN = KISC Root CA, O = KISC, C = KZ
Validity
Not Before: Sep 2 12:28:57 2008 GMT
Not After : Aug 28 12:28:57 2028 GMT
Subject: CN = KISC Root CA, O = KISC, C = KZ
Subject Public Key Info:
Public Key Algorithm: 1.3.6.1.4.1.6801.1.5.8
Безкоштовно скачати Public Key
90096:error:0D09B0A3:asn1 encoding routines:d2i_PublicKey:unknown public key type:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/crypto/asn1/d2i_pu.c:12
90096:error:0B077066:x509 certificate routines:X509_PUBKEY_get:err asn1 lib:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/crypto/asn1/x_pubkey.
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
1E:97:16:12:B3:4F:8D:E4:E8:39:8B:DA:34:F5:1E:F5:3F:C6:0F:B8:29:CF:7A:07:C0: 7A:DB:F5:9F:E9:12:0B
X509v3 Authority Key Identifier:
keyid:1E:97:16:12:B3:4F:8D:E4:E8:39:8B:DA:34:F5:1E:F5:3F:C6:0F:B8:29:CF:7A:07: C0:7A:DB:F5:9F:E9:12:0B
DirName:/CN=KISC Root CA/O=KISC/C=KZ
serial:1E:97:16:12:B3:4F:8D:E4:E8:39:8B:DA:34:F5:1E:F5:3F:C6:0F:B8:29:CF:7A:07: C0:7A:DB:F5:9F:E9:12:0B
Signature Algorithm: 1.3.6.1.4.1.6801.1.2.2
b4:dc:79:0f:a7:94:8f:fa:90:22:18:f9:22:27:30:83:33:59:
af:b9:68:6b:1d:40:75:ad:87:e0:ff:46:37:3c:0a:78:55:b4:
c3:b1:1a:8f:6c:62:37:ad:38:1b:9c:b6:1c:ac:68:16:37:c1:
8e:ae:6e:9c:7a:c4:00:6d:ff:3a

Зверніть увагу на поле Signature Algorithm: 1.3.6.1.4.1.6801.1.2.2, openssl не зміг розпізнати цей алгоритм, тому що в його коді немає такого OID. Якщо ми спробуємо знайти цей OID у репозиторії http://www.oid-info.com/get/1.3.6.1.4.1.6801.1.2.2, то виявимо, що він невідомий. Але їм відомий «батьківський» OID (пам'ятаємо, що схема OID ієрархічна), за адресою http://www.oid-info.com/get/1.3.6.1.4.1.6801 знаходимо координати власника цієї схеми — казахстанська фірма Gamma Technologies , OID попереднього рівня (1.3.6.1.4.1.6801.1.2) видає нам GOST28147, https://ua.wikipedia.org/wiki/ГОСТ_28147-89.

Як бачимо, фірма використовує X.509 для зберігання своїх сертифікатів. Браузер його не зможе переварити, а ось спеціалізований софт цілком. Наприклад, dumpasn1 чудово показує структуру ASN.1-об'єктів.

Наступний файл для препарування — сертифікат центру Бурятії, що засвідчує, завантажте файл ca-bur.der. Пропоную вам самим його завантажити та запустити команду:

[user@shell]$ % openssl x509 -inform DER -in ca-bur.der -noout -text

А потім таку, для розмаїття:

[user@shell]$ % openssl x509 -inform DER -in ca-bur.der -noout -text -nameopt multiline,-esc_msb,utf8