Jo VPN-klient seit dat it sertifikaat net ferifiearre wurde koe, en de dialooch stopet dêr. It bestân is der, de tsjinner is oan, en itselde profyl wurke ferline moanne op in oare laptop. Under dy warskôging fan ien rigel liet de klient it sertifikaat fan ’e pear troch fjouwer poarten rinne: in sertifikaatautoriteit dy’t jo konfigurearre hawwe, boarcht foar it ûndertekeningspaad, dat paad berikt de autoriteit, de pearnamme is dy’t jo fregen, en it sertifikaat is no foar dit doel brûkber. Fyn de poarte dy’t ticht gie en de reparaasje is meastentiids ien bestân; slaan dy stap oer en jo ympotearje de hiele middei bondels op ’e nij.

Lês de dialooch foar’t jo it profyl bewurkje

Sertifikaatflaters wurde troch de bibleteek derûnder formulearre, net troch it VPN-produkt dat jo ynstallearre hawwe, dat de krekte tekenrige is jo earste bewiis. «Kin gjin sertifikaat fan lokale útjouwer krije» wiist op it paad of op it fertrouwensanker. «Sertifikaat is ferrûn of noch net jildich» wiist op tiid. «Net-stipe sertifikaatdoel» wiist op útwreide kaaiberik. In nammeôfwiking fertelt jo hokker namme it woe. Gjin fan ’e fjouwer wurdt reparearre troch de klient op ’e nij te ynstallearjen.

Ferheegje de logging foar’t jo wat feroarje. OpenVPN meldt de ferifikaasjeflater om ’e hânskodding hinne as jo it mei --verb 4 útfiere, en strongSwan skriuwt syn identiteits- en kettingbesluten nei it charon-log. Befêstigje dan hokker sertifikaat jo ûndersykje, want minsken testen geregeld it bestân op skiif wylst it profyl in âldere kopy ynbânet. As it profyl PEM-blokken ynbânet, is it ynbâne sertifikaat dat test wurde.

In sertifikaatautoriteit ûndertekenet identiteiten, gjin tastimmingen

De autoriteit hâldt in namme en in ûndertekeningskaai. Se jout sertifikaten út dy’t in iepenbiere kaai oan dy namme bine neffens har eigen belied, mei in jildichheidsfinster en gebrûksbeheiningen deroan. Jo klient hat allinnich it sertifikaat fan ’e autoriteit nedich om de útjouwer te erkennen; hy hat nea de ûndertekeningskaai nedich, en it stjoeren fan dy kaai nei kliïnten soe har de mooglikheid jaan om elke identiteit te meitsjen dy’t de útrôl fertrout.

Fertrouwen yn in autoriteit makket elk sertifikaat dat se ûndertekene hat in kandidaat, net de goede pear. In webserver-sertifikaat fan deselde ynterne CA is ek in kandidaat. Dêrom besteane de namme- en doelpoarten, en dêrom is in kompromittearre CA-kaai wichtiger as hokker inkelse tsjinner dan ek: hy berikt elke identiteit dy’t de autoriteit ea útjûn hat. Jou klintsertifikaten per apparaat út, sadat in ferlern laptop ien yntrekking is ynstee fan in kaaifernijing foar de hiele útrôl.

Bou it paad op ’e nij dat de klient besiket te bouwen

It paad rint fan it sertifikaat fan ’e pear, troch nul of mear tuskenlizzende sertifikaten, nei in woartel yn jo fertrouwensopslach. In ûntbrekkend tuskenlizzend sertifikaat is de meast foarkommende kettingflater, en fan ’e klintkant liket it krekt as in net-fertroude woartel. Lês earst it bled, en lit OpenSSL dan it paad bouwe út it materiaal dat jo fan plan binne te stjoeren.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Utgongstatus nul betsjut dat it paad út dy bestannen boud is; in flater neamt it sertifikaat dat it net berikke koe. As openssl verify slagget wylst de klient noch wegert, leit it ferskil yn wat de tsjinner echt stjoert of yn hokker fertrouwensbestân it profyl laadt. Yn OpenVPN kinne tuskenlizzende sertifikaten mei it tsjinnersertifikaatbestân meiride of apart levere wurde mei --extra-certs, en in bondel mei twa woartels ûnder deselde subjektnamme sil ien fan jo kliïnten it ferkearde twiich yn stjoere.

Namme en doel binne aparte poarten

Kettingbou freget nea oft de namme fan jo is. OpenVPN kontrolearret it allinnich as it profyl --verify-x509-name set, en de âldere gewoante om allinnich de gewoane namme te passen brekt op sertifikaten waans identiteiten yn subjectAltName libje. IKEv2-útrôlen passe de konfigurearre identiteit op SAN-ynfieringen of op de ûnderskiedende namme, ôfhinklik fan ’e klient, en in wildcard- of %any-wearde skeakelet stil de fergeliking út dy’t jo tochten te hawwen.

Dêrnei komme tiid en doel. In laptop waans klok in pear oeren foar rint, wiist in sertifikaat ôf dat noch net jildich is, en in ferrûn tuskenlizzend sertifikaat lit it paad mislearje wylst it bled jildich is. Doelflaters komme fan in sertifikaat sûnder serverAuth yn útwreide kaaiberik, of mei in keyUsage dy’t de hânskoddingsûndertekening net tastiet, wat OpenSSL as in net-stipe sertifikaatdoel meldt. Jou op ’e nij út fan it goede sjabloan; neat yn dy melding is in reden om ferifikaasje út te skeakeljen.

Yntrekking rint allinnich as immen it konfigurearre hat

In CRL of in OCSP-antwurd wurdt net automatysk rieplachte. Op in OpenVPN-tsjinner wurde klintsertifikaten allinnich tsjin in list kontrolearre as --crl-verify nei ien wiist. Kliïntsydige kontrôle fan it tsjinnersertifikaat hinget fan ’e ymplemintaasje ôf en ûntbrekt faak. strongSwan hat syn yntrekkingsplugin en in belied nedich foar’t it foar in pear nei in CRL sjocht.

Dat ferklearret it ticket dat jo úteinlik krije: in yntrokken klintsertifikaat ferbynt noch, en elkenien konkludearret dat yntrekking stikken is. Neat kontrolearre. Publisearje en ferfarskje de CRL, of hâld klintsertifikaten koart genôch libben dat in ferâldere yntrekking mar even ta saak docht, en oefenje it yntrekkingspaad op in laboratoariumsertifikaat foar’t jo it by in ynsidint nedich hawwe.

In reparaasjeoarder dy’t ferifikaasje oan hâldt

Sortearje op symptoom foar’t jo bestannen oanreitsje, want elke rigel fan ’e tabel stjoert jo nei in oar objekt.

Client saysMost likely gateFirst check
unable to get local issuer certificatetrust anchor or missing intermediateyour own openssl verify against the files the profile loads
expired or not yet validvalidity windowleaf and intermediate dates against the device clock
unsupported certificate purposeextended key usageserverAuth present, keyUsage allows the handshake
name mismatchpeer identitysubjectAltName entries versus the profile name

Wurket de list yn ien pass troch: befêstigje it bestân dat it profyl laadt, bou it paad sels, kontrolearje dat de tsjinner it tuskenlizzende sertifikaat stjoert, fergelykje de klok, lês de SAN, lês de EKU, ferbynje dan op ’e nij en sjoch hoe’t deselde logrigel ferdwynt. As in apparaat hielendal gjin CA krije kin, is pinning it earlike alternatyf, want OpenVPN 2.6 akseptearret --peer-fingerprint en ferneaut fertrouwen ta ien kaai ynstee fan ’e kontrôle fuort te heljen. RFC 5280 is de referinsje foar wat elk fan dy fjilden betsjut.

Relatearre artikelen