Mac IKEv2 ECDSA: hokker sertifikaattype heart by de klient?
Op in Mac beskriuwt ECDSA256 yn 'e IKEv2-ynstellingen it lokale identiteitssertifikaat, net de gateway of de hantekening fan 'e útjouwer. Lês elke rol foardat jo kieze.
Op macOS beantwurdet de ECDSA-keuze yn in IKEv2-kliïntynstelling in smelle fraach: hokker sertifikaat bewiist de identiteit fan 'e Mac. It beskriuwt net it gateway-sertifikaat, de hantekening dy't it kliïntsertifikaat útjûn hat, of it fersiferingsfoarstel foar de tunnel. Dy fjouwer rollen as ien kompatibiliteitsfraach behannelje is de manier wêrop in korrekte lokale ynstelling de skuld krijt foar in ôfwiking oan 'e serverkant. De beslissing is lyts, mar it bewiismateriaal dat brûkt wurdt om it te nimmen moat sekuer wêze.
It fjild neamt ien sertifikaat: de lokale identiteit
De Network Extension API fan Apple biedt in sertifikaattype foar de kliïntreferinsje, wêrûnder NEVPNIKEv2CertificateType.ECDSA256, dokumintearre as it sertifikaattype ECDSA p-256. De eigenskip jildt foar it sertifikaat dat fia identityReference of identityData levere wurdt.
Dat betsjut dat de beslissing giet oer it sertifikaat dat de Mac presintearret, plus de partikuliere kaai dy't dêr by heart. Kies it type dat oerienkomt mei de iepenbiere kaai fan dat bledsertifikaat en leverje de identiteit fia it stipe meganisme. As de Mac gjin brûkbere partikuliere kaai foar de identiteit hat, kin de typekar de ferbining net rêde.
Beheard profilen nimme deselde beslissing fia CertificateType fan 'e IKEv2-lading, tegearre mei in sertifikaatreferinsje lykas PayloadCertificateUUID. Dy fjilden hawwe betingsten en in skema foar de OS-ferzje fan it doel; in neaken typewearde dy't yn in profyl kopiearre is, is net ynstallearber, en in ynstellingsfinster lit miskien net elke API-opsje sjen. Kontrolearje de betingsten fan 'e lading foar dy ferzje foar de ynset.
Beslis op rol, net op it sertifikaatlabel
Lês it fjild dat jo op it punt steane te feroarjen en freegje hokker sertifikaat it oanwiist. De labels yn in sertifikaatbesjogger mingskje it ûnderwerp, de útjouwer en it hantekeningalgoritme, en mar ien dêrfan heart by de kar fan 'e kliïntidentiteit.
| 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 |
As de sertifikaatbesjogger in ECDSA-hantekening fan 'e CA lit sjen, beskriuwt dat de hantekenkaai fan 'e útjouwer. De eigen kaai fan 'e kliïnt kin noch hieltyd RSA wêze, en it typefjild moat de kliïntkaai folgje ynstee fan 'e hantekeningrige. Dizze iene betizing ferklearret in soad rapporten "ECDSA is konfigurearre, mar de ferbining mislearret". Fergelykje it kaaitype yn it bled mei it type dat yn it profyl keazen is foar't jo wat feroarje.
De beslissing wurdt ienfâldiger sadra it bled identifisearre is: ECDSA256 foar in p-256 kliïntkaai, in oar stipe type foar in oare kaai. As it kliïntsertifikaat en syn kaai net oerienkomme, reparearje dat pear foar't jo it VPN-profyl feroarje.
It gateway-sertifikaat is in aparte beslissing
De gateway presintearret syn eigen sertifikaat en de Mac falidearret it tsjin in fertrouwensanker en in ferwachte namme. Oft dat sertifikaat ECDSA, RSA of in oar kaaitype brûkt, is in eigenskip fan 'e server, net fan 'e ynstelling foar kliïntidentiteit.
Lokale stipe foar in ECDSA-kliïntsertifikaat bewiist net dat elk gateway-sertifikaat, elke kromme of elke serverautentikaasjekonfiguraasje gearwurkje sil. Kontrolearje de identiteit fan 'e server, syn keatling en syn IKE-autentikaasjemetoade as aparte ynfier en test mei it profyl dat echt ynset wurde sil.
As it gateway-sertifikaat it probleem is, ferskynt it symptoom meastentiids by de falidaasje fan 'e peir ynstee fan by de identiteitskar. Lês de mislearringsstap foar't jo it kliïnttype feroarje, want in fertrouwensflater en in ôfwiking fan 'e kliïntkaai diele gjin oplossing.
De hantekening fan 'e útjouwer en de kaaiôfspraakgroep binne net it klienttype
X.509 hâldt de iepenbiere kaai fan it ûnderwerp en de hantekening fan 'e útjouwer yn ferskillende fjilden. De iepenbiere-kaaiynformaasje fan it ûnderwerp beskriuwt de kaai yn it sertifikaat; it hantekeningalgoritme beskriuwt de kaai fan 'e CA en de hantekingsoperaasje. Allinnich it earste komt oerien mei de ynstelling foar sertifikaattype.
De IKE- en Child SA-foarstellen binne in oare as. In ECDSA-sertifikaattype is gjin ESP-fersiferingskar, en it feroarjen fan 'e kaaiôfspraakgroep selektearret gjin sertifikaattype. In profyl kin jildige foarstellen en it ferkearde identiteitstype hawwe, of it goede identiteitstype en in foarstel dat de peir ôfwiist.
Hâld de trije rigels apart yn it feroaringsregister: identiteitssertifikaat en kaai, fertrouwensynfier fan 'e gateway, en foarstelalgoritmen. Se gearfoegje yn ien notysje "krypto-ynstellingen" makket de folgjende flater ûnmooglik ta te skriuwen.
Ferklearje de beslissing mei de fjilden dy't jo konfigurearre hawwe
Kontrolearje de identiteit dêr't it profyl echt nei ferwiist, en befêstigje dan dat it sertifikaat by dy referinsje de ferwachte iepenbiere kaai en in brûkbere partikuliere kaai hat. It toande type yn 'e ynterfaasje, it referearre sertifikaat en de kaai op it apparaat moatte oerienkomme.
Befêstigje dêrnei de ynfier fan 'e gateway: de ferwachte servernamme, it fertrouwensanker en de IKE-autentikaasjemetoade. Ferbyn jo úteinlik en lês wêr't de hânskudder stopet. In flater foar de identiteitsútwikseling wiist fuort fan dizze ynstelling; in flater by de falidaasje fan 'e peir wiist nei de gateway-kant.
Skriuw it keazen type, de identiteitsreferinsje en it ûnderwerp fan it gateway-sertifikaat yn 'e ynsetnotysjes. De folgjende profylbywurking kin elk dêrfan feroarje, en trije neamde wearden fergelykje flugger as in skermôfdruk fan in ynstellingspaniel.