Tystysgrif VPN wedi'i dirymu yn dal i gysylltu? Gwiriwch orfodi CRL

Fe wnaethoch ddirymu'r dystysgrif, cynhyrchu rhestr newydd, ac mae'r proffil hen yn dal i godi twnnel. Nid oes dim wedi torri yn y dirymiad ei hun: datganiad wedi'i lofnodi yw CRL nad yw rhif cyfresol yn ddilys mwyach, ac nid yw'n newid mynediad nes bod y gydran sy'n terfynu TLS yn ei lwytho, ar gyfer y rhoddwr cywir, cyn iddi wneud y penderfyniad derbyn. Dyna lle mae'r rhan fwyaf o'r achosion hyn, a dyna pam mae dirymiad a gwrthodiad yn ddau ffaith ar wahân.

Ewch drwy'r pum gwiriad isod yn eu trefn, a stopiwch yn y cyntaf nad yw'n dal, oherwydd mae pob gwiriad diweddarach yn rhagdybio bod y rhai cynharach yn wir.

Gwiriwch pa gydran sy'n gwneud y penderfyniad derbyn

Enwch y broses sy'n gwirio tystysgrif y cleient, oherwydd dim ond y broses honno all orfodi rhestr. Ar weinydd OpenVPN y daemon ei hun yw hi, wedi'i ffurfweddu gyda crl-verify. Ar ocserv y llinell crl yn ocserv.conf yw hi. Ar strongSwan y mewnbynnau yw'r CRLau a lwythwyd ynghyd â strictcrlpolicy. Gall dirprwy neu declyn sy'n terfynu TLS o flaen y VPN fod y gwiriedydd go iawn hefyd, ac os felly, ni fydd y daemon y tu ôl iddo byth yn gweld tystysgrif y cleient.

Mae WireGuard yn perthyn i gategori gwahanol. Nid oes ganddo dystysgrifau na rhestr ddirymu; derbynnir cymar drwy ei allwedd gyhoeddus yn y ffurfweddiad, felly mae terfynu mynediad yn golygu tynnu'r allwedd honno. Os ydych chi'n chwilio am CRL mewn gosodiad WireGuard yn unig, nid yw'r mecanwaith hwnnw yno.

Gwyliwch am y trap ar ochr y cleient hefyd. Mae cleient sy'n gwrthod cysylltu oherwydd nad yw'n hoffi tystysgrif y gweinydd yn gorfodi cadwyn y gweinydd, nid yn dirymu ei gymhwyster ei hun. Dim ond lle mae'r dystysgrif defnyddiwr honno'n cael ei gwirio y mae tystysgrif defnyddiwr yn cael ei dirymu, ac mae hynny bron bob amser ar ochr y gweinydd.

Gwiriwch pa roddwr y llofnodwyd y rhestr ar ei gyfer

Mae CRL yn gyfyngedig i un CA sy'n cyhoeddi. Gyda gwraidd a chanolradd, daw'r tystysgrifau dail o'r canolradd, felly'r rhestr sy'n bwysig yw CRL y canolradd; nid yw rhestr y gwraidd yn dweud dim am y dail hynny. Mae gwiriedydd sy'n pwyntio at y ffeil anghywir yn ei pharsio'n llawen, heb ddod o hyd i unrhyw gofnod cyfatebol, ac yn derbyn popeth.

Cadarnhewch y paru cyn cyffwrdd â'r daemon. Rhaid i roddwr y dystysgrif gyfateb i subject y rhestr:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Pan fydd y ddau yn dod o'r un CA, y rhif cyfresol a argraffwyd ar gyfer y dystysgrif yw'r gwerth y mae'n rhaid iddo ymddangos ar y rhestr. Os ydynt yn anghytuno, rydych chi'n dal y CRL anghywir neu'r gopi anghywir ohono.

Mae dilysrwydd yn perthyn i'r un gwiriad. Mae nextUpdate yn y gorffennol yn gwneud y rhestr yn hen, a bydd gwiriedydd sy'n methu ar gau yn gwrthod pob cleient yna yn hytrach na dim ond yr un a ddirymwyd.

Gwiriwch fod y rhif cyfresol yn y gopi a lwythodd y daemon

Mae dirymu yn ysgrifennu cofnod ym mhronfa ddata'r CA, ac mae ailddychmygu yn ysgrifennu ffeil newydd. Nid yw'r naill weithred na'r llall yn cyrraedd daemon sy'n rhedeg a lwythodd yr hen gopi ar amser cychwyn. Dympwch y rhestr a chwiliwch am y rhif cyfresol:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Gwiriwch wedyn sut mae eich gweithrediad yn codi'r ffeil. Mae OpenVPN yn darllen llwybr a roddwyd i crl-verify unwaith ar amser cychwyn, felly mae angen ailgychwyn neu signal ailgychwyn ar restr newydd; mae'r un opsiwn a gyfeiriwyd at ffolder yn cael ei ailddarllen ar gyfer pob cysylltiad, a dyna pam mae modd ffolder yn bodoli. Rhaid i strongSwan ail-lwytho ei gymwysterau, er enghraifft gyda swanctl --load-creds. Mae'r ffeil ar y disg yn gywir a bod y gwiriedydd yn ei defnyddio yn ddau ffaith wahanol.

Gwiriwch y polisi ar gyfer rhestr ar goll neu wedi dod i ben

Dyma'r penderfyniad nad yw llawer o osodiadau byth yn ei wneud yn benodol, ac mae'n penderfynu a yw dirymiad yn eich amddiffyn neu'n cloi pawb allan. Mae fail-closed yn golygu nad oes unrhyw wybodaeth ddirymu ddefnyddiadwy yn arwain at wrthodiad; mae fail-open yn golygu bod y gwiriedydd yn parhau hebddo. Mae strongSwan yn datgelu'r dewis fel strictcrlpolicy. Mae OpenVPN gyda crl-verify yn gwrthod cychwyn ar ffeil na all ei darllen na'i pharsio, ac mae rhestr sydd wedi dod i ben yn ymddangos fel gwall gwirio TLS am CRL sydd wedi dod i ben yn hytrach nag fel derbyniad tawel.

Pa bynnag gyfeiriad a ddewiswch, mae'r awtomeiddio yn cyfrif mwy na'r dewis: mae tasg sy'n ailddychmygu'r CRL cyn nextUpdate, a rhybudd pan fydd y gopi a osodwyd yn heneiddio, yn cadw'r naill bolisi a'r llall rhag dod yn ddigwyddiad. Mae gwirio ar-lein gyda OCSP yn symud y newydd-deb i ymatebydd, ond mae'r un rheol yn dal, oherwydd nid yw gwiriedydd nad yw wedi'i ffurfweddu i wirio'r ateb yn newid dim.

Gwiriwch y sesiwn fyw, yna copïau'r allwedd

Mae dirymiad yn cael ei werthuso yn ystod gwirio'r dystysgrif, sy'n digwydd ar adeg cysylltu ac ar adeg ailnegodi. Mae sesiwn sefydledig yn parhau nes iddi ailnegodi, a diofyn OpenVPN yw unwaith yr awr gyda reneg-sec 3600. Os oes rhaid i'r person fod oddi ar y rhwydwaith nawr, terfynwch y sesiwn yn ogystal â chyhoeddi'r rhestr, ac yna cadarnhau bod yr ailgysylltu yn cael ei wrthod.

Gwahanwch y cymhwyster oddi wrth ei gopïau. Nid yw dileu proffil ar un gliniadur yn atal copi arall o'r un allwedd breifat rhag dilysu; dirymiad sy'n gwneud pob copi yn ddiwerth, a dim ond pan fydd y gwiriadau cynharach yn dal. Rhowch dystysgrif ei hun i ddyfais gyfnewid fel y gellir dirymu'r naill heb gyffwrdd â'r llall.

Cyn i chi alw hynny'n barod: mae'r gydran wirio wedi'i nodi, mae rhoddwr y rhestr yn cyfateb i roddwr y dail, mae'r rhif cyfresol a ddirymwyd yn y gopi a lwythodd y daemon mewn gwirionedd, mae'r polisi ar gyfer rhestrau ar goll neu wedi dod i ben yn fwriadol ac o dan fonitro, ac mae'r sesiwn weithredol wedi'i therfynu yn hytrach na'i disgwyl. Mae'r fformatau y tu ôl i'r cyfan wedi'u nodi yn RFC 5280.