Айқас қол қойылған 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 жасамайтын тәсілдермен мүмкін.

Аралық сертификатты клиент шынымен оқитын қызмет конфигурациясы арқылы жеткізіңіз, wiki беті арқылы емес.

Тексеру 5: ескі жолды шығару сағатында ұстаңыз

Айқас қол қою ескі сенім жолын дизайн бойынша тірі ұстайды, бұл бір мезгілде мақсат та, тәуекел де. Ол бұзылған ескі тамырды жоймайды және сол тамырды ешбір клиенттен алмайды. Ескі жол қашан сенім бермейтінін жазыңыз және сол күннің шынымен келетінін растаңыз.

Егер әр клиент жаңа тамырды листтер жылжымас бұрын қабылдай алса, қарапайым қос сенімді енгізу айқас қол қоюдан оңайырақ, және шығаруға бір нәрсе кем қалады.