Што правярае ваш VPN-кліент, перш чым даверыць сертыфікату

Ваш VPN-кліент паведамляе, што сертыфікат не ўдалося праверыць, і на гэтым дыялог спыняецца. Файл на месцы, сервер працуе, і той жа профіль працаваў на іншым ноўтбуку ў мінулым месяцы. Пад гэтым аднарадковым папярэджаннем кліент прапусціў сертыфікат вузла праз чатыры вароты: цэнтр сертыфікацыі, які вы наладзілі, сведчыць за шлях подпісу, гэты шлях дасягае цэнтра, імя вузла — тое, што вы запыталі, і сертыфікат прыдатны цяпер для гэтага прызначэння. Знайдзіце вароты, якія зачыніліся, і рамонт звычайна ў адным файле; прапусціце гэты крок, і вы будзеце перазалічваць наборы ўвесь дзень.

Прачытайце дыялог, перш чым правіць профіль

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

Падвышце ўзровень журнала, перш чым нешта змяняць. OpenVPN паведамляе пра збой праверкі вакол рукапаціску, калі запусціць яго з --verb 4, а strongSwan запісвае свае рашэнні пра асобу і ланцуг у журнал charon. Затым пацвердзіце, які менавіта сертыфікат вы даследуеце, бо людзі звычайна правяраюць файл на дыску, пакуль профіль убудоўвае старэйшую копію. Калі профіль змяшчае блокі PEM, тэсціруецца менавіта ўбудаваны сертыфікат.

Цэнтр сертыфікацыі падпісвае асобы, а не дазволы

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

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

Пабудуйце шлях, які кліент спрабуе пабудаваць

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

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Нулявы код выхаду азначае, што шлях пабудаваны з гэтых файлаў; збой называе сертыфікат, да якога не ўдалося дасягнуць. Калі openssl verify паспяховы, а кліент усё яшчэ адмаўляе, розніца ў тым, што сервер фактычна дасылае, або ў тым, які файл даверу загружае профіль. У OpenVPN прамежкавыя сертыфікаты могуць ісці разам з файлам сертыфіката сервера або падавацца асобна з --extra-certs, а набор з двума каранямі пад адным імем суб’екта накіруе аднаго з вашых кліентаў у няправільную галіну.

Імя і прызначэнне — асобныя вароты

Пабудова ланцуга ніколі не пытаецца, ці ваша гэта імя. OpenVPN правярае яго, толькі калі профіль задае --verify-x509-name, а старажытная звычка супастаўляць толькі агульнае імя ламаецца на сертыфікатах, чые асобы жывуць у subjectAltName. Разгортванні IKEv2 супастаўляюць наладжаную асобу з запісамі SAN або з адметным імем, у залежнасці ад кліента, а значэнне шаблона або %any ціха адключае параўнанне, якое вы думалі, што маеце.

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

Адкліканне працуе, толькі калі хтосьці яго наладзіў

CRL або адказ OCSP не аналізуюцца аўтаматычна. На серверы OpenVPN кліенцкія сертыфікаты звяраюць са спісам, толькі калі --crl-verify паказвае на яго. Праверка сертыфіката сервера з боку кліента залежыць ад рэалізацыі і часта адсутнічае. strongSwan патрабуе свайго плагіна адклікання і палітыкі, перш чым паглядзець на CRL для вузла.

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

Парадак рамонту, які пакідае праверку ўключанай

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

Прайдзіце спіс за адзін заход: пацвердзіце файл, які загружае профіль, пабудуйце шлях самі, праверце, што сервер дасылае прамежкавы сертыфікат, параўнайце гадзіннік, прачытайце SAN, прачытайце EKU, потым перападключыцеся і назірайце, як той жа радок журнала знікае. Калі прыладзе зусім нельга даць ЦС, замацаванне — сумленная альтэрнатыва, бо OpenVPN 2.6 прымае --peer-fingerprint і звужвае давер да аднаго ключа замест таго, каб прыбраць праверку. RFC 5280 — даведнік пра значэнне кожнага з гэтых палёў.