Список відкликаних сертифікатів
Список відкликаних сертифікатів (або СВС) — це «список цифрових сертифікатів, які були відкликані центром сертифікації (ЦСК) до запланованої дати закінчення терміну дії та яким більше не можна довіряти».[1] СВС більше не потрібуються CA/Browser forum[en][2], оскільки замість них дедалі частіше використовуються альтернативні технології відкликання сертифікатів (такі як OCSP).[3][4] Тим не менш, СВС все ще широко використовуються центрами сертифікації.[5]
Стани відкликання[ред. | ред. код]
У RFC 5280 визначено два різні стани відкликання:
- Відкликано
- Сертифікат безповоротно відкликається, якщо, наприклад, виявлено, що центр сертифікації (ЦСК) неправильно видав сертифікат, або якщо вважається, що особистий ключ було скомпрометовано. Сертифікати також можуть бути відкликані через недотримання визначеною організацією вимог політики, як-от публікація фальшивих документів, спотворення поведінки програмного забезпечення або порушення будь-якої іншої політики, визначеної оператором ЦСК або його клієнтом. Найпоширенішою причиною відкликання є те, що користувач більше не володіє особистим ключем (наприклад, токен, що містить закритий ключ, було втрачено або вкрадено).
- Блоковано
- Цей оборотний статус можна використовувати для позначення тимчасової недійсності сертифіката (наприклад, якщо користувач не впевнений, що особистий ключ було втрачено). Якщо в цьому випадку особистий ключ було знайдено, і ніхто не мав до нього доступу, статус можна було відновити, і сертифікат знову стане дійсним, таким чином сертифікат буде видалено із майбутніх СВС.
Підстави для відкликання[ред. | ред. код]
Підставами для відкликання сертифіката згідно з RFC 5280[6] є:
unspecified(0)keyCompromise(1)CACompromise(2)affiliationChanged(3)superseded(4)cessationOfOperation(5)certificateHold(6)removeFromCBC(8)privilegeWithdrawn(9)aACompromise(10)
Зверніть увагу, що значення 7 не використовується.
Публікація списків відкликаних сертифікатів[ред. | ред. код]
СВС створюється та публікується періодично, часто через певний інтервал. СВС також можна опублікувати одразу після відкликання сертифіката. СВС видається емітентом СВС, яким зазвичай є центр сертифікації, що також видав відповідні сертифікати, але як альтернатива це може бути інший довірений орган. Усі СВС мають термін дії, протягом якого вони дійсні; цей часовий проміжок часто становить 24 години або менше. Протягом терміну дії СВС програма з підтримкою ІВК може перевіряти сертифікат перед використанням.
Щоб запобігти спуфінгу або атакам на відмову в обслуговуванні, СВС зазвичай мають цифровий підпис, пов'язаний із ЦСК, яким вони опубліковані. Щоб перевірити певний СВС, перш ніж покладатися на нього, потрібен сертифікат відповідного ЦСК.
Сертифікати, для яких слід підтримувати СВС, часто є сертифікатами відкритого ключа X.509, оскільки цей формат зазвичай використовується в схемах ІВК.
Відкликання vs. закінчення терміну дії[ред. | ред. код]
Терміни дії не замінюють СВС. Хоча всі прострочені сертифікати вважаються недійсними, не всі непрострочені сертифікати повинні бути дійсними. СВС або інші методи перевірки сертифікатів є необхідною частиною будь-якої належної роботи ІВК, оскільки очікується, що помилки під час перевірки сертифікатів і керування ключами траплятимуться при реальних операціях.
Вартий уваги приклад: сертифікат для Microsoft був помилково виданий невідомій особі, яка успішно видала себе за Microsoft перед центром сертифікації, уклавши контракт на обслуговування системи «сертифікатів видавця» ActiveX (VeriSign).[7] Корпорація Майкрософт побачила необхідність виправити свою підсистему криптографії, щоб вона перевіряла статус сертифікатів, перш ніж довіряти їм. Як короткотермінове виправлення було випущено патч для відповідного програмного забезпечення Microsoft (в основному Windows), у якому два сертифікати, про які йде мова, перераховані як «відкликані».[8]
Проблеми зі списками відкликаних сертифікатів[ред. | ред. код]
Найкращі практики вимагають, щоб незалежно від того, де і як підтримується статус сертифіката, його потрібно перевіряти щоразу, коли хтось хоче покладатися на сертифікат. Якщо цього не зробити, відкликаний сертифікат може бути помилково прийнятий як дійсний. Це означає, що для ефективного використання ІВК потрібно мати доступ до поточних СВС. Ця вимога перевірки в режимі онлайн зводить нанівець одну з головних переваг ІВК над протоколами симетричної криптографії, а саме те, що сертифікат є «самоавтентифікованим». Симетричні системи, такі як Kerberos, також залежать від існування он-лайнових служб (у випадку Kerberos це центр розподілу ключів[en]).
Існування СВС передбачає потребу в тому, щоб хтось (або якась організація) забезпечував дотримання політики та відкликав сертифікати, які вважаються такими, що суперечать політиці сертифікації. Якщо сертифікат помилково відкликано, можуть виникнути значні проблеми. Оскільки на центр сертифікації покладено завдання забезпечити дотримання політики сертифікації для видачі сертифікатів, вони зазвичай відповідають за визначення того, чи є доречним відкликання, інтерпретуючи політику сертифікації.
Необхідність звернення до СВС (або іншої служби статусу сертифіката) перед прийняттям сертифіката створює потенційну атаку типу «відмова в обслуговуванні» проти ІВК. Якщо прийняти сертифікат не вдається через відсутність доступного дійсного СВС, тоді не можуть виконуватися жодні операції, залежні від прийняття сертифіката. Ця проблема також існує для систем Kerberos, де неможливість отримати поточний маркер автентифікації завадить доступу до системи.
Альтернативою використанню СВС є протокол перевірки сертифіката, відомий як протокол онлайнового статусу сертифіката (OCSP). Основною перевагою OCSP є потреба в меншій пропускній здатності мережі, що дозволяє перевіряти статус у режимі реального часу або майже в режимі реального часу для великих обсягів або великих операцій.
Починаючи з Firefox 28, Mozilla оголосила про припинення використання СВС на користь OCSP.[3]
З часом файли СВС можуть збільшуватися, наприклад, в уряді США, для певних установ у до кількох мегабайтів. Тому були розроблені інкрементальні СВС[9], які іноді називають «дельта-СВС». Однак лише деякі клієнти їх впроваджують.[10]
Списки відкликання уповноважених[ред. | ред. код]
Список відкликаних уповноважених (ARL) — це форма СВС, що містить відкликані сертифікати, видані центрам сертифікації, на відміну від СВС, які містять відкликані сертифікати кінцевих об'єктів.[11][12]
Див. також[ред. | ред. код]
Примітки[ред. | ред. код]
- ↑ What is Certificate Revocation List (CRL)? - Definition from WhatIs.com. TechTarget. Процитовано 26 жовтня 2017.
- ↑ Baseline Requirements. CAB Forum. Архів оригіналу за 7 січня 2014. Процитовано 1 листопада 2021.
- ↑ а б As of Firefox 28, Firefox will not fetch CRLs during EV certificate validation. groups.google.com.
- ↑ RFC 6960: X.509 Internet Public Key Infrastructure: Online Certificate Status Protocol - OCSP. Internet Engineering Task Force (IETF). June 2013. Архів оригіналу за 15 грудня 2018. Процитовано 24 листопада 2021.
In lieu of, or as a supplement to, checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of certificates. ... OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information.
- ↑ Korzhitskii, Nikita; Carlsson, Niklas. Revocation Statuses on the Internet.
- ↑ RFC 5280. tools.ietf.org. IETF. с. 69. section 5.3.1, Reason Code. Процитовано 9 травня 2019.
- ↑ Robert Lemos. Microsoft warns of hijacked certificates - CNET News. News.cnet.com. Процитовано 9 травня 2019.
- ↑ Microsoft Security Bulletin MS01-017 : Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard. Technet.microsoft.com. 20 липня 2018. Процитовано 9 травня 2019.
- ↑ RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Tools.ietf.org. Процитовано 9 травня 2019.
- ↑ Archiveddocs (20 березня 2018). Configure CRL and Delta CRL Overlap Periods. Microsoft Docs. Процитовано 25 червня 2020.
- ↑ IBM (4 лютого 2021). Setting up LDAP servers. IBM Knowledge Center. Процитовано 18 лютого 2021.
- ↑ IBM. Creating a distribution point ARL. IBM Knowledge Center. Процитовано 18 лютого 2021.
| ||||||||||||||||||||||||||||||||||||||||||||||||
