Tri malsamaj demandoj estas respondataj de tri malsamaj partoj de OpenVPN-profilo, kaj ilia kunfandado estas kiel homoj finas malŝaltante kontrolon, kiu funkciis. Ĉu la atestilo de la kontraŭulo estas subskribita de la aŭtoritato, kiun mi fidas? Ĉu tiu atestilo deklaras la TLS-servilan rolon? Ĉu ĝi estas la preciza servilo, kiun mi celis atingi? remote-cert-tls server respondas nur la mezan demandon, kaj ĝi faras tion legante etendaĵojn ene de la atestilo.

Tri kontroloj facile kunfandeblaj en via kapo

La fida kerno loĝas en la direktivo ca. La rolkontrolo apartenas al remote-cert-tls. La identeckontrolo apartenas al verify-x509-name, kiam profilo uzas ĝin, aŭ al iu ajn nomkontrolo, kiun la deplojo aldonas.

Ili kovras malsamajn paneojn:

QuestionDirectiveFailure it catches
Who signed this?caCertificate from an unrelated authority
Is this a server?remote-cert-tlsClient certificate presented by a peer
Is this my server?verify-x509-nameAnother valid server from the same CA

Profilo povas havi ĉiujn tri kaj tamen esti malforta, se la CA estas tro vaste dividata, kio estas demando de ŝlosiladministrado, ne de direktivo.

Kion la rolkontrolo legas

La direktivo estas makroo. Ĝi etendiĝas al postulo pri ŝlosiluzado kaj postulo pri plilongigita ŝlosiluzado nomanta la rolon de TLS-ret-servilo, do la atestilo de la kontraŭulo devas reale deklari tiun celon. Atestilo eldonita por klienta aŭtentikigo ne kontentigas ĝin, eĉ kiam la sama aŭtoritato subskribis ambaŭ.

Tio gravas, ĉar dividita CA estas kutima en malgrandaj deplojoj. Unu aŭtoritato subskribas ĉiun klienton kaj la servilon, kaj sen rolkontrolo iu ajn el tiuj atestiloj povus plenumi la servilan flankon de la manpremo. La kontrolo ne faras tiun scenaron neebla, sed ĝi forigas ĝian trivialan version.

La direktivo estas malsimetria laŭdezajne: klientoj portas remote-cert-tls server, kaj serviloj portas remote-cert-tls client. Interŝanĝu ilin kaj ĉiu konekto paneas kun rola eraro, kiu aspektas kiel difektita atestilo.

Pli malnovaj profiloj foje uzas ns-cert-type por la sama celo. Nunaj manlibraj paĝoj traktas tiun opcion kiel anstataŭigita, do profilo, kiu ankoraŭ dependas de ĝi, indas migradon anstataŭ sencimigadon.

Kial malŝalti ĝin sentiĝas kiel ripari

Kiam la rolkontrolo paneas, la konekto haltas kun kontroleraro kaj la evidenta movo estas forigi la linion. La konekto tiam leviĝas, kio sentiĝas kiel progreso kaj estas fakte la paneomaniero, kiun la direktivo ekzistas por malhelpi. Vi nun akceptas kontraŭulon, kies atestilo neniam estis intencita por tiu rolo.

Anstataŭe legu la eraron. Ĝi nomas la kontrolon, kiu paneis, kaj la atestilo aliflanke povas esti esplorata por vidi, kiujn etendaĵojn ĝi vere portas. Du minutoj da legado decidas, ĉu la kulpo estas eldono aŭ agordo. Divenado kostas posttagmezon kaj kutime finiĝas per malfortigita profilo. Renovigita servila atestilo, kiu perdis sian plilongigitan ŝlosiluzadon, estas reala kulpo en la renovigo, ne kialo malstreĉi la klienton.

La nomkontrolo estas aparta direktivo

Kontentigi la rolkontrolon diras, ke la kontraŭulo estas iu servilo subskribita de via aŭtoritato. Ĝi diras nenion pri tio, kiun, kio gravas, kiam la sama CA eldonas atestilojn por pluraj enirejoj kaj unu el ili estas kompromitita aŭ reuzata.

verify-x509-name komparas la subjekton de la atestilo kun valoro, kiun vi agordas, kun kongruaj reĝimoj por preciza subjekto, prefikso aŭ unu kampo. Uzu la kampon, kiu reale identigas la enirejon, kaj atendu ĝisdatigi ĝin intence, kiam la nomo ŝanĝiĝas.

Neniu el la du direktivoj anstataŭas bonan ŝlosilmanipuladon. Se la klienta ŝlosildosiero estas kopiata ĉirkaŭe kun la profilo, la identeco de la kontraŭulo estas nur tiom forta kiom la distribulisto.

Esploru la atestilon antaŭ ol redakti la profilon

Legu la atestilon de la kontraŭulo kaj la klientan protokolon, en tiu ordo. La atestilo diras al vi, kiujn rolojn ĝi deklaras; la protokolo diras al vi, kiu kontrolo malakceptis ĝin.

Ĉi tiuj komandoj presas la uzadajn etendaĵojn kaj la kontrolajn liniojn de detala konekto:

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

Se la etendaĵoj montras la servilan rolon kaj la protokolo ankoraŭ raportas rolan paneon, la profilo verŝajne montras al la malĝusta atestildosiero anstataŭ al malbona atestilo. Se la etendaĵoj montras nur klientan aŭtentikigon, ĉesu rigardi la klienton kaj ripari la eldonon. Ĉiukaze restarigu la kontrolon antaŭ ol nomi la konekton sana, ĉar sukcesa manpremo post forigo de kontrolado pruvas malpli ol la eraro, kiun ĝi anstataŭigis.

Rilataj artikoloj