IKEv2 има два подписа: сертификат и IKE_AUTH
CA подписва сертификата, а партньорът подписва своя обмен IKE_AUTH по собствена схема. Прочетете всеки от своето поле и запишете двата.
Билетът ви казва, че сертификатът е SHA-256, а журналът на шлюза посочва различен алгоритъм за подпис, и някой вече е изготвил заявка за преиздаване на CA. Преди тази заявка да отиде някъде, разделете двата подписа: единият е печатът на издателя върху публичен ключ, другият е доказателството на партньора, че притежава съответния частен ключ по време на IKE_AUTH. Различни компоненти ги избират и им е позволено да се различават. Четенето на всеки от мястото, където живее, отнема две команди и една таблица.
Прочетете подписа на издателя от сертификата
CA поставя подписа си върху връзка между идентичност и ключ. Този подпис записва какво е направил CA при издаването, а не какво ще направи субектът при свързване, затова алгоритъмът му описва собствения избор на хеш и ключ на CA. Ключ на субект от един тип може да стои под ключ на CA от друг тип без никакво противоречие, а ротацията на ключ на CA е рутина, а не дефект. Прочетете двете полета и имате половината от инвентара:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Запишете двете означения като отделни редове. Първото описва CA, второто описва ключа на субекта и нито едно от тях не предсказва онлайн подписа.
Прочетете онлайн подписа от обмена IKE
По време на удостоверяването всеки партньор подписва данните за обмена със своя частен ключ, а другата страна проверява това доказателство спрямо идентичността на сертификата, веригата на доверие и политиката. При RSA подпълването и хешът принадлежат на тази онлайн схема, така че по-дълъг ключ или нов сертификат SHA-256 не може сам да избере RSA-PSS за подписа за удостоверяване. Договореният метод се появява в журнала на демона или в списъка му със свързвания, никога в сертификата. Попитайте всяка страна какво е договорила, защото двете посоки могат да се различават.
ipsec statusall | grep -i "auth\|proposal"Когато едната страна посочи схема, която другата не може да произведе, вие сте намерили несъответствието, за което е бил билетът. Преиздаването на CA е грешният ремонт за него, защото сертификатът никога не е бил това, което се е провалило.
Какво променя RFC 7427 и какво не
Първоначалните методи са номерирани по комбинация от алгоритми в RFC 7296. По-късното разширение за подпис RFC 7427 добавя общ метод Digital Signature със сигнализиране за поддръжка на хеш на подписа, така че нов хеш вече не се нуждае от собствен номер на метод. То се договаря, а не се предполага: партньор не получава разширението, защото библиотеката му може да анализира същите сертификати, а партньор, който реализира само първоначалните методи, принуждава шлюза да запази един от тях. Това е политическа размяна с цена за съвместимост, а не дефект.
Поддръжката е за всяка посока и всяка връзка, затова тествайте конструкцията пред вас, вместо да се доверявате на твърдение на ниво семейство. Матрица на възможностите, написана преди три години, описва конструкции на три години.
Поставете четири реда в инвентара
Записът, който прекратява спора, има четири реда, всеки прочетен от различно място и всеки променен от различен човек. Попълнете го преди да решите каквото и да е, защото грешният ред определя поправката.
| Обект | Откъде се чете | Кой го променя |
|---|---|---|
| подпис на издателя на сертификата | полето Signature Algorithm на сертификата | операторът на CA, при издаването |
| публичен ключ на субекта | полето Public Key Algorithm на сертификата | този, който генерира ключа на субекта |
| схема за удостоверяване IKE | журнал на демона или списък със свързвания, известие auth и signature-hash | профилът IKE на двамата партньори |
| алгоритми за защита на IKE и ESP | списъкът с предложения на връзката | профилът IPsec, по посока |
Всеки ред носи собствена последица за съвместимостта. Промяна на шифъра на ESP не избира подписа на издателя, а разхлабването на проверката на CA не добавя онлайн метод, който партньорите никога не са договаряли. Когато билет твърди несъответствие на подписа, редът, който наистина е грешен, почти никога не е първият.
Решете стария случай, без да отслабвате PKI
По-стар партньор може да предложи само схема, която политиката ви вече не разрешава. Изборът е ограничено във времето изключение за съвместимост, актуализация на клиента или различна уредба за удостоверяване само за този партньор. Преустройството на PKI около по-слаб подпис на сертификата не поправя ограничение в онлайн обмена и отслабва всяка друга услуга, която се доверява на същия CA. Запишете кой ред сте променили и кога изключението изтича.
След това изпълнете двете четения отначало, защото промяна в един ред може да измести какво се договаря в друг. Целият инвентар е две команди и една таблица и това е същата работа, независимо дали партньорът е рутер, лаптоп или устройство.