IKEv2:ssa on kaksi allekirjoitusta: varmenne ja IKE_AUTH
CA allekirjoittaa varmenteen ja vertaiskone allekirjoittaa oman IKE_AUTH-vaihtonsa omalla menetelmällään. Lue kumpikin omasta kentästään ja kirjaa molemmat.
Tikettisi mukaan varmenne on SHA-256, mutta yhdyskäytävän loki nimeää toisen allekirjoitusalgoritmin, ja joku on jo laatinut pyynnön CA:n uudelleenmyöntämisestä. Ennen kuin pyyntö lähtee minnekään, erota kaksi allekirjoitusta: toinen on myöntäjän leima julkiseen avaimeen, toinen on vertaiskoneen todiste siitä, että sillä on vastaava yksityinen avain IKE_AUTHin aikana. Erilaiset komponentit valitsevat ne, ja niiden sallitaan erota. Kummankin lukeminen siitä, missä se elää, vaatii kaksi komentoa ja yhden taulukon.
Lue myöntäjän allekirjoitus varmenteesta
CA asettaa allekirjoituksensa identiteetin ja avaimen väliselle sidokselle. Se allekirjoitus tallentaa, mitä CA teki myönnettäessä, ei sitä, mitä kohde tekee yhdistäessään, joten sen algoritmi kuvaa CA:n omaa hajautus- ja avainvalintaa. Yhden tyypin kohdeavain voi olla toisen tyypin CA-avaimen alla ilman mitään ristiriitaa, ja CA-avaimen vaihto on rutiinia eikä vika. Lue kaksi kenttää, niin sinulla on puolet luettelosta:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Kirjoita molemmat nimikkeet erillisinä merkintöinä. Ensimmäinen kuvaa CA:ta, toinen kohteen avainta, eikä kumpikaan ennusta verkkoyhteyden allekirjoitusta.
Lue verkkoyhteyden allekirjoitus IKE-vaihdosta
Todennuksen aikana kukin vertaiskone allekirjoittaa vaihdon tiedot omalla yksityisellä avaimellaan, ja vastapuoli tarkistaa tämän todisteen varmenteen identiteettiä, luottamussarjaa ja käytäntöä vasten. RSA:ssa täyte ja hajautus kuuluvat tähän verkkomenetelmään, joten pidempi avain tai tuore SHA-256-varmenne ei voi itsestään valita RSA-PSS:ää todennusallegirjoitukselle. Neuvoteltu menetelmä näkyy taustapalvelun lokissa tai sen yhteysluettelossa, ei koskaan varmenteessa. Kysy kummaltakin osapuolelta, mitä se neuvotteli, koska kaksi suuntaa voivat erota.
ipsec statusall | grep -i "auth\|proposal"Kun toinen osapuoli nimeää menetelmän, jota toinen ei voi tuottaa, olet löytänyt sen epäsuhdan, josta tiketti kertoi. CA:n uudelleenmyöntäminen on siihen väärä korjaus, koska varmenne ei ollut koskaan se, mikä petti.
Mitä RFC 7427 muuttaa ja mitä ei
Alkuperäiset menetelmät numeroidaan algoritmiyhdistelmän mukaan RFC 7296:ssa. Myöhempi RFC 7427 -allekirjoituslaajennus lisää yleisen Digital Signature -menetelmän allekirjoituksen hajautustuen signaloinnilla, joten uusi hajautus ei enää tarvitse omaa menetelmänumeroa. Se neuvotellaan, ei oleteta: vertaiskone ei saa laajennusta siksi, että sen kirjasto osaa jäsentää samat varmenteet, ja vertaiskone, joka toteuttaa vain alkuperäiset menetelmät, pakottaa yhdyskäytävän pitämään yhden niistä. Se on käytäntökauppa, jolla on yhteensopivuuskustannus, ei vika.
Tuki on suunnittain ja yhteyksittäin, joten testaa edessäsi oleva koontiversio sen sijaan, että luottaisit perhetason väitteeseen. Kolme vuotta sitten kirjoitettu kyvykkyysmatriisi kuvaa kolme vuotta vanhoja koontiversioita.
Laadi luetteloon neljä riviä
Kiistan päättävässä merkinnässä on neljä riviä, kukin luettu eri paikasta ja kukin eri henkilön muuttama. Täytä se ennen kuin päätät mitään, koska juuri väärä rivi valitsee korjauksen.
| Kohde | Mistä luetaan | Kuka muuttaa |
|---|---|---|
| varmenteen myöntäjän allekirjoitus | varmenteen Signature Algorithm -kenttä | CA:n operaattori, myöntämisen yhteydessä |
| kohteen julkinen avain | varmenteen Public Key Algorithm -kenttä | se, joka luo kohteen avaimen |
| IKE-todennusmenetelmä | taustapalvelun loki tai yhteysluettelo, auth- ja signature-hash-ilmoitus | IKE-profiili molemmissa vertaiskoneissa |
| IKE- ja ESP-suojausalgoritmit | yhteyden ehdotusluettelo | IPsec-profiili, suunnittain |
Jokainen rivi kantaa oman yhteensopivuusvaikutuksensa. ESP-salauksen muutos ei valitse myöntäjän allekirjoitusta, eikä CA-validoinnin löysääminen lisää verkkomenetelmää, josta vertaiskoneet eivät koskaan sopineet. Kun tiketti väittää allekirjoituksen epäsuhtaa, todella väärä rivi ei ole lähes koskaan ensimmäinen.
Ratkaise vanha tapaus heikentämättä PKI:tä
Vanhempi vertaiskone voi tarjota vain menetelmää, jota käytäntösi ei enää salli. Vaihtoehdot ovat aikarajattu yhteensopivuuspoikkeus, asiakaspäivitys tai erilainen todennusjärjestely vain sille vertaiskoneelle. PKI:n rakentaminen uudelleen heikomman varmenneallekirjoituksen ympärille ei korjaa verkkoyhteyden vaihdon rajoitusta ja heikentää kaikkia muita palveluita, jotka luottavat samaan CA:han. Kirjaa, minkä rivin muutit ja milloin poikkeus päättyy.
Aja sitten molemmat luvut uudelleen ylhäältä, koska yhden rivin muutos voi siirtää sitä, mistä toisessa neuvotellaan. Koko luettelo on kaksi komentoa ja yksi taulukko, ja työ on sama, olipa vertaiskone reititin, kannettava tai laite.