Mac IKEv2 ECDSA: kiu atestila tipo apartenas al la kliento?
Sur Mac, ECDSA256 en la agordoj de IKEv2 priskribas la lokan identecan atestilon, ne la enirejon aŭ la subskribon de la eldoninto. Legu ĉiun rolon antaŭ ol elekti.
En macOS, la elekto de ECDSA en agordo de IKEv2-kliento respondas al mallarĝa demando: kiu atestilo pruvas la identecon de la Mac. Ĝi ne priskribas la atestilon de la enirejo, la subskribon, kiu eldonis la klientan atestilon, nek la ĉifran proponon por la tunelo. Trakti tiujn kvar rolojn kiel unu demandon pri kongrueco estas la maniero, kiel ĝusta loka agordo estas kulpigata pri malkongruo ĉe la servila flanko. La decido estas malgranda, sed la pruvoj uzataj por ĝi devas esti precizaj.
La kampo nomas unu atestilon: la lokan identecon
La Network Extension API de Apple elmetas atestilan tipon por la klientaj legitimiloj, inkluzive de NEVPNIKEv2CertificateType.ECDSA256, dokumentita kiel la atestila tipo ECDSA p-256. La eco aplikiĝas al la atestilo liverita per identityReference aŭ identityData.
Tio signifas, ke la decido temas pri la atestilo, kiun la Mac prezentas, kune kun la privata ŝlosilo, kiu apartenas al ĝi. Elektu la tipon, kiu kongruas kun la publika ŝlosilo de tiu foli-atestilo, kaj liveru la identecon per la subtenata mekanismo. Se la Mac ne havas uzeblan privatan ŝlosilon por la identeco, la tipa elekto ne povas savi la konekton.
Administrataj profiloj faras la saman decidon per CertificateType de la IKEv2-ŝarĝo, kune kun atestila referenco kiel PayloadCertificateUUID. Tiuj kampoj havas antaŭkondiĉojn kaj skemon por la cela OS-eldono; nuda tipa valoro kopiita en profilon ne estas instalebla, kaj agorda fenestro eble ne montras ĉiun API-opcion. Kontrolu la antaŭkondiĉojn de la ŝarĝo por tiu eldono antaŭ la deplojo.
Decidu laŭ rolo, ne laŭ la atestila etikedo
Legu la kampon, kiun vi baldaŭ ŝanĝos, kaj demandu, al kiu atestilo ĝi montras. La etikedoj en atestila rigardilo miksas la subjekton, la eldoninton kaj la subskriban algoritmon, kaj nur unu el ili apartenas al la elekto de klienta identeco.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
Se la atestila rigardilo montras ECDSA-subskribon de la CA, tio priskribas la subskriban ŝlosilon de la eldoninto. La propra ŝlosilo de la kliento povas ankoraŭ esti RSA, kaj la tipa kampo sekvu la klientan ŝlosilon, ne la subskriban linion. Ĉi tiu unu konfuzo klarigas multajn raportojn "ECDSA estas agordita, sed la konekto malsukcesas". Komparu la ŝlosilan tipon en la folio kun la tipo elektita en la profilo antaŭ ol ŝanĝi ion ajn.
La decido plisimpliĝas, kiam la folio estas identigita: ECDSA256 por p-256 klienta ŝlosilo, alia subtenata tipo por malsama ŝlosilo. Se la klienta atestilo kaj ĝia ŝlosilo ne kongruas, riparu tiun paron antaŭ ol ŝanĝi la VPN-profilon.
La atestilo de la enirejo estas aparta decido
La enirejo prezentas sian propran atestilon kaj la Mac validigas ĝin kontraŭ fida ankro kaj atendata nomo. Ĉu tiu atestilo uzas ECDSA, RSA aŭ alian ŝlosilan tipon estas eco de la servilo, ne de la agordo de klienta identeco.
Loka subteno por ECDSA-klienta atestilo ne pruvas, ke ĉiu atestilo de enirejo, kurbo aŭ servila aŭtentiga agordo interoperacios. Kontrolu la identecon de la servilo, ĝian ĉenon kaj ĝian IKE-aŭtentigan metodon kiel apartajn enigojn, kaj testu per la profilo, kiu efektive estos deplojita.
Se la atestilo de la enirejo estas la problemo, la simptomo kutime aperas dum validigo de la samtavolano, ne ĉe la identeca elekto. Legu la malsukcesan etapon antaŭ ol ŝanĝi la klientan tipon, ĉar fida malsukceso kaj malkongruo de klienta ŝlosilo ne havas komunan riparon.
La subskribo de la eldoninto kaj la ŝlosilkonsenta grupo ne estas la klienta tipo
X.509 tenas la publikan ŝlosilon de la subjekto kaj la subskribon de la eldoninto en malsamaj kampoj. La informoj pri publika ŝlosilo de la subjekto priskribas la ŝlosilon en la atestilo; la subskriba algoritmo priskribas la ŝlosilon de la CA kaj la subskriban operacion. Nur la unua kongruas kun la agordo de atestila tipo.
La proponoj de IKE kaj Child SA estas alia akso. Atestila tipo ECDSA ne estas elekto de ESP-ĉifrado, kaj ŝanĝi la ŝlosilkonsentan grupon ne elektas atestilan tipon. Profilo povas havi validajn proponojn kaj la malĝustan identecan tipon, aŭ la ĝustan identecan tipon kaj proponon, kiun la samtavolano malakceptas.
Tenu la tri liniojn aparte en la ŝanĝprotokolo: identeca atestilo kaj ŝlosilo, fidaj enigoj de la enirejo, kaj proponaj algoritmoj. Kunigi ilin en unu noton pri "kriptaj agordoj" igas la sekvan malsukceson nefarebla atribui.
Kontrolu la decidon per la kampoj, kiujn vi agordis
Kontrolu la identecon, al kiu la profilo efektive referencas, poste konfirmu, ke la atestilo ĉe tiu referenco havas la atendatan publikan ŝlosilon kaj uzeblan privatan ŝlosilon. La montrata tipo en la interfaco, la referencata atestilo kaj la ŝlosilo sur la aparato devas kongrui.
Poste konfirmu la enigojn de la enirejo: la atendata servila nomo, la fida ankro kaj la IKE-aŭtentiga metodo. Fine, konektiĝu kaj legu, kie la manpremo haltas. Malsukceso antaŭ la identeca interŝanĝo montras for de ĉi tiu agordo; malsukceso ĉe validigo de la samtavolano montras al la enireja flanko.
Notu la elektitan tipon, la identecan referencon kaj la subjekton de la enireja atestilo en la deplojaj notoj. La sekva profila ĝisdatigo povas ŝanĝi iun ajn el ili, kaj tri nomitaj valoroj estas pli rapide kompareblaj ol ekrankopio de agorda panelo.