IKEv2 ima dva podpisa: potrdilo in IKE_AUTH

Vaša prijava pravi, da je potrdilo SHA-256, medtem ko dnevnik prehoda navaja drug algoritem podpisa, in nekdo je že pripravil zahtevo za ponovno izdajo CA. Preden ta zahteva kam gre, ločite podpisa: eden je žig izdajatelja na javnem ključu, drugi je dokaz partnerja, da ima med IKE_AUTH ustrezen zasebni ključ. Izbereta ju različne komponente in lahko se razlikujeta. Branje vsakega s kraja, kjer živi, zahteva dva ukaza in eno tabelo.

Preberite podpis izdajatelja iz potrdila

CA položi svoj podpis na vez med identiteto in ključem. Ta podpis zabeleži, kaj je CA storila ob izdaji, ne kaj bo subjekt storil ob povezavi, zato njegov algoritem opisuje lastno izbiro zgoščevalne funkcije in ključa pri CA. Ključ subjekta ene vrste je lahko pod ključem CA druge vrste brez vsakršne nedoslednosti, rotacija ključa CA pa je rutina in ne okvara. Preberite obe polji in imate polovico seznama:

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

Zapišite obe oznaki kot ločeni postavki. Prva opisuje CA, druga opisuje ključ subjekta, in nobena ne napoveduje spletnega podpisa.

Preberite spletni podpis iz izmenjave IKE

Med overjanjem vsak partner podpiše podatke izmenjave s svojim zasebnim ključem, druga stran pa ta dokaz preveri glede na identiteto, verigo zaupanja in politiko potrdila. Pri RSA zapolnitev in zgoščevalna vrednost pripadata tej spletni shemi, zato daljši ključ ali novo potrdilo SHA-256 samo po sebi ne more izbrati RSA-PSS za overitveni podpis. Dogovorjena metoda se pojavi v dnevniku demona ali na njegovem seznamu povezav, nikoli v potrdilu. Vsako stran vprašajte, o čem se je dogovorila, ker se smeri lahko razlikujeta.

ipsec statusall | grep -i "auth\|proposal"

Ko ena stran navede shemo, ki je druga ne more ustvariti, ste našli neskladje, o katerem je bila prijava. Ponovna izdaja CA je za to napačno popravilo, ker potrdilo ni bilo nikoli tisto, kar je odpovedalo.

Kaj spremeni RFC 7427 in kaj ne

Prvotne metode so oštevilčene po kombinaciji algoritmov v RFC 7296. Poznejša razširitev podpisa RFC 7427 doda splošno metodo Digital Signature s signalizacijo podpore zgoščevalni vrednosti podpisa, zato nova zgoščevalna vrednost ne potrebuje več svoje številke metode. Dogovarja se, ne predpostavlja: partner razširitve ne dobi zato, ker njegova knjižnica zna razčleniti ista potrdila, partner, ki izvaja le prvotne metode, pa prisili prehod, da obdrži eno od njih. To je politična menjava s stroškom združljivosti, ne napaka.

Podpora je po smereh in po povezavah, zato preizkusite gradnjo, ki je pred vami, namesto da zaupate trditvi na ravni družine. Matrika zmogljivosti, napisana pred tremi leti, opisuje tri leta stare gradnje.

V seznam vstavite štiri vrstice

Zapis, ki konča razpravo, ima štiri vrstice, vsaka prebrana na drugem mestu in vsaka spremenjena s strani druge osebe. Izpolnite ga, preden karkoli odločite, ker prav napačna vrstica izbere popravilo.

Vsaka vrstica nosi svojo posledico za združljivost. Sprememba šifre ESP ne izbere podpisa izdajatelja, popuščanje pri preverjanju CA pa ne doda spletne metode, o kateri se partnerja nista nikoli dogovorila. Ko prijava zatrjuje neskladje podpisa, vrstica, ki je res napačna, skoraj nikoli ni prva.

Rešite stari primer, ne da bi oslabili PKI

Starejši partner lahko ponudi le shemo, ki je vaša politika ne dovoljuje več. Možnosti so časovno omejena izjema za združljivost, posodobitev odjemalca ali drugačna ureditev overjanja samo za tega partnerja. Preoblikovanje PKI okoli šibkejšega podpisa potrdila ne odpravi omejitve pri spletni izmenjavi in oslabi vsako drugo storitev, ki zaupa isti CA. Zapišite, katero vrstico ste spremenili in kdaj izjema poteče.

Nato znova zaženite obe branji od začetka, ker lahko sprememba v eni vrstici premakne tisto, o čemer se dogovarjata v drugi. Celoten seznam sta dva ukaza in ena tabela, in delo je enako, ne glede na to, ali je partner usmerjevalnik, prenosnik ali naprava.