Ang CSR lamang ay hindi enrollment: ano ang dapat suriin ng CA ng VPN
Ang hiling na lagdaan ay nagpapatunay lamang ng paghawak sa susi at wala nang iba. Ihambing ang mga modelo ng enrollment sa kung ano ang binibigkis nila bago magbigay ng access sa VPN ang CA.
Ang hiling na lagdaan ang sertipiko ay may pampublikong susi at hiniling na subject, na nilagdaan ng katumbas na pribadong susi. Ang lagda ay nagpapatunay na taglay ng humihiling ang susi. Hindi nito pinatutunayan na may karapatan ang humihiling sa hinihiling na pangalan, device o papel sa VPN, at ang ituring itong nagpapatunay ay siya mismong paraan kung paano nagiging pagbibigay ng access ang isang tiket sa help desk.
Dalawang modelo ng enrollment ang dapat ihambing sa kung ano ang binibigkis nila, hindi sa kung anong protocol ang sinasalita nila.
Ang hiling ay nagsasabi ng pangalan, hindi ito pinatutunayan
Basahin ang hiling sa kung ano talaga ang laman nito: pampublikong susi, subject na pinili ng humihiling, at sariling lagda sa dalawa. Wala sa estrukturang iyon ang tumutukoy sa iyong imbentaryo, direktoryo ng account o daloy ng pag-apruba. Ang subject na tulad ng cn=finance-laptop ay isang string na tinipa ng isang tao. Hanggang hindi sinusuri ng proseso ng pag-isyu ang string na iyon laban sa rekord na pinagkakatiwalaan nito, ang sertipiko ay isang pahayag na may kalakip na lagda. Ang pagkakaibang iyon ang buong dahilan kung bakit may proseso ng enrollment.
Mahalaga ito sa operasyon. Hindi kailanman kailangan ng awtoridad ng sertipiko ang pribadong susi ng kliyente para mag-isyu ng sertipiko, at ang daloy na humihingi nito ay napagkamalan ang paglagda sa pag-iingat ng susi. Panatilihin ang pagbuo sa endpoint at ipadala lamang ang pampublikong kalahati.
Ihambing ang mga modelo sa kung ano ang binibigkis nila
Ang manu-manong paglagda ay nagbibigkis sa kung ano ang naaalalang suriin ng operator. Ang awtomatikong serbisyo ng enrollment ay nagbibigkis ng awtentikadong hiling sa desisyong maipatutupad ng serbisyo, at inilalarawan ng RFC 7030 ang isang gayong disenyo kung saan nagpapatunay ng pagkakakilanlan ang kliyente bago ibalik ang sertipiko. Ang pagkakaibang tumatagal sa isang audit ay hindi awtomasyon; ito ay kung ang pagsusuri ng pagkakakilanlan ay nangyayari sa loob ng landas ng pag-isyu o sa tabi nito.
Kailangan pa ring sagutin ng dalawang modelo ang parehong tatlong tanong. Sino ang humihiling, sa aling device o papel, at hanggang kailan. Ang sistemang may tiket na nagtatala ng mga sagot ay gumagawa ng tunay na trabaho; ang pila kung saan may tumitingin sa karaniwang pangalan ay hindi, gaano man kaingat na ma-format ang sertipiko mamaya.
Piliin ang modelo ayon sa bilang ng enrollment na inaasahan at sa pagpapalit ng mga device. Ang ilang server kada taon ay nakakayanan ang manu-manong pagsusuri na may nakasulat na checklist. Ang isang fleet ng laptop ay hindi.
Itala ang ikot ng buhay mula sa unang pag-isyu
Itabi ang identifier ng sertipiko, may-ari, inaasahang gamit, pagtatapos at landas ng pagtanggal sa sandali ng pag-isyu, hindi sa unang insidente. Ang inaasahang gamit ay dapat nasa sertipiko mismo sa pamamagitan ng pinalawak na paggamit ng susi, at dapat tumugma ang rekord dito. Ang sertipikong ginawa para sa awtentikasyon ng kliyente ay hindi dapat hindi makilala mula sa para sa server.
Planuhin ang pag-renew at pagbawi ng nawalang device bago mag-isyu ng ika-sampung profile. Ang sertipikong ibinabahagi sa isang departamento ay ginagawang pagkagambala ang naka-target na pagtanggal, at ang desisyong iyon ay mas murang balikan ngayon kaysa sa panahon ng insidente ng Biyernes.
Suriin ang inisyung sertipiko, pagkatapos ang access
Pagkatapos ng enrollment, siyasatin kung ano ang inisyu at tiyakin na nagkakadena ito sa awtoridad na inaasahan. Dalawang utos ang sumasaklaw sa karaniwang pagkakamali: sertipikong may maling gamit, at kadenang gumagana lamang dahil naka-configure ang kliyente na huwag pansinin ang validation.
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
Pagkatapos ay subukan ang access, hindi ang artifact. Ang sertipiko ay nagtatatag ng pagkakakilanlan, at ang patakaran pa rin ang nagpapasya kung aling mga serbisyo ang maaabot ng pagkakakilanlang iyon. Suriin ang dalawa, dahil ang tamang artifact na may masyadong malawak na patakaran ay bumabagsak din sa pagsusuri. Tiyakin na nagpapatunay ng pagkakakilanlan ang kliyente at natatanggap lamang ang inaasahang ruta o mapagkukunan. Itala ang naobserbahan mo, hindi ang dapat gawin ng profile.
Ang profile na gumagana sa maling dahilan, tulad ng tumutugmang karaniwang pangalan at walang pagsusuri ng pagkakakilanlan, ay patuloy na gagana pagkatapos alisin ang kontrol na akala mo ay mayroon ka.