Да ли је iPad-у потребан сопствени клијентски сертификат за VPN?

Нови iPad се придружује тиму, а најбржи пут је извоз постојећег клијентског сертификата и инсталирање на таблету. То функционише док неко не оде, не изгуби уређај или не затражи ревизију која показује који се уређај и када повезао. Одлука није о датотеци сертификата већ о идентитету: да ли се сваки уређај може засебно ауторизовати и опозвати. Трошак и напор управљања одређују одговор, и обоје је мање него што изгледа.

Заједнички издавалац, одвојени идентитети

Сваки уређај може веровати истом сертификационом телу и повезати се са истим пролазом док има другачији клијентски идентитет. Издавалац је сидро поверења, а идентитет је пар кључева чији субјекат сервер пресликава у политику. Управо мешање тога двоје чини заједнички сертификат наизглед безопасним. Он остаје безопасан само док некоме не затреба да зна који је уређај отворио сесију.

Дељење издаваоца штеди конфигурацијски рад и ништа не мења у одговорности по уређају. Дељење идентитета сажима сваки уређај у једну опозиву јединицу: опозив једног опозива све, а овлашћење замене овлашћује сваку икада направљену копију кључа. Ту размену вреди учинити изричито, а не копирањем датотеке зато што је петком поподне брже.

Када други сертификат кошта превише

Регистрација по уређају кошта један корак: управљани профил, SCEP захтев или вођени увоз са једнократном лозинком. Потребно је и место за праћење серијских бројева и датума истека, део који већина имплементација заборави док први сертификат не истекне. Оба трошка су једнократна и оба се смањују када ток регистрације то аутоматизује.

Трошак је стваран за домаћинство са два таблета и једним корисником, где је заједнички идентитет разумна одлука документована у једној реченици. Није разуман за услугу у којој приступ мора да се повуче по особи или по уређају, јер је прича о опозиву цео разлог за коришћење сертификата уместо лозинке. Процените имплементацију по томе колико често уређаји мењају власника, а не по томе колико уређаја данас постоји.

Региструјте уређај, не копирајте кључ

Савремене платформе држе приватне кључеве у заштићеном складишту, а неке их по дизајну означавају као неизвозне. Управо то својство чини копирање немогућим од почетка, и то је разлог зашто извезени пакет са преносног рачунара не може једноставно поново да се увезе на таблет ни на један подржан начин. Покушај ипак ствара профил који се чисто инсталира и затим никада не аутентификује.

Користите метод регистрације који имплементација већ подржава: управљани профил идентитета, SCEP услугу или ток заснован на налогу који издаје нови кључ на уређају. Дељење приватног кључа сертификационог тела ради решавања идентитета који недостаје је друга грешка са много већим радијусом утицаја. Тело издаје акредитиве и никада не треба да путује до крајње тачке.

Проверите опозив пре него што одговорите

Пре него што изаберете заједничку опцију, опишите како опозив изгледа на најгори дан. Ако је одговор једна радња која погађа неколико уређаја, дизајн је већ одлучио против вас.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Прегледајте материјал који заиста имате: да ли постоји приватни кључ, шта каже субјекат и да ли се серијски број може опозвати појединачно. Датотека сертификата без свог кључа не може ништа да аутентификује, и зато неки копирани идентитети не успевају при првој вези.

Брисање апликације са таблета није опозив, а сервер наставља да прихвата идентитет док га неко не онемогући. Запишите ту реченицу у процедуру пре регистрације првог уређаја.