Айкаш кол коюлган 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: эски жолду иштен чыгаруу саатында кармаңыз

Айкаш кол коюу эски ишеним жолун долбоор боюнча тирүү кармайт, бул бир эле учурда максат жана тобокелдик. Ал бузулган эски тамырды жойбойт жана ал тамырды эч бир кардардан албайт. Эски жол качан ишеним бербей каларын жазыңыз жана ал күндүн чындап келерин ырастаңыз.

Эгер ар бир кардар жаңы тамырды барактар жылганга чейин кабыл ала алса, жөнөкөй кош ишенимдүү киргизүү айкаш кол коюудан оңой, жана иштен чыгарууга бир нерсе азыраак калат.