Sertifikaat fan it blêd jildich, keatling ferrûn: lês de djipte

Jo kontrolearje it server-sertifikaat, sjogge noch moannen op 'e klok, en de klant wegert de ferbining dochs mei in ferrinberjocht. De datum dy't jo lêze heart by it blêd, en de klacht kin oer eat djipper yn it paad gean. Ferifikaasje rint in keatling lâns, en elk sertifikaat dat dizze rin kiest kin yn syn eigen jildichheidsfinster mislearje. Lês hokker mislearre ear't jo eat fernije.

De djipte neamt it sertifikaat dat mislearre

Yn OpenSSL-diagnostyk is djipte 0 it doelsertifikaat en djipte 1 de útjouwer dy't it ûndertekene hat, mei hegere nûmers dy't trochgeane nei it fertrouwensanker. In ferrin dat op djipte 1 rapportearre wurdt, wurdt net tsjinspreut troch in aktueel notAfter op it blêd, dus it sichtbere sertifikaat nochris kontrolearje sil de flater nea ferklearje.

Skriuw de fingerôfdruk fan it mislearre sertifikaat op tegearre mei syn subject, want ferskillende sertifikaten kinne deselde CA-namme drage. Krúsûndertekening makket krekt dy situaasje: deselde autoriteit ferskynt faker as ien kear, mei ferskillende jildichheidsdatums, en de ferifikaasjer helle dy iene dy't jo net ferwachte. In fertroud label is gjin identifikaasje, en in fingerôfdruk is wat twa objekten mei deselde namme ûnderskiedt.

Let ek op produkten mei mear as ien sertifikaatrol. Op OpenVPN Access Server binne de sertifikaten dy't de webynterfaces beskermje apart fan dy foar VPN-ferbiningen, dus in browser dy't de admin-side iepenet bewiist neat oer it paad fan 'e tunnel.

Fertrouwensynputten binne net itselde as keatlingkandidaten

Jou de ferifikaasjer de twa ynputten apart en eksplisyt. It fertrouwensbestân hâldt de ankers dy't jo akseptearje; de net-fertroude bondel hâldt tuskenlizzende sertifikaten dy't oanbean wurde foar it bouwen fan it paad. Se ferminge is hoe't minsken by fersin in tuskenlizzend sertifikaat ta woartel ferheegje en har dan ôffreegje wêrom't deselde flater har tusken masines folget.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

It standertpaad en -opslach útskeakelje mei -no-CApath -no-CAstore hâldt de test earlik: it resultaat hinget dan ôf fan 'e bestannen dy't jo neamd hawwe, net fan wat it wurkstasjon tafallich fertrout. De OpenSSL-ferifikaasjereferinsje dokumentearret dizze opsjes en de diagnostyk dy't se produsearje.

-show_chain prints de boude keatling as ferifikaasje slagget, wat brûkber is om te befêstigjen dat it paad dat is dat jo bedoelden. As it mislearret, hâld de rapportearre djipte en subject; dy twa fjilden fertelle de folgjende lêzer hokker sertifikaat te ynspektearjen.

Wat dit net docht, is it belied fan elke klant reprodusearje. In pin, in doelbeheining of in kliïntspesifike identiteitskontrôle wennet yn 'e klant, net yn dit kommando. Dat binne de ynstellingen om te ynspektearjen as ferifikaasje op 'e server slagget en de ferbining dochs mislearret. Hâld de twa diagnoazes apart, oars fernije jo in sûn sertifikaat wylst jo in pinning-flater efterfolgje.

Wat de kontrôle bewissiget en wat it weilitten lit

Dit is in paad-en-doel-kontrôle tsjin in fertrouwensbestân dat jo levere hawwe. Foar in HTTPS-nammekontrôle foegje jo de ferwachte hostnamme ta fia de passende opsje; foar in VPN-ferbining hâld de konfigurearre identiteitskontrôles fan 'e klant en brûk it fertrouwensmateriaal dat dy klant wurklik lêst.

Wat in server stjoert is in set kandidaten, net it paad dat jo klant úteinlik bouwe sil. Lokale fertrouwen en de boupregels fan 'e bibleteek foarmje beide it resultaat, dêrom kin itselde antwurd op ien masine ferifisearje en op in oare mislearje. Fergelykje de ûnderhâlden fertrouwensopslach en TLS-ymplemintaasje fan 'e mislearjende klant mei dy fan in wurkjende klant foardat jo identike evaluaasje oannimme. In ferskil dêr ferklearret in protte rapporten „allinnich dizze laptop mislearret“.

Om it finster fan elk sertifikaat te sjen ynstee fan ien foar ien, prints se as in set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Dat twadde kommando listet subjects en útjouwers sûnder elk bestân mei de hân te dekodearjen, sa merke jo in tuskenlizzend sertifikaat op wêrfan de datum foarby is wylst it blêd noch goed liket.

Reparearje it paad sûnder ferifikaasje te ferswakjen

As in ferrûn tuskenlizzend of in ferâldere krúsûndertekene sertifikaat levere wurdt, helje de op dit stuit stipe keatling fan 'e útjouwer en set dy út fia de dokumintearre sertifikaatwurkstream fan 'e tsjinst. As de klant it bedoelde ûnderhâlden anker mist, fernij dan syn behearde fertrouwenskonfiguraasje of de kliïntsoftware. Wjerstean de koartwei om elk sertifikaat yn 'e bondel as woartel te markearjen om it berjocht stil te meitsjen.

De omgong mei de woartel fertsjinnet in notysje, want gearfettingen oerdriuwe it faak. RFC 5280 behannelet it anker as in ynput bûten it foarnommen paad, wylst OpenSSL jildichheidskontrôles dokumintearret dy't syn woartel-CA-sertifikaat omfetsje. Beide bewearings binne wier foar har eigen systemen; it generalisearjen fan it woartel-ferrin-gedrach fan ien bibleteek nei elke klant produsearret selswiske ferkearde antwurden.

Nei de wiziging, twing in nije autentikaasje op 'e troffen klant en befêstigje dat it spesifike ferrinberjocht fuort is. Fernij it blêd allinnich as it blêd sels ûngeskikt is. Tiidkontrôles útskeakelje of in histoarysk krússertifikaat weromsette produsearret gjin jildich aktueel paad; it fertraget allinnich de folgjende mislearring.