Може ли синџирот на сертификати на серверот да го надмине складиштето за доверба на клиентот?

Браузерот прикажува предупредување за сертификат на страница чиј синџир е целосен, и првиот инстинкт е да се поправи серверот. Обично серверот го прикажува точно она што треба. Клиентот одлучува кои котви ги прифаќа, и ниту еден распоред на посредни сертификати не може да ја смени таа одлука од другиот крај на врската. Таа граница го објаснува најголемиот дел од она што изгледа како проблем со сертификат.

Валидацијата се изведува на клиентот, со котвите на клиентот

Валидацијата на патеката ги зема прикажаните сертификати и гради синџир до котва за доверба што валидацискиот систем веќе ја има. RFC 5280 го опишува тој модел и го става изборот на котва во локалната имплементација, а не во серверот. Апликацијата може да додаде сопствена политика врз тоа: фиксиран клуч, корпоративно складиште за доверба, или построга проверка на идентитетот. Списокот сертификати што серверот го испраќа е доказ понуден на тој процес, никогаш упатство до него.

Значи, целосниот синџир докажува дека серверот ги има деловите. Не докажува дека клиентот ќе ги прифати.

За да видите што всушност испраќа серверот, извршете openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts и избројте ги сертификатите во излезот. Нецелосен синџир таму е поправка на серверската страна. Целосниот синџир го преместува прашањето на клиентот и неговите котви, каде што серверот нема глас.

Што всушност менува TLS инспекцијата

Уредот за инспекција ја завршува TLS сесијата на клиентската страна и отвора одделна сесија до вистинската услуга. Клиентот потоа го валидира сертификатот на уредот, кој мора да се врзе до котва во која клиентот има доверба. Затоа управуваните уреди ја добиваат инспекциската коренска котва преку управување со уреди, и затоа личен уред без неа прикажува предупредување.

Распоредот е намерен и локален. Ништо во синџирот на оригиналниот сервер не може да присили неуправуван браузер да го прифати заменското идентитет, и ништо во него не спречува управуван уред да го стори тоа.

Завршувањето на VPN не е дешифрирање на HTTPS

VPN слојот пренесува пакети меѓу клиент и порта. Неговото отстранување, или читање на неговата конфигурација, не открива HTTPS товар внатре.

TLS сесијата уште се одвива меѓу браузерот и веб-серверот, со истите правила за валидација, освен ако нешто експлицитно не ја заврши. Мешањето на двата слоја создава барање до администраторот на VPN да го обезбеди сертификатот, додека сертификатот за кој станува збор припаѓа на инспекциски прокси или на самата страница. Прашајте кој компонент го прикажува сертификатот пред да смените било кое складиште за доверба.

Поставете очекувања во компонентата што ја контролирате

Ако ја управувате апликацијата и нејзиниот клиент, заедно дефинирајте го очекуваниот идентитет на услугата, прифатените издавачи и секое барање за фиксирање или клиентска автентикација. Планирајте обновување и закрепнување така што легитимната промена на сертификат да не стане прекин. Ако управувате само со јавниот сервер, документирајте каква автентикација барате и кои клиентски средини ги поддржувате. Испраќањето претпочитан синџир не го сертифицира уредот на непознат.

На управувана опрема, решете ја некомпатибилноста преку сопствениците на апликацијата и мрежата. Исклучувањето на верификацијата, додавањето необјаснет корен или обидот да се надживее инспекциска политика не воспоставуваат предвидениот партнерски однос.

Тестирајте го резултатот на чист клиентски профил, а не на машината каде што веќе е додаден исклучок. Тоа е единствената проверка што покажува што ќе доживее нов уред.