remote-cert-tls server: wat dit in 'n OpenVPN-profiel kontroleer

Drie verskillende vrae word deur drie verskillende dele van 'n OpenVPN-profiel beantwoord, en om hulle te vermeng is hoe mense uiteindelik 'n kontrole afskakel wat gewerk het. Is die eweknie-sertifikaat deur die owerheid wat ek vertrou, onderteken? Verklaar daardie sertifikaat die TLS-bedienerrol? Is dit die spesifieke bediener wat ek wou bereik? remote-cert-tls server beantwoord net die middelste een, en dit doen so deur uitbreidings binne die sertifikaat te lees.

Drie kontroles wat maklik in jou kop vermeng word

Die vertrouensanker woon in die ca-opdrag. Die rolkontrole hoort by remote-cert-tls. Die identiteitskontrole hoort by verify-x509-name, wanneer 'n profiel dit gebruik, of by watter naamkontrole ook al die ontplooiing byvoeg.

Hulle dek verskillende foute:

'n Profiel kan al drie hê en steeds swak wees as die CA te wyd gedeel word, wat 'n sleutelbestuursvraag is eerder as 'n opdragvraag.

Wat die rolkontrole lees

Die opdrag is 'n makro. Dit brei uit na 'n sleutelgebruik-vereiste en 'n uitgebreide-sleutelgebruik-vereiste wat die TLS-webbedienerrol noem, so die eweknie-sertifikaat moet daardie doel werklik verklaar. 'n Sertifikaat wat vir kliëntverifikasie uitgereik is, voldoen nie daaraan nie, selfs wanneer dieselfde owerheid albei onderteken het.

Dit maak saak omdat 'n gedeelde CA algemeen in klein ontplooiings is. Een owerheid onderteken elke kliënt en die bediener, en sonder 'n rolkontrole kan enige van daardie sertifikate die bedienerkant van die handdruk voltooi. Die kontrole maak daardie scenario nie onmoontlik nie, maar dit verwyder die triviale weergawe daarvan.

Die opdrag is ontwerp asimmetries: kliënte dra remote-cert-tls server, en bedieners dra remote-cert-tls client. Ruil hulle om en elke verbinding misluk met 'n rolfout wat soos 'n gebreekte sertifikaat lyk.

Ouer profiele gebruik soms ns-cert-type vir dieselfde doel. Huidige handleidingsbladsye beskou daardie opsie as vervang, so 'n profiel wat nog daarop staatmaak, is werd om te migreer eerder as om te ontfout.

Waarom dit afskakel soos 'n oplossing voel

Wanneer die rolkontrole misluk, stop die verbinding met 'n verifikasiemelding en die ooglopende skuif is om die reël te skrap. Die verbinding kom dan op, wat soos vooruitgang voel en eintlik die foutmodus is wat die opdrag bestaan om te voorkom. Jy aanvaar nou 'n eweknie wie se sertifikaat nooit vir daardie rol bedoel was nie.

Lees eerder die fout. Dit noem die kontrole wat misluk het, en die sertifikaat aan die ander kant kan ondersoek word om te sien watter uitbreidings dit werklik dra. Twee minute se lees beslis of die fout uitreiking of konfigurasie is. Om te raai kos 'n middag en eindig gewoonlik met 'n verswakte profiel. 'n Hernieude bediener-sertifikaat wat sy uitgebreide sleutelgebruik verloor het, is 'n werklike fout in die hernuwing, nie 'n rede om die kliënt te verslap nie.

Die naamkontrole is 'n aparte opdrag

Om die rolkontrole te bevredig sê die eweknie is een of ander bediener wat deur jou owerheid onderteken is. Dit sê niks oor watter een nie, wat saak maak wanneer dieselfde CA sertifikate vir verskeie gateways uitreik en een van hulle gekompromitteer of hergebruik is.

verify-x509-name vergelyk die sertifikaatonderwerp met 'n waarde wat jy opstel, met passingsmodusse vir 'n presiese onderwerp, 'n voorvoegsel of 'n enkele veld. Gebruik die veld wat die gateway werklik identifiseer, en verwag om dit doelbewus op te dateer wanneer die naam verander.

Nie een van die opdragte vervang goeie sleutelhantering nie. As die kliëntsleutellêer saam met die profiel rondgekopieer word, is die eweknie-identiteit net so sterk soos die verspreidingslys.

Ondersoek die sertifikaat voordat jy die profiel wysig

Lees die eweknie-sertifikaat en die kliëntlog, in daardie volgorde. Die sertifikaat vertel watter rolle dit verklaar; die log vertel watter kontrole dit verwerp het.

Hierdie opdragte druk die gebruiksuitbreidings en die verifikasielyne van 'n breedvoerige verbinding:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

As die uitbreidings die bedienerrol wys en die log steeds 'n rolfout rapporteer, wys die profiel waarskynlik na die verkeerde sertifikaatlêer eerder as na 'n slegte sertifikaat. As die uitbreidings net kliëntverifikasie wys, stop om na die kliënt te kyk en herstel die uitreiking. Herstel in elk geval die kontrole voordat jy die verbinding gesond noem, want 'n suksesvolle handdruk nadat verifikasie verwyder is, bewys minder as die fout wat dit vervang het.