Ліставы сертыфікат сапраўдны, ланцуг скончаны: чытайце глыбіню

Памылка тэрміну можа належаць выпушчальніку, а не лісту. Прачытайце глыбіню праверкі і ўваходныя даныя даверу, перш чым паднаўляць сертыфікат, які ўсё яшчэ выглядае актуальным.

Вы правяраеце сертыфікат сервера, бачыце, што на гадзінніку яшчэ месяцы, а кліент усё роўна адхіляе злучэнне з паведамленнем аб заканчэнні тэрміну. Дата, якую вы чытаеце, належыць лісту, а скарга можа датычыцца чагосьці глыбей у шляху. Праверка ідзе па ланцугу, і любы сертыфікат, які выбера гэты праход, можа не прайсці сваё ўласнае акно сапраўднасці. Прачытайце, які менавіта не прайшоў, перш чым нешта паднаўляць.

Глыбіня называе сертыфікат, які не прайшоў

У дыягностыцы OpenSSL глыбіня 0 — гэта мэтавы сертыфікат, а глыбіня 1 — выпушчальнік, які яго падпісаў; большыя лікі вядуць далей да якара даверу. Заканчэнне тэрміну, паведамленае на глыбіні 1, не супярэчыць дзейнаму notAfter на лісце, таму паўторная праверка бачнага сертыфіката ніколі не патлумачыць памылку.

Запішыце адбітак памылковага сертыфіката разам з яго суб’ектам, бо розныя сертыфікаты могуць мець адно і тое ж імя 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 выводзіць пабудаваны ланцуг, калі праверка паспяховая, што карысна для пацверджання, што шлях — менавіта той, які вы мелі на ўвазе. Калі яна не праходзіць, захавайце паведамленую глыбіню і суб’ект; гэтыя два палі скажуць наступнаму чытачу, які сертыфікат правяраць.

Чаго гэта не робіць — не ўзнаўляе палітыку кожнага кліента. Прымацаванне, абмежаванне мэты або праверка ідэнтычнасці, спецыфічная для кліента, жыве ў кліенце, а не ў гэтай камандзе. Менавіта гэтыя налады трэба правяраць, калі на серверы праверка праходзіць, а злучэнне ўсё роўна не ўсталёўваецца. Трымайце дыягностыкі асобна, інакш вы падновіце здаровы сертыфікат, палюючы за памылкай прымацавання.

Што праверка даказвае і што пакідае за бортам

Гэта праверка шляху і мэты супраць файла даверу, які вы падалі. Для праверкі імені HTTPS дадайце чаканае імя хоста праз адпаведны параметр; для VPN-злучэння захавайце наладжаныя праверкі ідэнтычнасці кліента і выкарыстоўвайце той матэрыял даверу, які гэты кліент сапраўды чытае.

Тое, што пасылае сервер, — набор кандыдатаў, а не шлях, які ў рэшце рэшт пабудуе ваш кліент. Лакальны давер і правілы пабудовы бібліятэкі разам фармуюць вынік, таму адзін і той жа адказ можа прайсці праверку на адной машыне і не прайсці на другой. Параўнайце кіраванае сховішча даверу і рэалізацыю TLS кліента, які не праходзіць, з такімі ж у працоўнага кліента, перш чым меркаваць аднолькавую ацэнку. Розніца там тлумачыць многія паведамленні «не працуе толькі на гэтым ноўтбуку».

Каб убачыць акно кожнага сертыфіката, а не па адным, выведзіце іх наборам:

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

Другая каманда пералічвае суб’екты і выпушчальнікаў, не дэкадуючы кожны файл уручную, так вы заўважаеце прамежкавы сертыфікат, чый тэрмін мінуў, пакуль ліст яшчэ выглядае добра.

Адрамантуйце шлях, не паслабляючы праверку

Калі падаецца пратэрмінаваны прамежкавы або састарэлы перакрыжавана падпісаны сертыфікат, атрымайце бягучы падтрымліваемы ланцуг выпушчальніка і разгарніце яго праз дакументаваны працэс сертыфікатаў сэрвісу. Калі кліенту не хапае мэтавага кіраванага якара, абнавіце яго кіраваную канфігурацыю даверу або праграмнае забеспячэнне кліента. Супраціўляйцеся спакусе пазначыць кожны сертыфікат у наборы як корань, каб проста заглушыць паведамленне.

Апрацоўка кораня заслугоўвае заўвагі, бо зводкі часта яе перабольшваюць. RFC 5280 разглядае якар як уваход, які знаходзіцца па-за меркаваным шляхам, а OpenSSL дакументуе праверкі сапраўднасці, якія ўключаюць яго каранёвы сертыфікат CA. Абодва сцверджанні слушныя для сваіх сістэм; абагульненне паводзін заканчэння тэрміну кораня адной бібліятэкі на кожнага кліента дае ўпэўненыя няправільныя адказы.

Пасля змены прымусьце кліента, якога закранула праблема, прайсці новую аўтэнтыфікацыю і пацвердзіце, што пэўнае паведамленне аб заканчэнні тэрміну знікла. Паднаўляйце ліст, толькі калі сам ліст непрыдатны. Адключэнне праверкі часу або аднаўленне гістарычнага перакрыжаванага сертыфіката не стварае сапраўднага бягучага шляху; яно проста адкладвае наступную няўдачу.

Падобныя артыкулы