Վկայագրերի չեղարկումը ձախողվում է՝ ո՞ր հոսթը ինչին չի հասնում
Չեղարկման ստուգումները կատարվում են այն սարքում, որը վավերացնում է։ Գտեք CRL-ի բաշխման կետը, ստուգեք այդ հոսթի հասանելիությունը, ապա առանձնացրեք հնացած ցանկը չեղարկված վկայագրից։
Վկայագրերը կարող են լինել իրենց վավերականության ժամկետի սահմաններում, մինչ VPN-ը դեռ հաղորդում է նույնականացման ձախողման մասին, և ինչ-որ մեկը եզրակացնում է, որ վկայագիրը չեղարկված է։ Դրանք երեք տարբեր փաստեր են։ Չեղարկման տվյալները պետք է ստանա այն սարքը, որն իրականացնում է վավերացումը՝ հենց վկայագրի ներսում նշված հրապարակման կետից։ Երբ այդ սարքը չի կարողանում հասնել կետին, ստուգումը ձախողվում է վկայագրի կարգավիճակին չառնչվող պատճառներով։
Ներբեռնման ուղին վավերացնողինն է
Սկսեք վավերացնողի նույնականացումից։ Երբ նոութբուքը ստուգում է դարպասի վկայագիրը, ներբեռնումը կատարում է նոութբուքը. երբ դարպասը ստուգում է հաճախորդի վկայագիր, դա անում է դարպասը։ Հետին պլանի նույնականացման ծառայությունը կարող է ավելացնել երրորդ վավերացնող՝ իր ցանցային դիրքով։ Յուրաքանչյուրն ունի տարբեր երթուղի դեպի ինտերնետ և տարբեր պրոքսի կարգավորում։ Ադմինիստրատորի աշխատանքային կայանում հավաքված ապացույցները ոչինչ չեն ասում DMZ-ի ներսում գտնվող սերվերի մասին։
Նախքան որևէ բան փոխելը գրի առեք վկայագիրը, վավերացնողը, փորձի ժամանակը և ճշգրիտ կարգավիճակի կոդը։
Կարդացեք հրապարակման կետը վկայագրից
Վկայագիրը նշում է, թե որտեղ է գտնվում դրա կարգավիճակը։ Կարդացեք այդ դաշտերը՝ CA հասցե գուշակելու փոխարեն։
openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"Առաջին ընդլայնումը թվարկում է CRL-ի բաշխման կետերը, իսկ երկրորդը՝ մարմնի տեղեկատվության հասանելիության մեթոդները, որոնք կարող են ընդգրկել OCSP-ի կարգավիճակը և թողարկողի վկայագրի ներբեռնումը։ Դրանք տարբեր մեխանիզմներ են, և OCSP-ի պատասխանողը CRL ֆայլ չէ։ Հրապարակման հոսթը հաճախ սովորական վեբ սերվեր է, այլ ոչ թե CA-ի մեքենան, քանի որ անցանց թողարկողը կարող է ստորագրել CRL, որը տարածում է մեկ այլ սերվեր։ Ուստի CA-ին հասանելիություն նկարագրված հրմշտոցի կանոնը չափազանց անորոշ է ներդնելու կամ վերանայելու համար։
Ստուգեք ներբեռնումը վավերացնող սարքից
Ներբեռնման թեստը կատարեք այն միջավայրում, որը փաստացի իրականացնում է վավերացումը՝ հաստատված վկայագիր նյութով և առանց մասնավոր բանալիների։
certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crlcertutil-ի գործարկումը ստուգում է շղթան և հաղորդում, թե որ URL ներբեռնումները հաջողվեցին կամ ձախողվեցին, մինչ curl կանչը փորձարկում է մեկ հրապարակման հասցե նույն հոսթից և վերադարձնում է միայն կարգավիճակի կոդ։ Հասանելի հասցեից ձախողված ներբեռնումը մատնանշում է բովանդակության կամ ստորագրության խնդիրներ. միացման սխալը՝ երթուղավորման, DNS-ի կամ պրոքսիի։ Պահպանեք երկու արդյունքները, քանի որ մեկ հաջող ներբեռնում չի ապացուցում, որ ամբողջ շղթան օգտագործելի է։ Փոխարինեք օրինակի հոսթն ու ուղին վկայագրում գտնված բաշխման կետով։
Առանձնացրեք բացակայող տվյալները չեղարկման կարգավիճակից
Չորս արդյունք դրսից նույն են թվում՝ կետն անհասանելի է, ցանկը հնացած է, ցանկը ստորագրվել է սխալ թողարկողի կողմից, կամ վկայագիրն իսկապես չեղարկված է։ Միայն վերջինն է կարգավիճակի արդյունք, և միայն այն է արդարացնում հասանելիության հեռացումը։ Քեշավորումը պատկերն ավելի է բարդացնում, քանի որ նախկինում ներբեռնված տվյալները կարող են թաքցնել կոտրված հրապարակման ուղին մինչև հաջորդ թարմացումը։ Չեղարկման ստուգման անջատումը, անկապ վկայագրերի ջնջումը կամ դարպասի վերագործարկումը փոխարինում են ախտորոշումը գործունեությամբ։
Ուղղումից հետո պարտադրեք նոր նույնականացում և հաստատեք, որ նախատեսված կարգավիճակի ներբեռնումը հաջողվում է։ Որտեղ կա վերահսկվող փորձնական ինքնություն, հաստատեք, որ այն դեռ մերժվում է, քանի որ ստուգումը վերացնող հասանելիությունը վերանորոգում չէ։