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. Запишете кој ред сте го смениле и кога истекува исклучувањето.
Потоа повторно извршете ги двете читања од почеток, бидејќи промената во еден ред може да го помести она што се договара во друг. Целиот попис е две наредби и една табела, и истата работа е без разлика дали партнерот е рутер, преносен сметач или уред.