Տերևի վկայականը վավեր է, շղթան ժամկետանց է՝ կարդացեք խորությունը

Դուք ստուգում եք սերվերի վկայականը, ժամացույցի վրա դեռ ամիսներ եք տեսնում, և հաճախորդը դեռևս մերժում է կապը ժամկետանցության հաղորդագրությամբ։ Ձեր կարդացած ամսաթիվը պատկանում է տերևին, և բողոքը կարող է լինել ուղու ավելի խորը ինչ-որ բանի մասին։ Ստուգումն անցնում է շղթայով, և այս անցման ընտրած ցանկացած վկայական կարող է ձախողվել իր սեփական վավերականության պատուհանում։ Կարդացեք, թե որն է ձախողվել, նախքան որևէ բան նորացնելը։

Խորությունը նշում է այն վկայականը, որը ձախողվել է

OpenSSL-ի ախտորոշման մեջ խորություն 0-ը թիրախ վկայականն է, իսկ խորություն 1-ը՝ այն ստորագրած թողարկողը, ընդ որում ավելի մեծ թվերը շարունակվում են դեպի վստահության խարսխակետը։ Խորություն 1-ում հաղորդված ժամկետանցությունը չի հերքվում տերևի վրա գտնվող ընթացիկ notAfter-ով, ուստի տեսանելի վկայականի կրկնակի ստուգումը երբեք չի բացատրի սխալը։

Գրանցեք ձախողված վկայականի մատնահետքը նրա subject-ի հետ միասին, որովհետև տարբեր վկայականներ կարող են կրել նույն CA անունը։ Խաչաձև ստորագրումը ստեղծում է հենց այդ իրավիճակը. նույն մարմինը հայտնվում է մեկից ավելի անգամ՝ տարբեր վավերականության ամսաթվերով, և ստուգողն ընտրել է այն, ինչը դուք չէիք սպասում։ Ծանոթ պիտակը նույնացուցիչ չէ, և մատնահետքն այն է, ինչը տարբերում է նույն անունը կիսող երկու օբյեկտների։

Ուշադրություն դարձրեք նաև մեկից ավելի վկայականի դեր ունեցող ապրանքներին։ OpenVPN Access Server-ում վեբ ինտերֆեյսները պաշտպանող վկայականները առանձնացված են VPN կապերի համար օգտագործվողներից, ուստի ադմինիստրատորի էջը բացող դիտարկիչը ոչինչ չի ապացուցում թունելի ուղու մասին։

Վստահության մուտքերը նույնը չեն, ինչ շղթայի թեկնածուները

Տվեք ստուգողին երկու մուտքերն առանձին և բացահայտ։ Վստահության ֆայլը պարունակում է ձեր ընդունած խարսխակետերը. չվստահվող փաթեթը պարունակում է ուղին կառուցելու համար առաջարկվող միջանկյալ վկայականներ։ Դրանք խառնելն այն է, ինչպես մարդիկ պատահաբար միջանկյալ վկայականը բարձրացնում են արմատի աստիճանի և հետո զարմանում, թե ինչու նույն սխալը հետևում է նրանց մեքենաների միջև։

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

Լռելյայն ուղու և պահոցի անջատումը -no-CApath -no-CAstore-ով թեստը պահում է ազնիվ. արդյունքն այդ դեպքում կախված է ձեր նշած ֆայլերից, այլ ոչ թե նրանից, ինչին աշխատանքային կայանը պատահաբար վստահում է։ OpenSSL-ի ստուգման տեղեկագիրը փաստագրում է այս ընտրանքները և դրանց առաջացրած ախտորոշումը։

-show_chain տպում է կառուցված շղթան, երբ ստուգումը հաջողվում է, ինչը օգտակար է հաստատելու, որ ուղին ձեր նախատեսածն է։ Երբ այն ձախողվում է, պահեք հաղորդված խորությունը և subject-ը. այս երկու դաշտերը հաջորդ ընթերցողին ասում են, թե որ վկայականը ստուգել։

Ինչ այս չի անում, դա յուրաքանչյուր հաճախորդի քաղաքականության վերարտադրումն է։ Pin-ը, նպատակի սահմանափակումը կամ հաճախորդին հատուկ ինքնության ստուգումը ապրում է հաճախորդում, ոչ այս հրամանում։ Դա այն կարգավորումներն են, որոնք պետք է ստուգել, երբ սերվերի վրա ստուգումն անցնում է, իսկ կապը դեռ ձախողվում է։ Առանձնացրեք երկու ախտորոշումները, այլապես կնորացնեք առողջ վկայական՝ հետապնդելով pinning-ի սխալ։

Ինչ է ապացուցում ստուգումը և ինչ է թողնում դուրս

Սա ուղու և նպատակի ստուգում է ձեր տրամադրած վստահության ֆայլի դեմ։ HTTPS անվան ստուգման համար ավելացրեք սպասվող հոսթի անունը համապատասխան ընտրանքով. VPN կապի համար պահեք հաճախորդի կարգավորված ինքնության ստուգումները և օգտագործեք այն վստահության նյութը, որը այդ հաճախորդն իսկապես կարդում է։

Ինչ սերվերն ուղարկում է, թեկնածուների հավաքածու է, ոչ այն ուղին, որը ձեր հաճախորդը վերջում կկառուցի։ Տեղական վստահությունը և գրադարանի կառուցման կանոնները երկուսն էլ ձևավորում են արդյունքը, այդ պատճառով նույն պատասխանը կարող է ստուգվել մի մեքենայում և ձախողվել մյուսում։ Համեմատեք ձախողվող հաճախորդի պահպանվող վստահության պահոցը և TLS իրականացումը աշխատող հաճախորդի հետ նախքան նույնական գնահատում ենթադրելը։ Այնտեղի տարբերությունը բացատրում է «միայն այս նոութբուքն է ձախողվում» բազմաթիվ հաղորդումները։

Յուրաքանչյուր վկայականի պատուհանը մեկ առ մեկ տեսնելու փոխարեն տպեք դրանք որպես հավաքածու՝

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

Երկրորդ հրամանը ցուցակում է subject-ներ և թողարկողներ՝ առանց յուրաքանչյուր ֆայլը ձեռքով վերծանելու, այդպես եք նկատում միջանկյալ վկայական, որի ամսաթիվն անցել է, մինչ տերևը դեռ լավ տեսք ունի։

Վերանորոգեք ուղին առանց թուլացնելու ստուգումը

Երբ տրամադրվում է ժամկետանց միջանկյալ կամ հնացած խաչաձև ստորագրված վկայական, ստացեք թողարկողի ներկայումս աջակցվող շղթան և տեղակայեք այն ծառայության փաստագրված վկայականի աշխատահոսքի միջոցով։ Երբ հաճախորդը չունի նախատեսված պահպանվող խարսխակետը, թարմացրեք նրա կառավարվող վստահության կարգավորումը կամ հաճախորդի ծրագրաշարը։ Դիմացեք այն կարճուղուն, որը փաթեթի յուրաքանչյուր վկայական նշում է որպես արմատ միայն հաղորդագրությունը լռեցնելու համար։

Արմատի հետ վարվելը նշումի արժանի է, որովհետև ամփոփումները հաճախ չափազանցնում են այն։ RFC 5280-ը խարսխակետը դիտարկում է որպես սպասվող ուղուց դուրս գտնվող մուտք, մինչդեռ OpenSSL-ը փաստագրում է վավերականության ստուգումներ, որոնք ներառում են նրա արմատային CA վկայականը։ Երկու պնդումներն էլ ճիշտ են իրենց սեփական համակարգերի համար. մեկ գրադարանի արմատի ժամկետանցության վարքը բոլոր հաճախորդներին ընդհանրացնելը տալիս է ինքնավստահ սխալ պատասխաններ։

Փոփոխությունից հետո պարտադրեք թարմ նույնականացում տուժած հաճախորդի վրա և հաստատեք, որ կոնկրետ ժամկետանցության հաղորդագրությունն անհետացել է։ Նորացրեք տերևը միայն այն դեպքում, երբ տերևն ինքնին անպիտան է։ Ժամանակի ստուգումների անջատումը կամ պատմական խաչաձև վկայականի վերականգնումը չի ստեղծում վավեր ընթացիկ ուղի. այն միայն հետաձգում է հաջորդ ձախողումը։