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

З’ясуйте, який сертифікат насправді спливає

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

Якір довіри зазвичай найдовговічніший об’єкт і найменш імовірна причина.

Чому жива сесія може пережити дату

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

Вважайте дату крайнім терміном для нових входів, а час життя сесії — позиченим часом.

Перевірте годинник, перш ніж звинувачувати сертифікат

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

Годинник, що скидається під час завантаження, пояснює збої, які з’являються лише після відключення електроенергії.

Продовжте через орган, що його видав

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

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

Доведіть це новим входом, збережіть шлях відкату

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

Наявні сесії можуть ще відображати попередній стан, тож вони нічого не доводять в жодному напрямку.

Порядок, який я використовую того дня

Підтвердьте спливаючий об’єкт і його ланцюжок, потім підтвердьте годинники:

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

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

Схожі статті