net-stipe sertifikaatdoel: wêrom de tuskenlizzende CA mislearret

It doel fan it serversertifikaat liket goed, de kaai komt oerien, de datums binne yn oarder, en de ferbining mislearret noch altyd mei unsupported certificate purpose. It detail dat dit oplost, stiet meastentiids op deselde rigel as de flater: in djiptewearde en in subject dy't in sertifikaat heger yn 'e keatling neame. Twa ferskillende tests wurde útfierd, en mar ien fan beide giet oer it blêd. It fergelykjen fan dy beide ferklearret wêrom't it ferfangen fan it serversertifikaat neat feroaret.

Hokker sertifikaat de ferifiearder eins wegere

In keatling is net ien objekt dat trije kear werhelle wurdt. It blêd draacht de namme en kaai fan 'e server, de tuskenlizzende sertifikaten ferbine it mei in woartel, en elk hat syn eigen jildichheidsperioade, beheiningen en gebrûken. As de flater in djipte neamt, wiist dat nûmer in posysje oan yn 'e keatling dy't de ferifiearder boud hat, en dat is miskien net de posysje dy't jo ferwachtsje as de server in ûnferwachte keatling stjoert.

Lês de fjilden fan it sertifikaat op dy djipte yn stee fan it sertifikaat dat jo as skuldige oannamen. Freegje om de twa útwreidings dy't de útjefte beheine yn stee fan elk fjild te dumpen, want it antwurd sit hast altyd yn ien fan beide. Útwreidingsútfier is feilich om te dielen; privee kaaien nea.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

As it neamde sertifikaat in tuskenlizzend sertifikaat is wêrfan't it útwreide kaai gebrûk eat neamt dat net mei TLS-serverautentikaasje te meitsjen hat, folget de rest fan 'e flater meganysk. De keatling kin net brûkt wurde foar it doel dat OpenVPN oanfrege hat.

It doel fan it blêd en it belied fan 'e keatling binne twa tests

De blêdtest stelt in smelle fraach: tastiet dit einentiteit-sertifikaat serverautentikaasje foar dizze namme? De keatlingtest stelt in bredere: mei elk sertifikaat yn it paad dat doel tsjinje? In sertifikaatautoriteit dy't allinnich kliïntsertifikaten útjaan mei, sil syn eigen hantekeningstests helje en dochs foar de twadde test falle, om't it paad dat it autorisearret it doel net omfettet dat de applikaasje nedich hat. De beide tests falle mei deselde wurden en hawwe folslein ferskillende reparaasjes.

Dêrom kin in krekt útjûn blêd, korrekt yn elk sichtber fjild, daliks mislearje. Dêrom heart de reparaasje meastentiids by it profyl fan 'e útjaande autoriteit en net by de VPN-konfiguraasje.

In ûntbrekkende EKU is gjin beheinende EKU

RFC 5280 makket de útwreiding foar útwreide kaai gebrûk opsjoneel en, as dy der is, beheinend. In CA-sertifikaat sûnder de útwreiding hat dus gjin 'nee' sein tsjin serverautentikaasje, wylst ien dat allinnich in ûnferbûn doel neamt eat hiel spesifyks sein hat. It behanneljen fan dy beide tastannen as gelykweardich jout de ferkearde diagnoaze en, slimmer, de ferkearde reparaasje. It ûnderskie ferklearret ek wêrom't twa autoriteiten dy't yn in konsôle opinoar lykje har yn in keatling folslein oars drage.

It gedrach fan bibleteken is hjir ek net ienriedich. OpenSSL-dokumint oer ferifikaasje-opsjes beskriuwt syn eigen behanneling fan doeltests op CA-sertifikaten, en dy behanneling is in ymplemintaasjebelied en net in regel dy't elke TLS-stapel identyk folget. Beskriuw wat jo ferifiearder docht en befêstigje dat dan tsjin 'e ferzje dy't jo eins draaie.

Reprodusearje de flater offline foardat jo opnij útjouwe

In offline ferifikaasje hellet de applikaasje út 'e fraach. As de keatling op deselde wize ûnder itselde doel mislearret, is it sertifikaat it probleem en gjin inkelde serverkonfiguraasje sil dat ferbergje. As de keatling offline slagget wylst de tsjinst noch wegert, freget de applikaasje in oar doel oan of brûkt er in oare keatling as dy't jo testen.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain is wichtich om't it it paad printsje dat it ark boud hat, en dat is faak net de triemfolchoarder dy't jo opjûn hawwe. Dy útfier is de fluchste manier om te ûntdekken dat in twadde tuskenlizzend sertifikaat út in fertrouwensopslach lutsen wurdt, dat de server in krúshantekene fariant stjoert dy't jo net bedoelden, of dat de doelflagge dy't jo út in hantlieding kopiearre hawwe by in oare rol heart as dy't tsjinne wurdt.

Reparearje it útjeftebelied, net de ferifikaasjeoprop

De duorsume reparaasje is in tuskenlizzend sertifikaat útjûn ûnder in belied dat de doelen tastiet dy't it tsjinje moat, mei de beheining opskreaun en besjoen. Elk doel by elke autoriteit foegje is gjin belied; it hellet de beheining fuort dy't de útwreiding betsjutting joech, en it oerlibbet meastentiids it ynsidint dat it oanlieding joech. In koarte notysje yn it profyl dy't beskriuwt hokker rollen de autoriteit sertifisearje mei, foarkomt dat de folgjende útjefte deselde diskusje werhellet.

It útskeakeljen fan ferifikaasje is de oare ferliedlike fluchwei, en it feroaret in sertifikaatprobleem yn in fertrouwensprobleem. Hâld de doeltest yn stân, reparearje de keatling en draai deselde offline ferifikaasje opnij om te befêstigjen dat it paad no de bedoelde rol tsjinnet foardat jo de tsjinst wer oanreitsje.