IKEv2 heeft twee handtekeningen: het certificaat en IKE_AUTH
De CA ondertekent het certificaat en de peer ondertekent zijn IKE_AUTH-uitwisseling met een eigen schema. Lees elke handtekening uit het eigen veld en leg beide vast.
Uw ticket zegt dat het certificaat SHA-256 is, terwijl het log van de gateway een ander handtekeningalgoritme noemt, en iemand heeft al een verzoek opgesteld om de CA opnieuw uit te geven. Voordat dat verzoek ergens heen gaat, scheidt u de twee handtekeningen: de ene is de stempel van de uitgever op een openbare sleutel, de andere is het bewijs van de peer dat hij tijdens IKE_AUTH de bijbehorende persoonlijke sleutel bezit. Verschillende componenten kiezen ze, en ze mogen verschillen. Elk ervan lezen op de plek waar het leeft kost twee opdrachten en één tabel.
Lees de handtekening van de uitgever uit het certificaat
De CA zet haar handtekening op een binding tussen een identiteit en een sleutel. Die handtekening legt vast wat de CA bij afgifte deed, niet wat het subject bij verbinden zal doen, dus het algoritme beschrijft de eigen keuze van hash en sleutel van de CA. Een subjectsleutel van het ene type kan onder een CA-sleutel van een ander type staan zonder enige inconsistentie, en het roteren van de CA-sleutel is routine en geen fout. Lees de twee velden en u hebt de helft van de inventaris:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Noteer beide labels als afzonderlijke regels. Het eerste beschrijft de CA, het tweede beschrijft de sleutel van het subject, en geen van beide voorspelt de online handtekening.
Lees de online handtekening uit de IKE-uitwisseling
Tijdens de authenticatie ondertekent elke peer de uitwisselingsgegevens met zijn eigen persoonlijke sleutel, en de andere kant controleert dat bewijs tegen de identiteit, de vertrouwensketen en het beleid van het certificaat. Bij RSA horen de opvulling en de hash bij dit online schema, dus een langere sleutel of een nieuw SHA-256-certificaat kan niet op eigen houtje RSA-PSS kiezen voor de authenticatiehandtekening. De onderhandelde methode verschijnt in het log van de daemon of in zijn verbindingslijst, nooit in het certificaat. Vraag elke kant wat die heeft onderhandeld, want de twee richtingen kunnen verschillen.
ipsec statusall | grep -i "auth\|proposal"Wanneer de ene kant een schema noemt dat de andere niet kan produceren, hebt u de tegenstrijdigheid gevonden waarover het ticket ging. De CA opnieuw uitgeven is daarvoor de verkeerde reparatie, want het certificaat was nooit wat er faalde.
Wat RFC 7427 verandert, en wat niet
De oorspronkelijke methoden zijn per algoritmecombinatie genummerd in RFC 7296. De latere RFC 7427-handtekeninguitbreiding voegt een algemene Digital Signature-methode toe met signalering van ondersteuning voor handtekeninghash, zodat een nieuwe hash geen eigen methodenummer meer nodig heeft. Er wordt over onderhandeld, het wordt niet aangenomen: een peer krijgt de uitbreiding niet omdat zijn bibliotheek dezelfde certificaten kan parseren, en een peer die alleen de oorspronkelijke methoden implementeert, dwingt de gateway er één daarvan te houden. Dat is een beleidsruil met een compatibiliteitskosten, geen defect.
Ondersteuning is per richting en per verbinding, dus test de build die voor u staat in plaats van een bewering op gezinsniveau te vertrouwen. Een capaciteitenmatrix die drie jaar geleden is geschreven, beschrijft builds van drie jaar oud.
Zet vier regels in de inventaris
Het record dat de discussie beëindigt heeft vier regels, elk op een andere plek gelezen en elk door een ander persoon gewijzigd. Vul het in voordat u iets beslist, want juist de verkeerde regel kiest de reparatie.
| Object | Waar u het leest | Wie het wijzigt |
|---|---|---|
| handtekening van de certificaatuitgever | het veld Signature Algorithm van het certificaat | de CA-operator, bij afgifte |
| openbare sleutel van het subject | het veld Public Key Algorithm van het certificaat | wie de subjectsleutel genereert |
| IKE-authenticatieschema | daemonlog of verbindingslijst, auth- en signature-hash-melding | het IKE-profiel op beide peers |
| IKE- en ESP-beveiligingsalgoritmen | de voorstellenlijst van de verbinding | het IPsec-profiel, per richting |
Elke regel draagt zijn eigen compatibiliteitsgevolg. Een wijziging van het ESP-cijfer kiest niet de handtekening van de uitgever, en het versoepelen van de CA-validatie voegt geen online methode toe die de peers nooit hebben onderhandeld. Wanneer een ticket een handtekeningverschil beweert, is de regel die echt fout is bijna nooit de eerste.
Los het oude geval op zonder de PKI te verzwakken
Een oudere peer biedt misschien alleen een schema dat uw beleid niet meer toestaat. De keuzes zijn een tijdsgebonden compatibiliteitsuitzondering, een clientupdate of een andere authenticatieopzet alleen voor die peer. De PKI herbouwen rond een zwakkere certificaathandtekening lost een beperking in de online uitwisseling niet op en verzwakt elke andere dienst die hetzelfde CA vertrouwt. Leg vast welke regel u hebt gewijzigd en wanneer de uitzondering afloopt.
Voer daarna de twee lezingen opnieuw van bovenaf uit, want een wijziging in de ene regel kan verschuiven wat in een andere wordt onderhandeld. De hele inventaris is twee opdrachten en één tabel, en het is hetzelfde werk of de peer nu een router, een laptop of een apparaat is.