OpenVPN username-as-common-name: waarom jou CN-kontrole leeg is
’n client-connect-skrip wat common_name met username vergelyk, kan ’n naam met homself vergelyk. Bind die sertifikaat aan die rekening voordat die vervanging plaasvind.
Jy voeg ’n client-connect-skrip by wat enige verbinding verwerp waar common_name van username verskil, en dit lyk soos ’n binding tussen ’n sertifikaat en ’n rekening. Op ’n bediener waar username-as-common-name loop, het daardie vergelyking reeds sy betekenis verloor teen die tyd dat die skrip uitvoer. Beide waardes is dieselfde string, so die toets slaag vir ’n sertifikaat wat heeltemal aan iemand anders uitgereik is.
Die kontrole is nie verkeerd omdat die skrip sleg geskryf is nie. Dit is verkeerd omdat die waarde wat dit lees vroeër in dieselfde verbinding vervang is.
Wat die vergelyking blyk te bewys
Sertifikaat-verifikasie en wagwoord-verifikasie is aparte bewyse, en ’n bediener kan albei eis sonder om te eis dat hulle aan dieselfde persoon behoort. Die gaping is werklik: ’n geldige toestelsertifikaat plus enige geldige rekening is ’n ander bewering as daardie toestelsertifikaat plus een genoemde rekening. ’n skrip wat common_name met username vergelyk, lees soos die ontbrekende skakel tussen die twee. Dit sou wees, as common_name nog beteken het wat die sertifikaat gesê het.
Of dit doen, hang van een bedieneropsie af, en daardie opsie word gewoonlik om ’n onverwante rede aangeskakel, soos om per-gebruiker-konfigurasielêers makliker te benoem.
Wat username-as-common-name aan die naam doen
Met username-as-common-name geaktiveer, vervang OpenVPN die geverifieerde gebruikersnaam vir die sertifikaat se algemene naam sodra die gebruikersnaam en wagwoord geverifieer is. Die verifikasie-haak wat tydens daardie kontrole loop, ontvang steeds die sertifikaat se algemene naam, want die vervanging het nog nie plaasgevind nie. Alles daarna, client-connect ingesluit, sien die gebruikersnaam. So die latere callback ontvang een identiteit twee keer en kan dit nie met die sertifikaat wat aangebied is, vergelyk nie.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Volg een voorbeeldige verbinding: ’n sertifikaat uitgereik vir bob-device, ’n suksesvolle gidsaanmelding as alice, en die opsie geaktiveer. Die verifikasiefase kan steeds twee verskillende stringe sien. Die verbindingsfase sien alice en alice.
Daardie voorbeeld wys waarom die vergelyking leeg is. Dit wys nie dat die verbinding andersins aanvaar sou word nie, want sertifikaatvalidering en wagwoordverifikasie loop steeds op hul eie.
Plaas die binding waar albei identiteite nog bestaan
Die reël moet afgedwing word in ’n fase wat die sertifikaatidentiteit en die rekening op dieselfde tyd sien, wat in die praktyk die gebruikersnaam-en-wagwoord-verifikasiehaak of ’n inprop wat daar gelaai word, beteken. ’n Ondersteunde inprop wat reeds wagwoordverifikasie doen, is gewoonlik die regte plek om ’n paringsreël by te voeg, want om dit met ’n naamvergelyking te vervang, sou die wagwoordkontrole heeltemal laat val.
Bepaal die kartering voordat jy kode skryf, want gelykheid is selde die werklike beleid. ’n Sertifikaat identifiseer dikwels ’n toestel terwyl die aanmelding ’n persoon identifiseer, en een toestel kan wettiglik verskeie mense dien. Stoor die verhouding in ’n vorm wie se uitreiking jy beheer, en besluit wat gebeur by hernoeming, by heruitreiking en by domeingekwalifiseerde name. Om ’n domeinvoorvoegsel klein te maak of te stroop sonder om die gids te verstaan, kan twee rekeninge saamsmelt wat bedoel was om apart te bly.
Onthou dat die opsie ook verander watter per-kliënt-konfigurasie geld, want client-config-dir word deur die algemene naam gesleutel.
Toets die paring met twee geldige geloofsbriewe
Begin met die paar wat jou beleid toelaat en bevestig dat dit verbind. Bied dan dieselfde geldige sertifikaat met ’n ander maar andersins geldige rekening aan: daardie poging moet misluk, en dit moet misluk weens die paringsreël, nie weens ’n verkeerd getikte wagwoord nie. ’n Verkeerde wagwoord bewys die wagwoordkontrole werk en sê niks oor die sertifikaat-tot-rekening-reël nie.
Kontroleer ook die ontbrekende-sertifikaat- en ongeldige-sertifikaat-roetes, en bevestig watter identiteit die bediener vir per-kliënt-instellings gebruik. As die enigste manier om die vergelyking te laat werk is om username-as-common-name te deaktiveer, bereken eers die prys van daardie verandering, want dit skuif elke kliënt se konfigurasie-opsoek terug na die sertifikaatnaam.