Сам CSR није регистрација: шта VPN CA мора да провери

Захтев за потпис сертификата садржи јавни кључ и тражени subject, потписане одговарајућим приватним кључем. Тај потпис доказује да подносилац поседује кључ. Не доказује да подносилац има право на тражено име, уређај или VPN улогу, и поступање са захтевом као да то доказује је управо начин на који тикет помоћне службе постаје додела приступа.

Два модела регистрације вреди упоредити по томе шта повезују, а не по томе којим протоколом говоре.

Захтев тврди име, али га не доказује

Прочитајте захтев по ономе што заиста садржи: јавни кључ, subject који је подносилац изабрао и сопствени потпис над оба. Ништа у тој структури не упућује на ваш инвентар, именик налога или ток одобрења. Subject као cn=finance-laptop је низ који је неко откуцао. Док процес издавања не провери тај низ према запису ком верује, сертификат је тврдња са приложеним потписом. Та разлика је цео разлог постојања процеса регистрације.

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

Упоредите моделе по томе шта повезују

Ручно потписивање повезује оно чега се оператер сећа да провери. Аутоматизована служба регистрације повезује аутентификован захтев са одлуком коју служба може да спроведе, а RFC 7030 описује један такав дизајн где се клијент аутентификује пре него што се сертификат врати. Разлика која преживи ревизију није аутоматизација; него то да ли се провера идентитета одвија унутар пута издавања или поред њега.

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

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

Забележите животни циклус од првог издавања

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

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

Проверите издати сертификат, затим приступ

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

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

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