Խաչաձև ստորագրված CA. բանալին համընկնում է, AKI կապը՝ ոչ

Երկու CA վկայական կարող են կրել նույն հանրային բանալին և նույն subject-ը և այնուամենայնիվ փոխարինելի չլինել։ Մեկը ինքնաստորագրված է, մյուսը խաչաձև ստորագրվել է հին արմատի կողմից, և նրանց թողարկողի անունները, սերիական համարները և ստորագրությունները տարբերվում են։ Տերևը կարող է կապվել կոնկրետ մեկի հետ իր Authority Key Identifier-ի միջոցով։ Այդ կապը մնում է անտեսանելի, մինչև հաճախորդը ընտրի սխալ շղթան, և handshake-ը ձախողվի առանց ակնհայտ պատճառի։

Կատարեք այս հինգ ստուգումները հերթականությամբ. յուրաքանչյուրը բացառում է տարբեր ձախողում։

Ստուգում 1. գծեք երկու շղթաներն էլ, նախքան ձևանմուշին դիպչելը

Գրեք ուղիները։ Հին պոպուլյացիան վստահում է Հին արմատ A-ին, որը թողարկեց CA B-ն, որը թողարկեց սերվերի տերևը։ Նոր պոպուլյացիան ուղղակիորեն վստահում է ինքնաստորագրված CA B-ին։ Երկու B վկայականներն էլ կրում են նույն բանալին և subject-ը, և հենց դրա համար է, որ subject-ի տողը կարդացող մարդը տեսնում է մեկ CA, որտեղ հաճախորդը տեսնում է երկուսը։

Խաչաձև ստորագրված պատճենը նույնպես պետք է լինի իսկական CA վկայական՝ basic constraints-ով և key usage-ով, որոնք թույլ են տալիս ստորագրել։

Ստուգում 2. համեմատեք AKI դաշտերը, ոչ միայն բանալին

Տերևի թողարկողի անունը պետք է համապատասխանի B-ի subject-ին, և այդ մասը սովորաբար պահպանվում է։ Authority Key Identifier-ն այն տեղն է, որտեղ երկու պատճենները տարբերվում են, որովհետև այն կարող է կրել բանալու նույնացուցիչ, թողարկող վկայական և սերիական համար։ Բանալու նույնացուցիչը համապատասխանում է երկու պատճեններին էլ, քանի որ բանալին նույնն է։ Թողարկողի և սերիական համարի դաշտերը համապատասխանում են ճիշտ մեկին, և դրա համար է, որ ինքնաստորագրված պատճենի դեմ կառուցվող շղթան կարող է ձախողվել խաչաձև ստորագրվածի դեմ։

Ուսումնասիրեք տերևը՝ գուշակելու փոխարեն. openssl x509 -in server.pem -noout -ext authorityKeyIdentifier։

Այնուհետև համեմատեք երկու թեկնածուներն էլ openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier"-ով, և նույն հրամանը՝ ինքնաստորագրված պատճենի դեմ։

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

Ստուգում 3. փոխեք թողարկման քաղաքականությունը, երբեք՝ ստորագրված բայթերը

Ընդլայնումները ապրում են ստորագրության ներսում։ Գոյություն ունեցող տերևի վրա մեկն ավելացնելը, հեռացնելը կամ խմբագրելը վերանորոգում չէ, դա այլ վկայական է և պահանջում է վերաթողարկում։ Փոփոխությունը տեղ ունի թողարկման քաղաքականության մեջ. authorityKeyIdentifier = keyid,issuer:always-ը ստիպում է նոր տերևներին կրել վկայականին հատուկ կապը, մինչդեռ միայն keyid-ը պահպանում է ավելի թույլ ձևը, որը հարմար է դիտավորյալ խաչաձև ստորագրման անցմանը։ Որոշեք, թե որն է ուզում ձեր PKI-ն, նախքան հաջորդ խմբաքանակը կստորագրվի։

Համօգտագործվող ձևանմուշի խմբագրումը փոխում է նաև յուրաքանչյուր ապագա վկայական, ոչ միայն ձեր առջևի սերվերը։

Ստուգում 4. ստուգեք յուրաքանչյուր վստահության պոպուլյացիա առանձին

Փորձարկեք հին ուղին և նոր ուղին որպես առանձին գործարկումներ։ openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem-ը վարժեցնում է խաչաձև ստորագրված ուղին, և նույն հրամանը նոր արմատով և առանց untrusted ֆայլի վարժեցնում է ինքնաստորագրված ուղին։ Երկու արմատներն էլ մեկ փաթեթում խառնելը թաքցնում է, թե որ շղթան է ընտրվել։ Դրանից հետո կրկնեք իրական հաճախորդներով, որովհետև VPN backend-ը կարող է նախընտրել շղթա կամ ամրագրել վկայական այնպես, ինչպես openssl-ը չի անում։

Միջանկյալ վկայականը հանձնեք այն ծառայության կոնֆիգուրացիայի միջոցով, որը հաճախորդն իսկապես կարդում է, ոչ թե վիքի էջի միջոցով։

Ստուգում 5. պահեք հին ուղին շահագործումից հանելու ժամացույցի վրա

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

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