Mac IKEv2 ECDSA: watter tipe sertifikaat hoort by die kliënt?
Op 'n Mac beskryf ECDSA256 in die IKEv2-instellings die plaaslike identiteitsertifikaat, nie die poort of die uitreiker se handtekening nie. Lees elke rol voordat jy kies.
Op macOS beantwoord die ECDSA-keuse in 'n IKEv2-kliëntinstelling 'n eng vraag: watter sertifikaat bewys die Mac se identiteit. Dit beskryf nie die poortsertifikaat, die handtekening wat die kliëntsertifikaat uitgereik het, of die enkripsievoorstel vir die tonnel nie. Om daardie vier rolle as een verenigbaarheidsvraag te behandel, is hoe 'n korrekte plaaslike instelling die skuld kry vir 'n bedienerkant-wanpassing. Die besluit is klein, maar die bewyse wat gebruik word om dit te maak, moet presies wees.
Die veld benoem een sertifikaat: die plaaslike identiteit
Apple se Network Extension API stel 'n sertifikaattipe vir die kliëntbewys bloot, insluitend NEVPNIKEv2CertificateType.ECDSA256, gedokumenteer as die ECDSA p-256 sertifikaattipe. Die eienskap is van toepassing op die sertifikaat wat deur identityReference of identityData verskaf word.
Dit beteken die besluit handel oor die sertifikaat wat die Mac voorlê, plus die privaatsleutel wat daarmee saamgaan. Kies die tipe wat by daardie bladsertifikaat se publieke sleutel pas en verskaf die identiteit deur die ondersteunde meganisme. As die Mac geen bruikbare privaatsleutel vir die identiteit het nie, kan die tipekeuse nie die verbinding red nie.
Bestuurde profiele maak dieselfde besluit deur die IKEv2-lading se CertificateType, gepaard met 'n sertifikaatverwysing soos PayloadCertificateUUID. Daardie velde het voorvereistes en 'n skema vir die teiken-OS-weergawe; 'n kaal tipewaarde wat in 'n profiel gekopieer word, is nie installeerbaar nie, en 'n instellingsvenster wys dalk nie elke API-opsie nie. Kontroleer die lading se voorvereistes vir daardie weergawe voor ontplooiing.
Besluit volgens rol, nie volgens die sertifikaatetiket nie
Lees die veld wat jy op die punt staan om te verander en vra na watter sertifikaat dit wys. Die etikette in 'n sertifikaatkyker meng die subjek, die uitreiker en die handtekeningalgoritme, en net een daarvan hoort by die kliëntidentiteitkeuse.
| 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 die sertifikaatkyker 'n ECDSA-handtekening van die CA wys, beskryf dit die uitreiker se ondertekeningsleutel. Die kliënt se eie sleutel kan steeds RSA wees, en die tipeveld moet die kliëntsleutel volg eerder as die handtekeninglyn. Hierdie enkele verwarring verklaar baie "ECDSA is opgestel maar die verbinding misluk"-verslae. Vergelyk die sleuteltipe in die blad met die tipe wat in die profiel gekies is voordat jy enigiets verander.
Die besluit word eenvoudiger sodra die blad geïdentifiseer is: ECDSA256 vir 'n p-256 kliëntsleutel, 'n ander ondersteunde tipe vir 'n ander sleutel. As die kliëntsertifikaat en sy sleutel nie pas nie, maak daardie paar reg voordat jy die VPN-profiel verander.
Die poortsertifikaat is 'n aparte besluit
Die poort bied sy eie sertifikaat aan en die Mac valideer dit teen 'n vertrouensanker en 'n verwagte naam. Of daardie sertifikaat ECDSA, RSA of 'n ander sleuteltipe gebruik, is 'n eienskap van die bediener, nie van die kliëntidentiteitinstelling nie.
Plaaslike ondersteuning vir 'n ECDSA-kliëntsertifikaat bewys nie dat elke poortsertifikaat, kurwe of bedienerverifikasiekonfigurasie sal saamwerk nie. Kontroleer die bediener se identiteit, sy ketting en sy IKE-verifikasiemetode as aparte insette, en toets met die profiel wat werklik ontplooi sal word.
As die poortsertifikaat die probleem is, verskyn die simptoom gewoonlik tydens eweknie-validasie eerder as by identiteitskeuse. Lees die mislukkingsfase voordat jy die kliënttipe verander, want 'n vertrouensfout en 'n kliëntsleutel-wanpassing deel nie 'n oplossing nie.
Die uitreiker se handtekening en sleutelooreenkomsgroep is nie die kliënttipe nie
X.509 hou die subjek se publieke sleutel en die uitreiker se handtekening in verskillende velde. Die subjek se publieke sleutelinligting beskryf die sleutel in die sertifikaat; die handtekeningalgoritme beskryf die CA se sleutel en ondertekeningsbewerking. Net die eerste pas by die sertifikaattipe-instelling.
Die IKE- en Child SA-voorstelle is 'n ander as. 'n ECDSA-sertifikaattipe is nie 'n ESP-enkripsiekeuse nie, en om die sleutelooreenkomsgroep te verander kies nie 'n sertifikaattipe nie. 'n Profiel kan geldige voorstelle en die verkeerde identiteitstipe hê, of die regte identiteitstipe en 'n voorstel wat die eweknie verwerp.
Hou die drie lyne apart in die veranderingsrekord: identiteitsertifikaat en -sleutel, poortvertrouensinsette, en voorstelalgoritmes. Om hulle in een "kripto-instellings"-nota te kombineer, maak die volgende fout onmoontlik om toe te skryf.
Verifieer die besluit met die velde wat jy opgestel het
Kontroleer die identiteit waarna die profiel werklik verwys, en bevestig dan dat die sertifikaat by daardie verwysing die verwagte publieke sleutel en 'n bruikbare privaatsleutel het. Die vertoonde tipe in die koppelvlak, die verwysde sertifikaat en die sleutel op die toestel moet ooreenstem.
Bevestig volgende die poortinsette: die verwagte bedienernaam, die vertrouensanker en die IKE-verifikasiemetode. Verbind laastens en lees waar die handdruk stop. 'n Fout voor identiteitsuitruiling wys weg van hierdie instelling; 'n fout by eweknie-validasie wys na die poortkant.
Teken die gekose tipe, die identiteitsverwysing en die poortsertifikaat se subjek in die ontplooiingsnotas aan. Die volgende profielopdatering kan enige van hulle verander, en drie benoemde waardes is vinniger om te vergelyk as 'n skermkiekie van 'n instellingspaneel.