In korrekt VPN-wachtwurd ferfangt gjin ûntbrekkend sertifikaat

De oanmeldgegevens binne goed, it profyl wurdt skjin ymportearre, en de ferbining mislearret noch hieltyd foardat de ferifikaasje foltôge is. Op Windows kin it berjocht flater 798 wêze, oer in sertifikaat dat net fûn wurde koe foar de EAP-metoade. Op OpenVPN lit it kliïntloch in TLS-hânskwiving sjen dy't de server nea befrediget. Beide beskriuwe itselde ûntbrekkende objekt: in kliïntsertifikaat dat de kliïnt presintearje moatten hie.

In wachtwurd bewiist kennis fan in geheim; in sertifikaat bewiist besit fan in kaai, en it ien ferfangt it oar net.

It wachtwurd wie nea it probleem

Flater 798 is in mislearre sertifikaatopsyk. De kliïnt waard frege om in sertifikaat dat by de konfigurearre ferifikaasjemetoade past, trochsocht syn argyf en fûn neat brûkbers. Dat kin betsjutte dat it sertifikaat ûntbrekt, oanwêzich is sûnder syn priveekaai, ferrûn is, of bewarre is wêr't de opsyk net by komt. It wachtwurd nochris besykje kin gjin fan dy betingsten feroarje, dêrom komt de flater werom sels mei kloppe oanmeldgegevens.

Lês it berjocht foardat jo derop reagearje. In ôfwizing fan oanmeldgegevens, in mislearre sertifikaatopsyk en in mislearre TLS-hânskwiving binne trije ferskillende befiningen, en mar ien dêrfan hat mei it wachtwurd te krijen.

Wat it kliïntargyf befetsje moat

Twa objekten binne belutsen. It kliïntsertifikaat moat ynstallearre wêze foar de brûker dy't de VPN-kliïnt draait, mei syn priveekaai, en de útjaanende woartel moat fertroud wêze. In .cer-bestân befettet allinnich it iepenbiere sertifikaat, dus it kin op himsels neat ferifiearje. Yn 'e Windows-sertifikaatbehearder heart de kliïntidentiteit yn it persoanlike argyf fan 'e hjoeddeiske brûker, en de woartel yn it argyf fan fertroude woartels.

It ynstallearjen fan 'e identiteit yn it masjine-argyf, of allinnich yn it woartelargyf, foldocht net oan in opsyk dy't op it persoanlike argyf fan 'e brûker rjochte is. Kontrolearje it argyf, de priveekaai-flagge en de jildichheidsdatums tagelyk, en start de kliïnt dan opnij sadat er it argyf wer lêst.

Twa produkten, deselde ûntbrekkende oanmeldgegevens

OpenVPN-servers easkje standert in kliïntsertifikaat. It tafoegjen fan auth-user-pass oan in kliïnt stjoert in brûkersnamme en wachtwurd, en de TLS-hânskwiving freget noch altyd in sertifikaat, dus in wachtwurd allinnich kin de ferbining ûnder verify-client-cert require net foltôgje. De server kin ynsteld wurde om neat te easkjen, wat it wachtwurd de iennichste kliïntoanmeldgegevens makket en in echte ferswakking is. In shell-skript efter auth-user-pass-verify kin oanmeldgegevens falidearje, en it easket dat skriptútfiering ynskeakele is, wat it in riskantere ûntwerp makket as in goed ferifikaasje-backend.

In profyl dat allinnich op in wachtwurd fertrout, hinget ek ôf fan tawiisde opsjes, dy't op har beurt ôfhingje fan it ynskeakeljen fan it lûkmechanisme.

Reparearje in ûntbrekkend sertifikaat net troch kontrôles út te skeakeljen

De ferlieding is om ferifikaasje te fersoepeljen sadat it berjocht ferdwynt. Dat hellet de kontrôle fuort dy't syn wurk die en lit in ferbining efter dy't net mear bewiist wat er beweart. As de gateway koartlyn syn woartel feroare hat, download dan it kliïntpakket opnij ynstee fan it profyl te bewurkjen, want it âlde pakket kin noch de foarige woartel befetsje. As de sertifikaatferifikaasje-opsje yn 'e profylbewurker ûntbrekt, lit de ynstallearre Windows-ferzje dy metoade miskien net sjen; fernij it systeem ynstee fan XML mei de hân te bewurkjen.

Skriuw op hokker argyf it sertifikaat befette, hokker brûker de kliïnt draaide en of de priveekaai oanwêzich wie. Dy trije ferklearje hast elk gefal fan dizze mislearring.

It wachtwurd wie goed. De oanmeldgegevens dy't de metoade eins nedich hie, wiene earne oars.