کاملترین آموزش راه اندازی CA مایکروسافت از مفاهیم تا ریزه کاری ها
با قویترین مقاله راه اندازی CA یا Certificate Authority سرویس PKI مایکروسافت در خدمت شما هستیم. در این مقاله قصد دارم تمام اطلاعات و اصطلاحاتی که در سرویس Certificate Authority مایکروسافت وجود دارد به علاوه Feature های جدید آن را توضیح و حدالامکان مثالی در رابطه با آن زده بشه تا کاربران بتوانند یک شناخت نسبتا کامل از این سرویس داشته باشند.همانطور که می دانید این سرویس (به نظر خودم) یکی از پیچیدترین سرویس های می باشد که یک آدمین با آن می تواند سرکار داشته باشد.
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
- Certificate Authority Server
- امضای دیجیتال (Digital Signature)
- گواهینامه دیجیتال (Digital Certificate)
- رمزنگاری نامتقارن (Asymmetric Encryption)
- Public Key Infrastructure (PKI)
- Registration Authority
- Certificate Revocation List یا CRL
- Certificate Enrollment
- Certificate Life Cycle
- Renew a Certificate
- Certificate Usage
- Certificate Signing Request
- Certification Authority Hierarchies
- Certification Path
- Certificate Path Validation
- معرفی انواع Certificate Authorities یا PKI Server
- Policy modules ها
- گواهینامه های باطل شده (Certificate Revocation List)
- Authority Information Access (AIA) چیست؟
- لیست CRL
- Online Certificate Status Protocol یا (OCSP) چیست؟
- معرفی اجزای Online Certificate Status Protocol
- نحوه پیاده سازی OCSP چگونه است؟
- معرفی انواع پیاده سازی OCSP در سازمان
- آموزش نصب سرویس Online Certificate Status Protocol
- آموزش آماده سازی محیط سازمان برای استفاده از این سرویس
- آموزش تنظیم سرویس OCSP
- آموزش تنظیمات OCSP URIs با گروپ پالیسی
- آموزش رفع اشکال سرویس Online Responder
- آموزش ساخت Certificate Template یا قالب گواهینامه
- معرفی نسخه های مختلف Certificate Template
- آموزش مدیریت Certificate templates
- آموزش تنظیمات Certificate Enrollment
- آموزش تنظیمات Certificate Auto-Enrollment
- One-Tier Hierarchy چیست؟
- Three-Tier Hierarchy چیست؟
- Two-Tier Hierarchy چیست؟
- رابطه اعتماد در CA Hierarchy چگونه است؟
- آموزش تنظیمات اولیه Web Server
- آموزش ایجاد Alias CNAME برای پارمترهای AIA/CDP
- آموزش نصب Standalone Offline Root CA
- آموزش نصب Standalone Offline Intermediate CA
- آموزش نصب Enterprise Mahshaher-Issuing-CA
- آموزش نصب Enterprise Ahvaz-Issuing-CA
- آموزش نصب و تنظیم OCSP سرور
- آموزش تست ساختار CA Hierarchy
- Cross-forest Certificate Enrollment چیست؟
- پیاده سازی Cross-forest Certificate Enrollment در ساختارهای Enterprise
- Certificate Enrollment Policy Web Service چیست؟
- Certificate Enrollment Policy Web Service چیست؟
- فرق بین Certification Authority Web Enrollment و Certificate Enrollment Web Services در چیست؟
- مزایای استفاده از Certificate Enrollment Web Services چیست؟
- پیش نیازهای Key Based Renewal در تنظیمات Certificate Template ها
- نیازمندی های Key Based Renewal در Certificate Enrollment Policy Service
- نیازمندی های Key Based Renewal در Certificate Enrollment Web Service /CES
- پیش نیازهای ارتباط کلاینتها با CESCEP و ارتباط CESCEP با AD DS and CA Server
- نیازمندی های Firewall
- CES/CEP در چه توپولوژی کاربرد دارد؟
از پیاده سازی آن گرفته تا فهمیدن و درک اصطلاحات آن. سعی می کنم در چند مقاله آتی تمام مباحث این سرویس را پوشش بدم و از دوستان و همکاران گرامی خواهشمندم اگر اشتباهی در انتقال این اطلاعات در این مقاله ها دیدین حتما تذکر بدن ( همه در زمینه IT شاگرد هستن و هیچ کس از هر نظر استاد و کامل نیست) در این مقاله قصد دارم اصطلاحاتی که در این سرویس استفاده می شود را توضیح بدم.
Certificate Authority Server
Certificate Authority یا CA که به معنی صدور گواهینامه می باشد مسئول ارائه یک هویت (گواهی) به کاربران ، کامپیوترها ، سرویس ها و سخت افزارهای شبکه می باشد. وقتی کاربری از CA سرور یک Certificate دریافت کند آن کاربر در شبکه یک کاربر مورد اطمینان و تعریف شده برای بقیه کاربران و Resourceهای شبکه می باشد. اگر بخواهیم یک مثال در دنیای واقعی بزنیم رفتار CA سرور مانند رفتار پلیس راهنمائی و رانندگی می باشد.
یعنی هر کس که می خواهد در کشور بصورت قانونی رانندگی کند موظف است یک گواهینامه رانندگی ( بستگی به نوع وسیله نقلیه که دارد که این مورد را می توانید برای User, Computer and... etc. در نظر گرفت) از پلیس راهنمائی رانندگی اخذ کند. الان اگر این فرد حقیقی این گواهی نامه را برای هر مامور پلیس راهنمائی رانندگی نشان دهد، آن مامور متوجه می شود این فرد مجاز است در سطح کشور رانندگی کند چون محل صدور گواهینامه رانندگی درکل کشور معتبر است. این مثال دقیقا رفتار CA سرور در شبکه و Authenticate کردن منابع شبکه بوسیله Certificate را نشان می دهد.
امضای دیجیتال (Digital Signature)
Digital Signature به معنای امضای دیجیتالی می باشد. اجازه بدید یک سوال بپرسم و این اصطلاح را توضیح دهیم.ماهیت و علت وجود امضای شما زیر چک بانکی چیست؟؟؟ چرا صاحب چک قبل از واگذار کردن آن به غیر آن را امضا می کند؟ درست است آن امضا صاحب خود را برای بقیه احراز هویت می کند (authentication) یعنی این امضا یک اعتماد و یک اعتبار برای صاحب چک ایجاد می کند.
و به همین علت است که برای متصدی بانک یک اعتماد ایجاد می شود که صاحب دست چک این چک را کشیده و او بدون هیچ معطلی آن چک را پاس می کند. Digital Signature یک نوع اعتبار و اعتماد برای اسناد، برنامه ها و سرویس های شبکه بوجود می آورد.Digital Signature باعث عدم جعل هویت ودستکاری منابع شبکه می شود. و این اطمینان را بوجود می آورد که همه سرویس ها و منابع احراز هویت شوند.
گواهینامه دیجیتال (Digital Certificate)
digital certificate به معنی گواهینامه دیجیتالی می باشد.digital certificate به مثابه یک پاسپورت برای یک کاربر یا کامپیوتر می باشد. که با استفاده از زیر ساخت کلید عمومی باعث امن کردن فعالیتهای شبکه در داخل و بیرون سازمان می شود. اگر کاربر یک Digital Certificate از CA دریافت کند آن کاربر برای همه منابع شبکه مورد اطمینان و تعریف شده ست.
اگر سرویسی به این کاربر شک کند که مورد تایید است یا خیر از او تقاضای تایید هویت می کند. که کاربر با ارائه گواهینامه دیجیتالی خود اطمینان آن سرویس را جلب می کند.نکته: گواهینامه دیجیتالی همون Certificateی هستش که کاربر از CA Server دریافت می کند که حاوی Digital Signatureآن کاربر می باشد. این جمله را به خاطر داشته باشید کلا Certificate بستگی به نوع آن دو کار مهم را انجام می دهد:
- احراز هویت Authentication
- امن کردن یا Secure کرده اطلاعات
رمزنگاری نامتقارن (Asymmetric Encryption)
Asymmetric Encryption به معنی رمزگذاری نامتقارن هستش. احتمالا تا حالا با واژه های مثل کلید خصوصی یا کلید عمومی برخورد داشتید! اساس کار کرد Certificate Authorityها استفاده از متد رمزگذاری نامتقارن هستش. وقتی درخواستی به CA سرور شود CA با استفاده از کلید خصوصی خود یک امضای دیجیتالی برای تقاضا کننده ایجاد می کند و آن را بوسیله کلید عمومی رمزگذاری می کند. این را گفتم که بدانید هر واکنش و هر گواهینامه دیجیتالی دارای یک کلید خصوصی و عمومی می باشد. به اصطلاح دیگر ماهیت استفاده از CA سرور ایجاد یک زیر ساخت برای این دو کلید می باشد.
Public Key Infrastructure (PKI)
public key infrastructure (PKI) به معنی زیر بنا یا زیر ساخت کلید عمومی می باشد.PKI مجموعه ای از نقش ها، سیاست ها و روش ها برای ایجاد، مدیریت، توزیع، ذخیره سازی، استفاده و ابطال گواهینامه دیجیتالی در ساختار می باشد.هدف از PKI تعریف یک محیط برای امن کردن فعالیتهای شبکه بوسیله کلید عمومی و خصوصی می باشد.برای اطلاع بیشتر در باره زیر ساخت PKI سلسله مقالات مهندس نصیری را مطالعه کنید.
Registration Authority
Registration Authority به معنی مراکز ثبت صدور گواهینامه می باشد.به مراکزی گفته می شود که درخواست کاربران برای گواهینامه دیجیتالی را برسی و تحویل CA می دهند و به CA سرور میگویند که گواهینامه دیجیتالی مناسب برای آن کاربر ارسال کند.
Certificate Revocation List یا CRL
Certificate Revocation List به معنی لیست گواهینامه های دیجیتالی باطل شده می باشد. هر Certificateی که توسط CA ایجاد می شود دارای یک مدت زمان خاصی می باشد (life time). قبل از اینکه این Certificate منقضی شود و اعتماد آن از بین برود باید دوباره یک Certificate جدید درخواست دهد یا آن Certificate را Renew کند.CA Server دارای لیستی از تمام Certificateهای می باشد که به زودی تاریخ آنها تمام می شود.
و آنها را در شبکه پخش میکند (در ساختار دومین) تا سرویس های شبکه از تاریخ انتقضای فلان Certificate اطلاع داشته باشند.وقتی یک Web Browser به یک https://Web Server وصل می شود از پروتکل TLS/SSL استفاده می کند، اولین مرحله تایید اعتبار، CA سروری می باشد که این Cert را به این Web Server ارائه داده است و در ادامه این پروسه لیست CRL آن CA سرور را چک می کند.
Certificate Enrollment
به نحوه اختصاص دادن یک Certificate به یک سرویس، کاربر یا کامپیوتر را Certificate Enrolment گفته می شود. این اختصاص دادن Certificate به عبارت دیگر نحوه درخواست Certificate توسط منابع شبکه را تعریف می کند.این پروسه به دو صورت انجام می شود بصورت دستی یا بصورت اتوماتیک که به آن Auto-Enrollment Certificate گفته می شود.
وقتی پروسه دستی انجام می شود که کاربر صریحا یک Certificate از CA سرور درخواست می کند. و پروسه اتوماتیک وقتی انجام می شود که یک سرویس یا Application بصورت اتوماتیک یک Certificate درخواست دهد که این درخواست و اعمال آن بصورت کاملا اتوماتیک صورت میگیرد و کل این پروسه در بک گراند اتفاق می افتد.
Certificate Life Cycle
Certificate Life Cycle به معنی چرخه عمر یک Certificate می باشد.تا حالا توجه کردید که چرا کارتهای بانکی ATM باید در یک فرجه زمانی خاص تعویض بشن؟؟؟ مثلا کارت ATMمن تا سال 98 فرصت دارد و بعد از سپری شدن این زمان باید کارتم را عوض کنم!!! کارت ATM یک گواهینامه دیجیتالی مخصوص هر فرد می باشد که از طرف CA بانک مرکزی یا بانک مربوطه صادر می شود. و به دلایل زیر باید آن کارت تعویض یا Renew شود:
- لو رفتن Private key سرور CA.
- Expire شدن Certificate کاربر.
- دست آوردن Private key کاربر توسط هکر.
- به پایان رسیدن طول عمر Certificate و ....
CLC یک Certificate در شبکه های کامپیوتری، دقیقا مانند رفتار کارتهای ATM می باشد.در هنگام نصب رول Active Directory Certificate Services در ویندوز سرور 2012 R2 شما باید یک مدت زمانی برای Expire شدن یا Renew شدن Private key خود CA Server تعیین کنید که بصورت پیش فرض 5 سال ست شده است.بحث CLC در Certificate Authority Server Microsoft شامل موارد زیر می باشد:
- CAs are installed and their certificates are issued.
- Certificates are issued by CAs
- Certificates are revoked (as necessary).
- Certificates are either renewed or allowed to expire.
- The CAs' certificates are renewed before they expire.
- The CA is revoked or retired.
به این هم توجه داشته باشید که طول عمر یک Certificate که از Enterprise CA صادر شده با Certificateی که بوسیله Stand-alone CA صادر شده فرق می کند. (این اصطلاحات را بعدا یاد خواهیم گرفت)
The certificate lifetimes of certificates that are issued by enterprise CAs are determined differently than the lifetime of certificates that are issued by stand-alone CAs. An enterprise CA issues certificates with lifetimes that are based on the certificate template for the requested certificate type. A stand-alone CA issues certificates with a lifetime that is determined by system registry settings for the CA.
Renew a Certificate
Renew a Certificate به معنی تازه سازی و ایجاد یک Certificate جدید می باشد.هر Certificate یک مدت زمان یا طول عمر دارد که بعد از سپری شدن آن مدت زمان آن Certificate قابل قبول نیست و نمی توان از آن استفاده کرد.منابع شبکه قابلیتی دارند که می توانند این Certificate را قبل از Expire شدن Renew کنند. در پروسه Renew شما می توانید از یک کلید جدید یا از همان کلید قبلی استفاده کنید که هر یک از این روش ها معایب و مزایای خود را دارند.
اگر به هر دلیلی Certificateی Renew نشد آن Certificate اکسپایرمی شود که CA سرور قبل از اکسپایر شدن آن یک هشدار به شما می دهد. اگر هیچ عکس العملی نشان ندادید آن Certificate باطل می شود. نکته: Certificate های که بوسیله کاربران درخواست داده شده اند توسط خود کاربران یا Administratorsها می توانند Renew شوند و Certificate های که به کامپیوترها و سرویس ها اعمال می شوند فقط توسط Administrators می توان آنها را مدیریت کرد.
Certificate Usage
میتوانم حدس بزنم که از اول مقاله تا الان این سوال ذهن شما رو مشغول کرده که گواهینامه دیجیتالی و Certificate Authority کار اصلی آن چیست؟ چرا باید از آن استفاده کنیم؟ به چه کارمون میاد؟؟؟ و سوالاتی از این قبیل!!!! همانطور که قبلا گفتم کار اصلی سرویس CA دو چیز است، یکی احراز هویت و دومی امن کردن ارتباطات هستش. بعضی از برنامه ها، سرویس ها و دیوایس ها برای کارکرد آنها حتما باید برای آنها یک Certificate درخواست بدید
مثل Exchange Server. یا بعضی از آنها به علت محرمانگی اطلاعاتی که ارائه میدن حتما باید از گواهینامه دیجیتالی برای آنها استفاده کنیم مانند IIS, Work Folders یا بعضی از سرویس ها برای احراز هویت اشخاص از آن استفاده می کنند مانند IPsec. همچنین سرویس network access protection یکی از پیش نیازهای آن استفاده از CA سرور می باشد. یک مثال دیگه می زنم که بعضی از کاربران شاید با آن رو به رو شده باشند:
Signed Drivers!!!! بیشتر درایورهای که بر روی Windows نصب می شوند باید Signed شده باشند. وگرنه اجازه نصب نمیده. جالبه بدونید این روش از مکانیزم Certificates for Code Signing استفاده می کند. استفاده های که از Certificate می شود را بطور اختصار می توانید برای Applicationها در جدول زیر مشاهده کنید:
دوستان عزیز توصیه اکید می کنم لینک زیر را مطالعه کنید واقعا دید بهتری به شما نسبت به زیر ساخت کلید عمومی می دهد:
https://technet.microsoft.com/en-us/library/cc700805.aspx
Certificate Signing Request
certificate signing request یا CSR به فرایندی گفته می شود که یک برنامه پیامی به یک CA سرور ارسال می کند و CA سرور طبق همین پیام یک Certificate برای او ایجاد و ارسال می کند. این فرایند را می توانید در این مقاله که برای Exchange Server نوشته شده مطالعه کنید.
Certification Authority Hierarchies
Certification Authority Hierarchies یا مراکز صدور گواهینامه سلسله مراتبی.در سازمانهای بسیار بزرگ که دارای چندین هزار کاربر و کامپیوتر و سرویس هستن برای مدیریت و پایداری زیر ساخت کلید عمومی از چندین CA Server استفاده می کنند. نحوه اضافه کردن CA در ساختار و پیکربندی آن مانند ساختار سلسله مراتبی دومین هستش، همانطور که در دومین شما Parent and Child دارید در زیر ساخت کلید عمومی همین ساختار (با نام های متفاوت) پیاده سازی می شود.ساختاری که چندین CA سرور داشته باشد را certification hierarchy می گویند. به عکس زیر توجه کنید
به اولین CA سروری که در ساختار ایجاد می شود Root CA گفته می شود و بدیهی است برای ایجاد یک ساختار سلسله مراتبی ایجاد یک Root CA الزامی می باشد. به CA سرورهای Child به اصطلاح Subordinate CA گفته می شود که بوسیله Root CA تایید و مجاز به فعالیت در شبکه هستند که این تایید را بوسیله صدور یک Certificate به Subordinate CA ایجاد می شود.در عکس بالا شما دو اصطلاح دیگه هم می بینید یکی Intermediate CA و Issuing CA.
- به CA سرورهای Child به اصطلاح Subordinate CA یا Intermediate CA گفته می شود.
- به CA سرورهای که به یوزر، کامپیوتر یا سرویس Certificate صادر می کنند و با منابع شبکه در تعامل هستند را Issuing CA می گویند.
نکته:CA سرورهای Child می توانند در مد Intermediate CA یا Issuing CA فعالیت کنند.
نکته: Intermediate CA ها فقط با CA های زیر دست خود در تعامل می باشد.
شما در ایجاد یک ساختار hierarchy محدودیتی ندارید ولی بیشتر سازمانهای بزرگ از همین سه لایه استفاده می کنند.
Certification Path
با ایجاد ساختار certification hierarchy شما یک ارتباط زنجیره ای از Issuing CA تا Root CA تشکیل می دهید. به این مسیر زنجیره ای Certification Path گفته می شود.
در تصویر بالا ما یک EFS Recovery Agent داریم که از Issuing CA صادر شده که این CA سرور یک Certificate Path به Root CA دارد. دوستان به این نکته توجه کنید در تصویر بالا اگر Root CA 2 در Trusted Root Certification Authorities کلاینتها ثبت شده باشد
Certificate Path بالا مورد اعتماد است. الان اگر هر Certificateی از هر Issuing CA صادر شود مورد اطمینان است. شاید الان سوال براتون پیش بیاد که من از Issuing CA دارم Cert دریافت می کنم، چه ربطی به Root CA دار؟!!! جواب سادس: هر Certificateی از هر CAی دریافت کنید آن Certificate شما را به Parent CA لینک می کند تا به Root CA برسید.
Certificate Path Validation
قبل از اینکه یک Certificate Path مورد اطمینان قرار بگیرد باید توسط Microsoft CryptoAPI تایید شود، که اینکار را بوسیله چک کردن تمام Certificate های CA سرورها یک Certificate Path انجام می دهد. هر Certificate دارای اطلاعاتی از Parent CA خود می باشد.نکته: CryptoAPI سرتیفیکت های دریافتی از Parent CA را با سرتیفیکتهای که در Intermediate Certification Authorities store or the Trusted Root Certification Authorities stores ذخیره شده اند مقایسه می کند.
حالا اگر CryptoAPI سرتیفیکیتی در این دو Store پیدا نکند یا با هم همخوانی نداشته باشند Certificate Path مورد تایید نیست و کلاینتها نمی توانند به آن اطیمینان کنند.
- نکته: اگر CA Certificateی Expire شود Certificate Path همچنان مورد تایید است و این موضوع ربطی به Expire شدن Certificateها ندارد.
فکر کنم تا حدودی بیشتر اصطلاحات را توضیح دادم و بقیه اصطلاحات مانند Enterprise CA and Stand-alone CA و غیره را در آموزش های بعدی توضیح خواهم داد.
در این جلسه قصد دارم ADCS را نصب و اجزای آن را توضیح دهم.قبل از نصب و راه اندازی یک زیر ساخت کلید عمومی لازم می دونم که بعضی از اصطلاحات و انواع آنها را دوباره توضیح و اگر امکانش باشه آنها را بیشتر باز کنم.
معرفی انواع Certificate Authorities یا PKI Server
همانطور که قبلا گفتم CA برای امن کردن بعضی از منابع شبکه و همچنین احراز هویت آنها ایجاد شده است. CA Server درخواستهای ارسالی از سمت منابع شبکه را تایید می کند و آنها را طبق سیاستهای برسی می کند و بعد از آن توسط کلید خصوصی خود (CA) امضای دیجیتالی خود را بر روی Certificate اعمال می کند و آنها را برای منابع شبکه صادر می کند. CA Server همچنان مسئول باطل کردن Certificateها و و انتشار لیست آنها می باشد. CRL : دوستان از این به بعد وقتی خواستیم از منابع شبکه مانند کاربران، کامپیوترها یا سرویس های که در تعامل با CA Server هستن نام ببریم از واژه Subject استفاده می کنیم.
CAها می تواند خارج از سازمان هم به هر Subjectی سرویس دهد مانند Verisign و غیره یا می توان یک CA در یک Forest دیگر به آن دسترسی داشت و از خدمات آن استفاده کرد. همچنین در ساختارهای سلسله مراتبی هر CA سرور یک گواهینامه دیجیتالی یا یک Certificate دارد که هویت خود را برای بقیه مشخص و احراز هویت می کند و این Certificate از Parent CA برای او ارسال می شود. ما هنگام نصب این سرویس اصطلاحتی داریم که قبلا آنها را در آموزش قبلی توضیح دادم به نام Root and subordinate!!!!!
یک Root CA که گاهی وقتها به آن Root Authority می گویند یکی از مهمترین و و حساس ترین سرور در ساختار PKI می باشد که بیشترین اعتماد در کل ساختار دارد. اگر این سرور در معرض خطر قرار گیرد یا یک Certificate به یک CA قلابی یا غیر مجاز ارسال کند کل ساختار PKI اسیب پذیر می شود. در بیشتر سازمانها (مخصوصا اینجا، ایران) از Root CA بعنوان یک Issuing CA استفاده می کنند. Subordinate CA یک CA سروی می باشد که زیر مجموعه Root CA قرار می گیرد که بوسیله Root CA تصدیق شده و مجاز به فعالیت در شبکه می شود. Subordinate CA دقیقا مانند Child Domain در ساختار دومین می باشد. منظور از ایجاد Subordinate CA در ساختار، پایداری و مدیریت ساختار PKI در سازمانهای بزرگ می باشد.
Policy modules ها
شاید برای شما جای سوال باشه که Policy Modules چی هست؟ به طور خلاصه به رفتار CA Server هنگام دریافت یک درخواست از Subjectی را Policy Modules می گویند. که دو Policy Modules داریم:
Enterprise certification authorities:
این نوع CA دارای خصوصیات زیر می باشد:
- برای استفاده از Enterprise certification authorities نیاز به ساختار دومین و Active Directory دارید.
- وقتی Enterprise CA را نصب می کنید Enterprise CA از Group Policy استفاده می کند و Certificate خود را در Trusted Root Certification Authorities certificate کلاینتها، یوزرها و سرویس ها ذخیره می کند. همانطور که می دانید اگر Root CA در این استورج ذخیره شود آن CA برای آن Subject قابل اعتماد است.
- وقتی شما Enterprise CA را نصب میکنید این سرور بصورت اتوماتیک خود را عضو گروه Cert Publishers می کند و اعضای این گروه می توانند Certificateها را در یک دومین انتشاریا Publish کند. مثالی که در این مورد می توانم بزنم انتشار لیست CRL می باشد.
Enterprise CA از انواع Certificate ها استفاده می کند و اساس کار این Certificate ها استفاده از Certificate Template ها می باشد. شرایط زیر وقتی صدق می کند که از Certificate Template استفاده شود:
- وقتی Certificate Enrollment توسط Subjectی انجام شود Enterprise CA بصورت Force هویت و credential آن را چک می کند. هر Certificate Template در ساختار Active Directory دارای یک Permission می باشد و در نتیجه Subjectی می تواند این Template را Enroll کند که مجوز آن را داشته باشد
- certificate subject name بصورت اتوماتیک بر اساس اطلاعاتی که در Active Directory ذخیره شده تولید می شود یا با استفاده از اطلاعاتی که در CSR می باشد می توان آن را ایجاد کرد. certificate subject name را بعدا توضیح خواهم داد.
Stand-alone certification authorities:
این نوع CA دارای مشخصات زیر می باشد:
- بر خلاف Enterprise CA این نوع نیازی به Active Directory و ساختار دومین ندارد. در درجه اول هدف از Stand-Alone CA ایجاد یک Trusted offline CA در یک ساختار PKI سلسله مراتبی می باشد.
- وقتی درخواستی حواله stand-alone CA می کنید باید تمام اطلاعات و هویت خود را برای آن فراهم کنید همچنین نوع Certificate چون این نوع CA مثل Enterprise CA نیست که اطلاعات Subject ها را از Active Directory استخراج کند.
- بصورت پیش فرض هر درخواستی که به سمت Stand-alone CA فرستاده میشه بصورت Pending یا انتظار باقی می ماند و تا Admin آن را تایید یا Issue نکند برای آن Subject صادر نمی شود. علت این رفتار هم عدم توانائی Stand-alone CA در Authenticate کردن Subjectها می باشد و این مسئولیت را بر عهده Admin می اندازد.
- از Certificate Template استفاده نمی کند. یعنی شما باید نوع Certificate را برای Stand-alone CA مشخص کنید.
- Admin باید بصورت دستی Stand-alone CA's Certificate را در Trusted root کاربران deploy کند.
بر خلاف اسم گذاری Stand-alone CA می توان این نوع CA را در ساختار دومین نصب و راه اندازی کرد. وقتی شما اینکار را انجام دهید Stand-alone CA's Certificate بصورت اتوماتیک در Trusted Root سابجکتهای ذخیره می شود. و بیتشر (نه همه) درخواستهای Subjectها بصورت اتوماتیک Issue می شود. و بعضی از User Certificate ها و CRL ها بصورت اتوماتیک در ساختار دومین Publish می شوند.
جدول زیر به شما کمک می کنه تفاوت این دو Policy Modules را بهتر متوجه شوید:
قبل از نصب CA Server شما باید به این سوالات جواب بدید، اجازه بدید عامیانه سوال کنم بهتر قابل درکه:
- این سرویس چی بهم میده؟
- اصن چرا باید این سرویس رو نصب کنم؟
- وقتی این سرویس رو نصب کردم قراره اتفاقی توی سازمان بیوفته؟
کلی بحث و نکته را توی این سه سوال خلاصه کردم. الان برید سرچ و تحقیق کنید که مزیت استفاده از CA یا بهتر بگم ساختار PKI چیه؟
قبل از اینکه شروع به نصب کنیم باید نیازهای خودتون را مشخص کنید که فقط یک Root CA نیاز دارید که کار همان Issue CA را انجام دهد؟ یا یک ساختار سلسله مراتبی؟
اگر سطح نیاز سازمان یک ساختار سلسله مراتبی را می طلبه باید مشخص کنید که مایلید از روش Trusted offline CA استفاده کنید یا خیر؟
برای اطلاع بیشتر درباره Trusted offline CA و همچنین راه اندازی چنین ساختاری سلسله مقالات مهندس نصیری را مطالعه کنید.
چون ما در ابتدای یاد گرفتن این سرویس هستیم من یک Enterprise Certificate Authority نصب می کنم.
قبل از نصب کردن باید چک کنیم چه پیش نیاز های برای نصب و راه اندازی PKI نیاز می باشد:
- برای نصب Enterprise CA نیاز به ساختار دومین دارید.
- سروری که روی آن Enterprise CA نصب میکنید باید Joint to Domain باشد.
- کاربری که مسئول این پروسه می باشد باید عضو گروه Enterprise admin باشد.
به این هم توجه داشته باشید که بعد از نصب CA Server شما قادر به تعقیر اسم CA Server نیستید ونمی توانید سرور را عضو یا خارج از دومین کنید یا CA Server را تبدیل به DC کنید.
برای نصب Enterprise CA سرور کنسول Server Manager را اجرا کنید وگذینه Active Directory Certificate Service را تیک بزنید
Next کنید و در پنجره زیر
گذینه مشخص را انتخاب کنید. نگران نباشید بقیه گذینه ها را توضیح میدم. در اخر Install کنید. بعد از پایان نصب لینک زیر را کلیک کنید:
در صفحه بالا کاملا توضیح داده برای چه کارهای نیاز به چه credential های می باشد. Credential مناسب را انتخاب و Next کنید
چه سرویس های را می خواهید در این Wizard تنظیم کنید؟ باید در بالا مشخص کنید. که من فقط Certificate Authority را نصب کردم و فقط می خوام آن را تنظیم کنم.
گذینه های بالا را مفصل توضیح دادم. بنا به شرایط سازمان و نیازهای آن یکی از گذینه های بالا را انتخاب کنید.
گذینه های بالا را نیز مفصل توضیح دادم. چون اولین CA در ساختار می باشد و هیچ Trusted offline CA نداریم گذینه Root CA را انتخاب می کنیم.
برای اینکه CA Server بتواند به Subjectها Certificate صادر کند نیاز به Private key دارد. اگر اولین سرور شما در ساختار می باشد گذینه مشخص شده را انتخاب کنید وگرنه گذینه های دیگر را انتخاب و Private key را به CA معرفی کنید.
کلید خصوصی یا Private key هر CA Server هویت آن CA محسوب می شود. وقتی CA بخواهد Certificateی را به Subjectی صادر کند از کلید خصوصی خود استفاده میکند. بصورت پیش فرض این کلید بر روی هارد دیسک سرور CA ذخیره می شود. بیشتر سازمانها برای امن کردن کلید خصوص CA سرورهای خود از سخت افزاری به نام Hardware Security Module یا به اختصار HSM استفاده می کنند. شما در قسمت Select a Cryptographic Provider میتوانید نحوه ذخیره سازی این کلیدها را مشخص کنید. در قسمت key length هم باید طول کلید های ایجاد شده را مشخص کنید.
- نکته: اگر از RSA در قسمت SCP استفاه کنید نباید طول کلید بیشتر از 2048 باشد و نباید کمتر از 1024 باشد. در غیر اینصورت CA service استارت نمی شود
When using an RSA certificate for a CA, ensure that the key length is at least 2048 bits. You must not attempt to use an RSA certificate below 1024 bits for the CA. The CA service (certsvc) will not start if an RSA key of less than 1024 bits is installed.
به این نکته هم توجه کنید که بعضی از برنامه ها از طول کلید مشخصی استفاده می کنند یا بعضی از آنها بالاتر از 2048 را ساپورت نمی کنند.
به این هم توجه کنید که هر چقدر طول کلید بیشتر باشد پردازش آن زیاد و زمان بر است. در کادر پایین می توانید نوع رمزگذاری کلیدها را مشخص کنید. این نوع رمزگذاری بر اساس نوع تنظیمات SCP متغیر می باشد. در آخر گذینه Allow administrator inter…. را وقتی تیک بزنید که از HSM استفاده می کنید. شما با تیک زدن این گذینه در مواقعی که CA Server قصد دارد به کلید خصوصی دسترسی پیدا کند Administrator باید پسورد خود را وارد کند.
یک اسم برای این CA Server بنویسید.
- نکته: به علت اینکه این اسم در هر Certificateی می باشد که صادر می شود از نوشتن FQDN سرور خودداری کنید. همچنین این اسم باید در ساختار Unique باشد.
به قول کمپانی مایکروسافت بعضی از روترها به علت فرمت بد نامگذاری CA Server نمی توانند از قابلیت Network Device Enrollment Service استفاده کنند و در نتیجه نمی توانند Certificate را درخواست بدهند.
certain types of routers will not be able to use the Network Device Enrollment Service to enroll for certificates if the CA name contains special characters such as an underscore.
نکته بسیار مهم: به علت بعضی از مسائلی که باعث مشکلات در ساختار می شود از گذاشتن فاصله در اسم گذاری CA Server شدیدا خود داری کنید.
مدت زمان اعتبار کلید خصوصی این CA Server را باید مشخص کنید. در پنجره بالا بصورت پیش فرض بر روی 5 سال ست شده است. اگر این مدت زمان سپرسی شود این کلید خصوصی اعتباری ندارد و با Renew شود. وقتی ادمین تعیین می کند که کلید خصوصی یک CA Server 5 سال اعتبار دارد این CA سرور Certificate های را به Subject ها صادر می کند که کمتر از 5 سال باشد.
مثال: شما نمی توانید Certificate را با طول عمر 10 سال به Subjectی صادر کنید در حالی که طول عمر Certificate سرور CA 5 سال باشد. فرض کنید 3 سال از این 5 سال گذشته باشد CA Server نمی تواند Certificate با طول عمر 4 سال Issue کند و باید CA's Certificate را Renew کرد.
نکته: وقتی طول عمر کلید خصوصی Root CA بر روی 5 سال ست شده باشد شما نمی توانید طول عمر کلید خصوصی Intermediate CA را بیشتر از 5 سال ست کنید. این مسئله نیز برای Intermediate CA and Issuing CA صدق می کند.
سوال؟؟؟
وقتی کلید خصوصی CA Server اکسپایر شود (طول عمر آن سپری شود و Admin آن را Renew نکند) مسئله Certificate های که صادر کرده چی میشه؟؟؟؟؟
همه Certificateهای صادر شده اکسپایر می شوند.
. Certificate Services enforces a rule that a CA never issues a certificate to be valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire.
توصیه اکید می کنم که لینک زیر را بخوانید. حتما بخوانید:
https://technet.microsoft.com/en-us/library/cc740209(WS.10).aspx
واضحه نیازی به توضیح نداره
اولین CA Server در ساختار ایجاد شد.
الان Certificate این CA Server بصورت اتوماتیک در Trust Root همه کلاینتها با اولین ابدیت کردن Group Policy ذخیره می شود.
خب!!!
وقتی شما کنسول CA Server را اجرا میکنید گذینه های زیر را می بینید:
- در این کانتینر Certificateهای باطل شده را می بینید.
- Certificateهای صادر شده به Subjectها. همانطور که در بالا می بیند یک Certificate template بصورت اتوماتیک به DC صادر شده.
- اگر Certificateی نیاز به تایید Admin داشته باشد اینجا لیست می شود.
- Certificateهای که به هر دلیلی fail شدن در اینجا ذخیره می شوند.
- Certificate Template را در این کانتینر می توانید ببنید.
بعد از نصب CA Server یک سری تنظیمات مربوط به CRL and AIA می باشد که قبل از فعالیت CA و صادر کردن هر گونه Certificateی، شما باید آنها را کانفیگ کنید. این تنظیمات را در جلسه بعدی توضیح خواهم داد.
بعد از نصب اولین CA در ساختار شما باید Authority Information Access (AIA) and CRL distribution point (CDP) extensions را قبل از هر گونه Certificate Issue تنظیم کنید.در تعریف AIA باید بگم، Subjectها توسط AIA می توانند به CA Server دسترسی داشته باشند و همچنین CA's Certificate و بقیه Certificate را تایید اعتبار و برسی کنند. CDP به Subject ها کمک می کند که به لیست CRL دسترسی داشته باشند و از اخرین Certificateهای باطل شده اطلاع یابند. نکته: اطلاعات CDP and AIA بر روی همه Certificateهای که صادر می شوند اعمال می شود.و جزئی از اطلاعات همراه آن Certificate محسوب می شوند.
گواهینامه های باطل شده (Certificate Revocation List)
شاید برای خیلیا هنوز جا نیفتاده که لیست Certificateهای باطل شده چی هست و چرا باید در کل ساختار منتشر یا پخش شود؟ دوستان هر Certificateی که صادر شود دارای یک طول عمر Life time می باشد و با تمام شدن این Life time آن Certificate دیگر اعتبار ندارد و باطل می شود. در شرایطی که کلید خصوصی آن Certificate توسط هکری یا کسی کشف شود یا در هر موقعیت خطرناک دیگری ادمین می تواند قبل از اتمام life time سرتیفیکت را باطل کند.
حالا سوال اصلی اینجاست که چرا باید Certificateها طول عمر داشته باشند؟
به خاطر دلایل زیر:
- کشف کردن کلید خصوصی Certificate توسط هکر.
- لو رفتن کلید خصوصی CA Server (مصیبت بزرگیه برید از بانک ملی ایران بپرسید به خاطر این اتفاق چه پوستی از آنها کنده شد. (این قضیه متعلق به خیلی وقت پیشه))
- خطراتی کلید خصوصی Certificate یا CA's Certificate را تهدید می کند.
- CA Server سرتیفیکتی را به یک CA Server تقلبی ارسال کند.
- ادمین Certificateی را صادر می کند ولی بعدا متوجه می شود که این Certificate مناسب آن کار نیست.
- Subject برای ادامه کار خود نیاز به Certificate ندارد.
و دلایل دیگر .....
نکته: حتی اگر شرایط بالا اتفاق نیفتد باز هم Certificateها نیاز به طول عمر دارند و بعد از سپری شدن طول عمر آنها باطل می شوند و باید آنها را renew کرد.
خب شما در نظر بگیرید در چنین شرایطی Certificate یکی از سرویسهای مهم بنا به دلایلی باطل شود ... الان اگر Subjectی بدون اطلاع از باطل شدن این Certificate از آن استفاده کند چه مشکلی پیش می آید؟؟؟؟ توانائی استفاده از آن سرویس را ندارد . اگر آن سرویس یک VPN Server باشد کاربران نمی توانند به VPN Server وصل شوند....پس برای حل این مشکل باید یک مکانیزمی وجود داشته باشد که وقتی Certificate باطل شود توی شبکه جار بزند که اقا آن Certificate باطل شد جان عزیزتون از آن استفاده نکنید D: پس در نتیجه علت بوجود آمدن لیست سرتیفیکت های باطل شده یا CRL به همین خاطر می باشد. وقتی این لیست در AD منتشر شد کلاینتها این لیست را در خود Cache میکنند تا دم به دقیقه دنبال این لیست نباشند. برای دیدن این لیست بر روی کلاینتها دستور زیر را اجرا کنید:
certutil -urlcache CRL
برای اینکه این لیست از اهمیت زیادی برخورداره در تنظیمات CA Server قسمتی برای تنظیم دستیابی به این لیست وجود دارد.
دوباره عرض می کنم که: CDP extension به کلاینتها می گوید کجا بتوانند به لیست CRL دسترسی داشته باشند.همانطور که در تصویر بالا مشاهده می کنید چندین مکان یا بهتره بگم مخزن (بنا به تعبیر مایکروسافت) برای دسترسی به این لیست وجود دارد. وقتی کلاینتی نیاز به این لیست داشته باشد به این مخازن رجوع می کند و به ترتیب از اولین مخزن تا اخرین مخزن را به دنبال لیست CRL می گردد.
ما کلا دو لیست CRL داریم:
Base CRLs:
Base CRL لیستی از Certificate های هستن که Expire نشدن ولی بنا به دلایلی ادمین آنها را Revoke یا باطل کرده است.
Delta CRLs:
لیستی از Certificate های باطل شده می باشد که بعد از اخرین انتشار یا Publish لیست CRL ایجاد شده اند. در بعضی از داکیومنتهای مایکروسافت به این لیست، آخرین Certificateهای باطل شده اطلاق میشه. یکی دیگر از مزیتهای این نوع لیست انتشار به روزترین Certificateهای باطل شده می باشد و به علت کم حجم بودن این لیست سرعت دستیابی به آن زیاد است.اگر کلاینتی از دو ایتم بالا استفاده کند، برای تشخیص باطل بودن Certificate باید هر لیست بالا را دانلود کند.
خوبه یه نگاهی به لیست CRL بندازیم:
Version: V2 means version 2 of the CRL Profile which is defined in RFC 5280
Issuer: The CA that issued the CRL
Effective Date: The date and time that the CRL first becomes valid
Next Update: The date and time that the CRL expires
Signature Algorithm: The Public Key Cryptography Algorithem and the Hashing Algorithem that were used to sign the CRL
Signature hash algorithm: The hashing algorithm used in to sign the CRL
Authority Key Identifier: This field gives additional information used to identify the issuer of the CRL
CA Version: The bersion number of the CA certificate
CRL Number: A unique identifier for the CRL
Next CRL Publish: The date and time that the next CRL will be published
Freshest CRL: If you are using Delta CRLs this field will show where the Delta CRL can be retrieved, typically this is the same location as the CRL.
با تمام جرات می تونم بگم مهمترین تنظیماتی که در زیر ساخت کلید عمومی وجود دارد تنظیمات همین CDP Extension می باشد. اگر Application نتواند لیست CRL را بدست آورد نمی تواند از خدمات CA Server سرور استفاده کند.ما در تنظیمات CDP Extension دو مخزن مهم برای انتشار CRL داریم:
LDAP:
لیست CRL در Configuration Partition اکتیو دایرکتوری ذخیره می شود و بوسیله Replication در کل Forest منتشر می شود. یکی از مزیتهای آن دسترسی آسان به این لیست می باشد. و معایب آن عدم دسترسی کلاینتهای غیر ویندوزی می باشد و همچنین کاربران اینترنت توانائی دسترسی به این لیست را ندارند.
HTTP:
لیست CRL بر روی یک وب سرور قرار می گیرد. مزیتهای این روش اینست که کاربران از هر جائی می توانند به این لیست دسترسی داشته باشند ومزیت دوم، برای بدست آوردن این لیست نیازی به Authenticate نیست.
علاوه بر مخازن بالا میتوان مخازن دیگری هم ایجاد کرد مانند File یا Share Folder و غیره
خب!!!
شما می توانید توسط اینترفیس های زیر CDP and AIA را تنظیم کنید:
- Certification Authority interface
- Windows PowerShell
- certutil command
ما از محیط گرافیکی استفاده می کنیم.
همانطور که در بالا می بینید بصورت پیش فرض دو مخزن بصورت اتوماتیک برای کاربران دومین ایجاد شده اند. یکی Share Folder و دیگری LDAP. گذینه های زیر هم نوع Publish کردن لیست CRL می باشد که واضح هستند و نیازی به توضیح خاصی ندارند.انتخاب این گذینه ها برای هر یک از مخازن بصورت استاندارد توسط مایکروسافت تعیین شده (بدین معنی نیست که شما حتما باید مطابق شکل زیر ست کنید ولی یک استانداره)
در بعضی از سناریوها لازم میشه که شما مخزن HTTP را برای کاربران بیرون از سازمان مانند کاربران Forest های دیگر یا کاربران اینترنت تنظیم کنید. برای اینکار شما نیاز به یک Web Server دارید که تنظیمات زیر بر روی آن انجام شود.
قبل از اینکار نکات زیر را راعایت کنید:
- حتما از DNS Name استفاده کنید نه اسم کوتاه یا NetBIOS
- اسم سرور NetBIOS نباید شامل FQDN باشد.
- سعی کنید Web Server بر روی سروری غیر از سرور CA Server باشد.
- اگر قرار است این وب سرور به کاربران بیرون از سازمان یا کاربران اینترنت سرویس دهد باید A Record آن را در DNSهای خارجی سازمان ایجاد کنید و این سرور را Publish کنید.
ناگفته نمونه اگر CA Server را فقط برای کاربران داخلی سازمان ایجاد کردید نیازی به انجام دادن مراحل زیر نیست.
نکته: در تنظیمات زیر از اسامی و FQDNهای دلخواه یا سازمانی خود استفاده کنید.
و اما تنظیمات:
یک پوشه به نام PKI در درایو C:\ وب سرور ایجاد کنید و آن را Share کنید و به گروه Cert Publishers مجوز Read/Write دهید.
در آموزش قبلی توضیح دادم گروه Cert Publishers چی هست.
کنسول IIS را اجرا کنید و یک Virtual Directory ایجاد کنید به نام PKI و ادرس پوشه PKI را معرفی کنید.
در آخر OK کنید.
الان باید به گروه های ANONYMOUS LOGON; Everyone مجوز لازم را بدیم برای اینکار:
بعد از ایجاد تنظیمات بالا، در همان صفحه وارد تنظیمات Request Filtering شوید و گذینه زیر را انتخاب کنید:
و گذینه زیر را تیک بزنید
و بعد از آن سرویس IIS را ریستارت کنید.
قدم بعدی باید CA's Certificate و لیست CRL را به این Virtual Directory منتقل کنیم. پس دستورات زیر را در Power Shell اجرا می کنیم:
نکته: این دستورات را در CA Server اجرا کنید.
certutil –crl copy C:\Windows\system32\certsrv\certenroll\*.crt \\web-srv\pki copy C:\Windows\system32\certsrv\certenroll\*.crl \\web-srv\pki Restart-Service certsvc
قدم بعدی ایجاد مخزن HTTP بر روی CA Server میباشد. برای اینکار وارد تنظیمات CDP Extension شوید و HTTP را پاک کنید و بعد از آن دکمه ADD را کلیک کنید و عبارت زیر را در قسمت Location کپی کنید:
http://pki.mycity.local/pki/.crl
و گذینه های زیر را انتخاب کنید:
- Include in CRLs. Clients use this to find the Delta CRL locations
- Include in the CDP extension of issued certificates
بعد از آن سرویس CA Server را ریستارت کنید.برای دیدن نتیجه کار در CA Server دستور pkiview.msc را در منوی Run اجرا کنید
مشاهده می کنید که CDP Extension با موفقیت تنظیم شد است. و کلاینتها علاوه بر مخازن دیگر میتوانند از مخزن HTTP استفاده کنند.
Authority Information Access (AIA) چیست؟
الان نوبت به تنظیمات AIA می رسد.AIA بوسیله Applicationها و Subjectهای شبکه برای دستیابی به CA Server و تایید اعتبار آن مورد استفاده قرار می گیرد. این تنظیمات مانند تنظیمات CDP Extension دارای چندین مخزن می باشد:
که بصورت پیش فرض مخازن Share Folder و LDAP برای کاربران داخلی ایجاد شده. و ما قصد داریم مخزن HTTP را هم برای کاربران داخلی و خارجی تنظیم کنیم. برای اینکار مخزن پیش فرض HTTP را پاک کنید و دکمه Add را کلیک کنید. و عبارت زیر را در قسمت Location کپی کنید:
http://pki.mycity.local/pki/_.crt
و گذینه Include in the AIA of issued certificates. را انتخاب کنید.
الان شاید از خودتون بپرسید ما از همان محتوای Virtual Directory تنظیمات CDP استفاده می کنیم!!! قراره اونجا Certificateی کپی کنیم؟؟؟ باید عرض کنم آره ما در تنظیمات قبلی مربوط به CDP در Virtual Directory علاوه بر لیست های CRL سرتیفیکت Certificate CA را هم کپی کردیم. که Subjectها برای دسترسی به CA Server و تایید اعتبار آن استفاده می کنند. از این به بعد Subject ها علاوه بر LDAP, Share Folder مخزن HTTP را نیز دارند که می توانند از آن استفاده کنند.
الان اگر بریم چک کنیم تنظیمات به درستی اعمال شده!!!! می بینیم جلوی همه مخازن در قسمت Status واژه OK نوشته است و به معنی درستی و صحت تنظیمات می باشد.
در آخر باید به این نکته اشاره کنم که کلاینتها برای دسترسی به CDP and AIA بصورت Orderی استفاده می کنند و از هر مخزنی که این اطلاعات را بدست آورند متوقف می شوند و از مخازن دیگر استفاده نمی کنند. کلاینتها برای استفاده از این اطلاعات در هر بازه زمانی 15 ثانیه سعی خواهند کرد به اطلاعات دست یابند و اگر نتوانند در این 15 ثانیه اطلاعاتی بدست آورند درخواست آنها Time Out می شود پس درنتیجه مخازن بلا استفاده و تنظیم نشده را پاک کنید. در جلسه بعدی یکی از کامپوننتهای مهم CA Server به نام Online Responder که مباحث وتنظیمات تکمیلی این جلسه می باشد را آموزش خواهم داد. دوستان بعد از تمام شدن مباحث Certificate Revocation و بقیه مباحث شروع به آموزش Certificate Template و Certificate Enrollment که پایه استفاده از این سرویس می باشد را شروع میکنیم. دندون رو جگر بذارید این مباحث سنگین و حیاتی رو تموم کنیم D:
در این جلسه قصد دارم قابلیت جدیدی که در Windows Server 2008 به نام Online Responder معرفی شده را آموزش دهم. با ما باشید.Subjectها قبل از استفاده از Certificate برای احراز هویت و رمزگذاری وضعیت آنها آن Certificate ها را برسی و اعتبار سنجی می کنند. Subjectها در پروسه اعتبار سنجی از دو پارامتر مهم استفاده می کنند:
Time:
قبل از اینکه Subjectی از Certificateی استفاده کند چک می کند طول عمر آن Certificate به پایا ن نرسیده و Expire نشده است. اگر Certificateی به هر دلیلی طول عمر آن سپری شده باشد آن Certificate بلا استفاده می باشد.
Revocation Status:
بعد از چک کردن طول عمر Certificate توسط Subjectها آن Certificate را از لحاظ باطل بودن یا Revocation چک می کنند و اگر آن Certificate این دو پارامتر مهم را پاس کند Subject از آن Certificate استفاده می کند.
چک کردن Certificate ها از لحاظ باطل بودن توسط Subjectها می تواند شامل چندین روش باشد که ابتدائی ترین روش لیست CRL and Delta CRL می باشد و علاوه بر این دو روش، روش جدیدی به نام Online Certificate Status Protocol یا OCSP معرفی شده است.سیستم عاملهای قبل از Windows Vista فقط از روش CRL استفاده می کردند ولی با امدن Windows Server 2008 علاوه بر لیست CRL از OCSP هم استفاده خواهد شد.در پروسه ارزیابی یا اعتبار سنجی Certificateها اعتبار سنجی شامل کل Certificate Path می باشد. و همراه ارزیابی سرتیفیکت Parent CA آن Certificate هم ارزیابی می شود و این ارزیابی تا خود Root CA ادامه دارد.جهت اطلاع شما دوستان Subjectها برای دسترسی به Parent CA و اعتبار سنجی آنها از دو پارامتر استفاده می کنند:
- Local certificate store
- Authority information access (AIA)
اگر به هر دلیلی این اعتبار سنجی با موفقیت انجام نشود آن Subject قادر به استفاده از آن Certificate نخواهد بود.
لیست CRL
لیست CRL یک فایل می باشد که توسط CA Server ایجاد می شود و شامل تمام Certificateهای باطل شده است. این فایل علاوه بر Certificateها باطل شده دارای Serial numbers می باشد که متعلق به Certificateها است. علاوه بر اینها دارای زمان و دلیل باطل شدن Certificate نیز می باشد.
یکی از مشکلات لیست CRL حجیم شدن این لیست می باشد. در سازمانهای خیلی بزرگ برای ذخیره سازی این لیست و انتشار آن استورج و پهنای باند زیادی استفاده می شود.و دیگر مشکلات این روش تاخیر آن می باشد. لیست CRL در بازه های زمانی مشخصی منتشر می شود و بعد از انتشار این لیست بر روی کلاینتها Cache می شود. حالا اگر بعد از انتشار این لیست Certificateی باطل شود کلاینتها از این تعقیر تا انتشار بعدی بی خبر می مانند.جهت اطلاع شما دوستان برای تنظیم Publish شدن لیست CRL در ساختار می توانید از تنظیمات زیر استفاده کنید:
Online Certificate Status Protocol یا (OCSP) چیست؟
با امدن قابلیت جدید OCSP شما یک سرور Online دارید که به کاربران خدمات ویژه ای ارائه می دهد. وقتی Subjectی قصد داشته باشد وضعیت Certificateی را چک کند درخواست این Subject مستقیما به OCSP ارسال می شود و OCSP وضعیت Certificate و مسیر آن Certificate Path را چک می کند و جواب را بسوی Subject ارسال می کند.
نکته: کل ارتباطات OCSP با Subjectها از طریق پروتکل HTTP انجام می شود.
بزرگترین عیب این روش پایداری یا بهتره بگم UP Time این سرور می باشد. تا وقتی که این سرور روشن باشد این اعتبار سنجی به نحوه احسنت انجام می شود ولی اگر این سرور از کار افتد و بقیه پارامترها مانند CDP extension تنظیم نشده باشند کار Subjectها مختل می شود.
معرفی اجزای Online Certificate Status Protocol
اجزای OCSP به دو قسمت تقسیم می شود:
- Client
- Server
قسمت کلاینت جزئی از CRYPTOAPI می باشد که وقتی Subjectی قصد برسی وضعیت Certificateی را داشته باشد CryptoAPI را فراخوانی می کند و درخواست خود را به سمت OCSP ارسال می کند.
قسمت سرور شامل اجزای زیر می باشد:
Online Responder Web Proxy Cache:
این کامپوننت دو کار مهم را انجام می دهد:
Request Decoding: درخواست کلاینتها را بعد از دریافت رمزگشائی می کند و سریال نامبر Certificate را برای اعتبار سنجی استخراج می کند.
Response Caching: بعد از اینکه درخواست کلاینتها دریافت شد و سریال نامبر آنها استخراج شد Online Responder Web Proxy Cache کش خود را برای چک کردن وضعیت Certificate برسی می کند. اگر جوابی پیدا نکرد درخواست کلاینتها را به Online Responder Service ارسال می کند.
Online Responder Service:
بر اساس تنظیماتی که انجام می دهیم کار اصلی آن بازیابی و اعتبار سنجی کردن درخواست کلاینتها می باشد.
Revocation Configuration:
شامل تمام تنظیماتی می باشد که برای ارسال پاسخ هنگام چک کردن وضعیت Certificate به Subjectها استفاده می شود. یا یکسری تعاریف می باشد برای پاسخ دادن به وضعیت Certificateهای یک CA Server.
نکته: هر OCSP می تواند شامل چندین Revocation Configuration باشد.
Revocation Providers:
افزونه ی می باشد برای Revocation Configuration که Online Responder Service را قادر می سازد وضعیت Certificate را برسی کند و نتیجه را Cache کند.
Online Responder:
کامپیوتری می باشد که Online Responder service and Online Responder Web proxy بر روی آن در حال اجرست. و اطلاعات Revocation یک CA یا چندین CA سرور را در خود نگهداری می کند. جالبه که بدونید سرویس OCSP اطلاعات Revocation را از لیست CRL سرور CA بدست می آورد.در تکنت مایکروسافت اطلاعات زیادی درباره کامپوننتهای بالا وجود دارد که من آنها را برای درک راحتتر خلاصه کردم.
نحوه پیاده سازی OCSP چگونه است؟
با توجه به تصویر زیر ما می توانیم OCSP را بر روی یک سرور نصب کنیم یا در سازمانهای بزرگ که روزانه چندین هزار درخواست سمت OCSP ارسال می شود از لود بلانس نرم افزاری یا سخت افزاری استفاده کنیم:
در بعضی از سناریوها که قصد داریم OCSP توسط کاربران بیرون از سازمان در دسترس باشد می توانیم این سرویس را توسط TMG or ISA یا سولوشن های دیگر Publish کنیم.
برای اطلاع از نحوه Publish کردن این سرویس در ISA به لینکی که در آخر معرفی می کنم رجوع کنید.
معرفی انواع پیاده سازی OCSP در سازمان
برای نصب و راه اندازی این سرویس سه مرحله پیش رو داریم:
- نصب سرویس OCSP.
- آماده سازی محیط سازمان برای استفاده از این سرویس.
- تنظیم سرویس OCSP.
آموزش نصب سرویس Online Certificate Status Protocol
شما باید این سرویس را بعد از پیکربندی CA Server در سازمان و قبل از صدور هر گونه Certificate نصب و تنظیم کنید.
نکته: شما می توانید این سرویس را بر روی CA Server یا یک سرور مجزا نصب کنید.
برای نصب این سرویس مراحل زیر را دنبال کنید:
بعد از اتمام نصب مشاهده می کنید که کنسول IIS اضافه شده و یک Virtual Directory به نام OCSP ایجاد شده است.
آموزش آماده سازی محیط سازمان برای استفاده از این سرویس
اولین قدم در این راستا ایجاد A Record این سرویس در DNS می باشد.
دومین قدم تنظیم AIA Extensions بر روی CA Server می باشد.
در قسمت Location شما باید URL سرور OCSP به همراه Virtual Directory را بنویسید به عنوان مثال:
http://ocsp.mycity.local/ocsp
قدم بعدی تنظیم OCSP Response Signing Template می باشد. برای اینکار در کنسول CA
در کادر بالا سروری که روی آن OCSP نصب شده است را اضافه و مجوزهای Read and Enroll دهید. OK کنید و مراحل زیر را دنبال کنید:
الان این Template در کادر Certificate Template اضافه می شود و با اضافه شدن آن در این کادر بصورت اتوماتیک در اکتیو دایرکتوری Publish می شود.
این Template برای کارکرد OCSP و چک کردن درخواستهای کاربران مورد استفاده قرار می گیرد.
آموزش تنظیم سرویس OCSP
برای تنظیم OCSP این کنسول را از منوی استارت اجرا کنید:
- در این قسمت می توانید Revocation Configuration را ایجاد کنید. همانطور که می دانید هر CA Server باید دارای یک Revocation Configuration باشد. هر OCSP می تواند چندین RC داشته باشد.
- اگر چندین OCSP در ساختار داشته باشید همه زیر مجموعه Array Configuration می شوند و یکی از OCSP نماینده Array controller"" این Array Configuration می شود. این قابلیت زمانی مفید می باشد که تنظیمات Revocation Configuration سرورهای OCSP کانفلیت داشته باشند در چنین شرایطی تنظیمات Array controller بر روی OCSPها اعمال می شود.
برای ایجاد Revocation Configuration مراحل زیر را دنبال کنید:
نکته: برای هر CA Server باید یک Revocation Configuration ایجاد شود.
اسمی برای Revocation Configuration بنویسید.
در بالا باید روش دسترسی به CA Certificate را مشخص کنید. از طریق فایل یا Local Certificate Store یا از طریق اطلاعات ذخیره شده در Active Directory
در صفحه بعد Browse کنید و CA Certificate مورد نظر را انتخاب کنید.
در مرحله بالا شما باید OCSP Response Signing که در مرحله قبلی ایجاد کردید را معرفی کنید. چک باکس Auto-Enroll… باعث Enroll و Renew کردن اتوماتیک این Template می شود. اگر CA Server که در مرحله قبلی آن را انتخاب کردیم مسئول صادر کردن این Template باشد این چک باکس و فیلد های Certificate Authority and Certificate Template بصورت اتومات انتخاب و تنظیم می شوند.
در بالا با کلیک کردن دکمه Provider باید مشخص کنید Revocation Configuration چگونه به اطلاعات لیست CRL دسترسی داشته باشد. که همانطور که در تصویر بالا مشاهده می کنید از دو طریق این اطلاعات بازیابی می شوند اطلاعاتی که بر روی Web Server میزبانی می شوند و اطلاعاتی که در Active Directory ذخیره شده اند.بصورت پیش فرض OCSP قبل از اینکه اطلاعات CRL را بر روی شبکه جستجو کند بصورت لوکال دنبال یک CRL متعبر میگردد. اگر OCSP بر روی CA Server نصب شده باشد تنظیمات Provider نادیده گرفته می شود.
خب برای تست کارمون من یک WorkStation Authentication Certificate را بر روی کلاینتهای ساختار Enroll کردم. وقتی در قسمت Propertiesش میرم و گذینه زیر را انتخاب می کنم می بینم مخزن OCSP به درستی بر روی Certificateها اعمال شده
الان این Certificate را در درایو C به نام Client-01 اکسپورت می کنم و توسط دستور زیر:
certutil –URL c:\client-01.cer
ابزار URL Retrieval Tool را اجرا می کنم و OCSP را تست می کنم که در تصویر زیر
مشاهده می کنید که کلاینت اطلاعات Revocation این Certificate را با موفقیت از OCSP بدست آورد.
الان این Certificate را Revoke می کنم و اطلاعات Revocation را Publish می کنم.
دوباره تست می کنم
این از این. خب در آخر باید به این هم اشاره کنم که شما می توانید سرور OCSP را تنظیم کنید.تنظیماتی از قبیل Auditing و Security و همچنین تعداد Entry های که باید Cache شوند و غیره
قسمت Audit را حتما تنظیم کنید تا در مواقع اضطراری بتوانید با رجوع کردن به Event Viewer مشکل را حل کنید. درضمن برای اینکار حتما Audit object access را در Group Policy فعال کنید.همچنین می توانید Revocation Configuration را هم تنظیم کنید:
برای یاد گرفتن این تنظیمات و همچنین کارائی آنها به لینکی که در آخر ضمیمه می کنم رجوع کنید. (برای جلوگیری از طولانی نشدن مقاله از آموزش آنها خود داری می کنم).در آخر هم اینو بگم که مباحثم تکمیل بشه. برای تنظیم کردن OCSP از راه دور شما باید ابزار Remote Administration tools را بر روی کامپیوتر مقصد نصب کنید و دو رول زیر را در فایروال بر روی سرور OCSP فعال کنید:
در آخر باید بگم دوستان و همکاران عزیز. سعی کنید تمام قسمتهای این سلسله های آموزشی را درک و تمرین کنید. حفظ کردن این مطالب هیچ کمکی به شما نمی کند بلکه همه چیز را پیچیده می کند. در این آموزشها سعی کردم مباحث و مطالب اولیه هر قسمت را تا حدودی در آموزش های قبلی بیان کنم تا آمادگی این را داشته باشید که مطالب اینده را با درک بهتر و با دیدی بازتر یاد بگیرد. از اساتید خواهشمندم اگر کمی و کاستی یا اشتباهی در انتقال این آموزشها می ببیند حتما ذکر بدن تا در آموزش های بعدی لحاظ شود. با تشکر از همه شما.
منبع:
Online Responder Installation, Configuration, and Troubleshooting Guide
https://technet.microsoft.com/en-us/library/cc770413(v=ws.10).aspx
در این قسمت قصد دارم مباحث تکمیلی Online Responder و مباحث CRL را توضیح بدم.
آموزش تنظیمات OCSP URIs با گروپ پالیسی
با یک سوال شروع می کنم. کلاینتها از کجا متوجه می شوند برای برسی وضعیت Certificateها به کجا رجوع کنند؟؟ درسته کلاینتها به تنظیمات CDP, AIA and OCSP رجوع می کنند. خب مکانیزم متصل شدن به این تنظیمات را از کجا بدست می آورند؟؟؟؟ نمی دونم جوابتون چیه ولی امیدوارم بگید از طریق اطلاعاتی که در Certificate ذخیره شده است این تنظیمات را بدست می آورند. شما بعد از تنظیم کردن CDP, AIA and OCSP در ساختار این اطلاعات به Certificateها اضافه می شود و کلاینتها با چک کردن اطلاعات Certificate به این اطلاعات دسترسی پیدا می کنند.
یک سوال دیگه!!! Certificateهای که قبل از ایجاد این تنظیمات به Subjectها صادر شده اند چی؟؟؟ ایا آن Subjectها می توانند به این اطلاعات دسترسی داشته باشند؟؟ جواب منفی هستش. بخاطر همین توصیه شده قبل از هر گونه صادر کردن Certificate مقادیر بالا را تنظیم کنید. ولی خوشبختانه با آمدن Windows Vista و Windows Server 2008 تنظیماتی در Group Policy اضافه شده که می توان URL سرویس OCSP را به کلاینتهای سازمان اعمال کرد. و دیگر نگران Certificateهای که قبل از ایجاد تنظیمات OCSP صادر شدند نباشید. برای اینکه URL سرویس OCSP را بوسیله Group Policy به کلاینتها اعمال کنیم مراحل زیر را دنبال کنید:
قدم اول Export کردن CA Certificate می باشد برای اینکار:
و CA Certificate را ذخیره کنید. و بعد از آن اعمال تنظیمات GP بر روی کل Domain.
میسر زیر را طی کنید:
Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities
نکته: اگر Issuing CA شما Root CA نباشد باید این تنظیمات را بر روی Intermediate Certification Authorities انجام دهید.بعد از تعیین کانتینر اعمال تنظیمات، بر روی کانتینر مورد نظر راست کلیک کنید و گذینه Import را کلیک کنید:
بعد از آن Wizardی ظاهر می شود که شما باید CA Certificateی که در مرحله قبل آن را Export کردید را Import کنید.
بعد از Import کردن CA Certificate وارد کانتینری که این تنظیمات را بر روی آنجام دادید شوید و بر روی CA Certificate راست کلیک کنید و گذینه Properties را کلیک کنید
و قدم آخر اضافه کردن URL سرویس OCSP می باشد.
نکته: اگر می خواهید کلاینتها از لیست CRLاستفاده نکنند و فقط از OCSP استفاده کنند تیک Disable Certificate… را تیک بزنید که توصیه شده نیست.بعد از اعمال شدن این Policy همه کلاینتها علاوه بر تنظیمات CDP از OCSP نیز استفاده می کنند.
آموزش رفع اشکال سرویس Online Responder
بعضی مواقع پیش میاد که Revocation Configuration ی که در OCSP ایجاد کردید از کار می افتد و علامت قرمز رنگی جلوی آن ظاهر می شود. در چنین شرایطی اگر کلاینتی وضعیت Certificate را از OCSP درخواست دهد نتیجه عملیات Fail می شود. اگر به Event Viewer مراجعه کنید مشاهده می کنید Errorی ثبت شده که علت این مشکل را توضیح داده:
با سرچی که در Internet انجام دادم متوجه شدم علت این مشکل نبود سرتیفیکت OCSP Response Signing در Personal Store در سرور OCSP می باشد. برای حل این مشکل ساده دوباره آن Certificate را Enroll کردم و مشکل حل شد. برای Enroll کردن این Certificate مراحل زیر را دنبال کنید:
مشکل حل شد. توضیحات بیشتر در مورد این مشکل را می توانید در لینک زیر مطالعه کنید:
https://technet.microsoft.com/en-us/library/dd299794(v=ws.10).aspx
نکته دیگری که اهمیت زیادی دارد مدت زمانی هستش که OCSP اطلاعات Revocation را از مخازن CDP بدست می آورد. بصورت پیش فرض این مدت زمان بر اساس مدت زمانی می باشد که بر روی Base CRL and Delta CRL ست شده است. که بصورت پیش فرض Base CRL یک هفته می باشد و Delta CRL دو روز. من می خواهم تنظیمی انجام دهم که این اطلاعات هر 5 ساعت یکبار بر روی OCSP ابدیت شود.
برای این منظور:
نکته دیگری که حائز اهمیت هستش Cache شدن لیست CRL در کلاینتها می باشد. ( در سازمانهای که از OCSP استفاده نشود) وقتی لیست CRL در کلاینتی Cache می شود تا یک هفته این اطلاعات بر روی آن کلاینت باقی می ماند و کلاینت در این مدت زمان برای چک کردن وضعیت Certificate از کش خود استفاده میکند. بعضی وقتا به دلایلی شما Certificateی را باطل می کنید ولی کلاینتها از وضعیت این Certificate تا بعد از Expire شدن کش اطلاعی ندارند. آیا راه حلی وجود دارد که بتوانم این Cache را پاک کنم تا کلاینتها بتوانند جدیدترن لیست CRL را از CA دانلود کنند؟؟؟ بله شما می توانید با دستور زیر CRL Cache یک سیستم را پاک کنید:
certutil -urlcache crl delete
برای اطلاع بیشتر:
Forcing the Expiration of Locally Cached Certificate Revocation Lists
http://windowsitpro.com/security/forcing-expiration-locally-cached-certificate-revocation-lists
در این جلسه Certificate Template و روش Enroll کردن آنها را یاد خواهیم گرفت.
آموزش ساخت Certificate Template یا قالب گواهینامه
هر Certificate در ساختار PKI وظایف و کارهای مشخصی برای انجام دارد به اصطلاح دیگر هر Certificate برای کار مشخصی ایجاد می شود. بعضی از Certificateها برای رمزگذاری و رمزگشائی کردن به کار می روند و بعضی از آنها برای احراز هویت Client/Server به کار می رود و بعضی از آنها برای سرویس خاصی کاربرد دارند.وظایف هر Certificate درون خود Certificate تعبیه شده است.
وقتی شما یک Domain Controller در ساختار راه اندازی می کنید در پروسه نصب یکسری Certificate برای کارهای مشخصی ایجاد می شود. که به این Certificateهای اماده و از پیش ساخته شده Certificate Template گفته می شود. که با نصب Enterprise CA آنها را در قسمت Certificate Template می توانید مشاهده کنید.
نکته: Stand-alone CA فاقد Certificate Template می باشد. Certificate Templateهای که در بالا مشاهده می کنید بر Subjectهای مختلفی اعمال می شود و برای کارهای خاصی استفاده می شود مثلا در بالا شما سرتیفیکت تمپلت User را مشاهده می کنید که بر روی Userها اعمال می شود. وهر User که این تمپلت بر روی آن اعمال شود می تواند کارهای که در Certificate تعیین شده بوسیله این Template انجام دهد.
با استفاده از این تمپلت یک User می توانید فایلهای خود را رمزگذاری کند، Emailهای خود را Secure کند یا Clientها خود را برای بقیه احراز هویت کند.بعضی از Certificate Template ها بر روی کامپیوترها اعمال می شوند. که کارهای مشخصی انجام می دهند:
به نکات زیر در خصوص Certificate Templateها توجه کنید:
- Certificate Templateها فقط در همان Forest معتبر هستند.
- Certificate Template ها غیر قابل حذف هستند.
- بصورت پیش فرض فقط گروه Enterprise Admins و Domain Admins روت Domain میتوانند Certificate Templateها را مدیریت کنند. یعنی اگر در ساختار چندین Child and Tree داشته باشید فقط Domain Admins and Enterprise Admins اولین DC یا روت می توانند Certificate Templateها را مدیریت کند.
- اگر شما چندین Enterprise CA در ساختار داشته باشید هر تعقیری در Certificate Template ایجاد کنید این تعقیرات بر روی دیگر Enterprise CA ها اعمال می شود.
نکته: Certificate Template ها در کل ساختار دومین Publish می شوند و هر Subjectی می تواند Certificate Templateها را طبق مجوزی که بر روی Certificate تنظیم شده Enroll کنند.
ترفند:
برای مدیریت Certificate Template ها در ساختارهای چند دومینی می توانید یک گروه برای این منظور ایجاد کنید و مجوز مدیریتی را بوسیله مراحل زیر به این گروه واگذار کنید:
ADSI Edit را اجرا کنید و مسیر زیر را دنبال کنید
و به گروه مورد نظر مجوز مدیریتی دهید.
نکته: عملیات بالا را هم بر روی کانتینر CN=OID انجام دهید.
معرفی نسخه های مختلف Certificate Template
Certificate Template ها دارای چندین ورژن می باشند.
- Version 1 certificate templates
- Version 2 certificate templates
- Version 3 certificate templates
- Version 4 certificate templates
اولین ورژن در Windows Server 2000 معرفی شده که بر روی Windows 2000 و یندوزهای کلانیتی مانند 98 و غیره کاربر داشت. این ورژن تنها قابلیتی که به مدیر شبکه به ارمغان می آورد تعریف Permission بر روی آنها بود. که بصورت اتوماتیک و دستی می توان این ورژن را Enroll کرد. این ورژن برای سیستم عاملهای زیر در دسترس می باشد:
- Windows Server 2008 R2, all editions
- Windows Server 2008, all editions
- Windows Server 2003 R2, all editions
- Windows Server 2003, all editions
- Windows 2000 Server, all edition
دومین ورژن در Windows Server 2003 معرفی شد. که به مدیر شبکه اختیاراتی مانند کنترول درخواست، نحوه صدورو نحوه استفاده از آن را می داد. این ورژن مانند ورژن قبلی بصورت دستی و اتوماتیک Enroll می شود. این ورژن برای سیستم عاملهای زیر در دسترس می باشد:
- Windows Server 2008 R2, all editions
- Windows Server 2008, Enterprise and Datacenter editions
- Windows Server 2003 R2, Enterprise and Datacenter editions
- Windows Server 2003, Enterprise and Datacenter editions
سومین ورژن دقیقا مانند ورژن دو می باشد منتها قابلیت جدیدی به نام Suite B Cryptography در آن ایجاد شده که مجموعه از الگوریتم های رمزگذاری می باشد که بوسیله United States National Security Agency (NSA) تالیف و تایید شده است که برای ارتباطات خیلی حساس و سیستم های احراز هویت خیلی قوی کاربرد دارد. قابلیت فوق برای سیستم عاملهای Windows Vista and Windows Server 2008 به بالا قابل پیاده سازی می باشد. این ورژن برای سیستم عاملهای زیر در دسترس می باشد:
- Windows Server 2008 R2, all editions
- Windows Server 2008, Enterprise and Datacenter editions
و جدیدترین ورژن که در Windows Server 2012 معرفی شده است ورژن چهار می باشد که تمام امکانات بالا را دارد. و امکاناتی مانند renew کردن Certificate با کلید قبلی و تب Compatibility که باعث می شود به راحتی برای هر سیستم عامل Certificate مربوط به آن را انتخاب کنید. و امکانات دیگر. این ورژن مانند ورژنهای قبلی بصورت دستی و اتوماتیک Enroll می شود و برای سیستم عاملهای زیر در دسترس می باشد:
- Windows 8
- Windows 8.1
- Windows Server 2012
- Windows Server 2012 R2
آموزش مدیریت Certificate templates
یکی از مهمترین Best Practice های مایکروسافت درباره Certificate Template حذف Templateهای بلا استفاده در سازمان می باشد. مایکروسافت توصیه کرده که اگر از Certificate Templateهای که در کادر زیر وجود دارد
هیچ استفاده ی نکرده اید یا به اصطلاح دیگر هیچکدام از Certificate Templateها بالا را Enroll نکردید آنها را حذف کنید تا بر روی Subjectها اعمال نشود و در صورت لزوم آنها را صادر کنیم.
- نکته: اگر Certificate Templateی بر روی Subjectی اعمال شده باشد آن Certificate Template را حذف نکنید.
یکی از استفاده های زیادی که از Certificate در سازمانها می شود رمزگذاری کردن اطلاعات می باشد. برای اینکه کاربران بتوانند از خدمات CA Server در رمزگذاری کردن اطلاعات استفاده کنند باید Certificate این کار را از CA Server سازمان دریافت کنند. این Certificate باید الگوریتم های رمزگذاری را برای کاربران فراهم کند. خوشبختانه چند Certificate آماده و از پیش تعریف شده برای اینکار وجود دارد مانند Basic EFS or User. اگر Certificate Templateی می خواهید که فقط عملیات رمزگذاری را برای شما انجام دهد Basic EFS را تنظیم کنید. ولی سرتیفیکت تمپلت User یک پکیج می باشد که برای کارهای مختلفی می توان از آن استفاده کرد. من تمپلت User را برای اینکار تنظیم می کنم.
- نکته: توصیه اکید می کنم قبل از هرگونه رمزگذاری، توسط پرسنل سازمان، برای جلوگیری از دست دادن اطلاعات پرسنل یک Data Recovery Agent ایجاد کنید.
برای تنظیم این Certificate Template برای کاربران سازمان مراحل زیر را دنبال کنید:
در کادر بالا و درون تب Compatibility شما باید مشخص کنید این CA Server برروی چه سیستم عاملی میزبانی می شود و گیرنده این Template دارای چه نوع سیستم عاملی می باشند. شما با انتخاب سیستم عامل در کادر بالا قابلیتهای را از این Certificate Template کم و زیاد می کنید. چون من از Windows Server 2012 R2 برای سرور و Windows 10 برای کلاینتها استفاده کردم قابلیتهای که به این Certificate Template اضافه می شود را نشان می دهد.
در تب General می توانید یک اسم برای این Certificate Template بنویسید و مدت اعتبار و مدت Renew شدن این Certificate را مشخص کنید. و با تیک زدن گذینه Publish Certificate in Active Directory این Template در دیتابیس AD همراه با اطلاعات Subjectی که این Certificate را دریافت می کند ذخیره خواهد شد هدف این کار دسترسی به Certificate این User توسط User های دیگر می باشد.
برای اطلاع بیشتر:
This setting indicates the certificate issued based on the certificate template should be published to the Active Directory Domain Services (AD DS) database. When this setting is enabled, the user or computer object in the AD DS database is updated with the certificate of the user or computer respectively. The private key is not published to the AD DS database. For both computer and user certificates, the user Certificate attribute of the AD DS object is updated with the certificate. The CA must have write permission to the AD DS database user and computer objects to make this update. The permission to write to the computer and user objects in the AD DS database is granted to CAs through their membership in the Cert Publishers group by default. This setting is typically only used with user certificates. When a user’s certificate is published in the AD DS database, other users can search the AD DS database to find the certificate of that user. The certificate can then be used to encrypt email or files to the user whose certificate is published in the AD DS database.
Configure Certificate Publishing in Active Directory Domain Services
https://technet.microsoft.com/en-us/library/cc730861(v=ws.11).aspx
در تب بالا در قسمت Purpose هدف این Certificate را مشخص کنید. قراره این Certificate چه کاری انجام بده؟؟؟ همچنین می توانید اجازه دهید که کلید خصوصی این Certificate اکسپورت شود یا نه؟ ( در بعضی از سناریوها export کردن کلید خصوصی Certificate الزامی می باشد و شما باید تیک این گذینه را بزنید). به علاوه شما می توانید تنظیم کنید که این Certificate با کلید خصوصی قبلی، دوباره Renew شود. (یکی از قابلیتهای جدید Windows Server 2012 می باشد) وقتی شما در قسمت Purpose گذینه های Encryption or Signature and encryption را انتخاب کنید گذینه Archive subject's encryption private key فعال می شود و شما با انتخاب این گذینه می توانید کلید خصوصی این Certificate را در دیتابیس Subject ذخیره کنید تا در مواقعی که کلید خصوصی به هر دلیلی از بین رفت بتوان این کلید را بازیابی کرد.
Certification authorities (CAs) can archive a subject's keys in their databases when certificates are issued. If subjects lose their keys, the information can be retrieved from the database and securely provided to the subjects.
Request Handling
https://technet.microsoft.com/en-us/library/cc732007(v=ws.11).aspx
اجازه بدید مفهوم Cryptography را روشن کنیم؟ Cryptography یکسری قانون، روش، تکنولوژی یا علوم پایه می باشد برای امن کردن اطلاعات در شبکه های اینترانت و اینترنت. Cryptography در مایکروسافت یکسری libraryی هستن که شامل الگوریتم رمزگذاری و رمزگشائی می باشد. Cryptography امن کردن اطلاعات را در دو سطح نرم افزار و سخت افزار تعریف می کند.
- Cryptographic service providers (software)
- Key storage providers (hardware)
در کادر بالا شما در قسمت Provider Category میتوانید سطح امنیت را مشخص کنید.
نکته: key storage providers از چیپست های (تراشه) به نام Trusted Platform Module برای ذخیره کردن Certificate, Password, Secret Keys و غیره استفاده می کند. و شما می توانید این تراشه ها را از طریق کنسول زیر در Windows تنظیم کنید
تنظیمات امنیتی بالا برای ذخیره سازی کلید خصوصی و عمومی بر روی کلاینت می باشد.
Cryptography
https://technet.microsoft.com/library/cc770477
در این تب می توانید پارامترهای چون application policies, issuance policies, certificate subject types, and key usage attributes را تنظیم کنید.
نکته: هر Certificate بنا به ماهیت عملکرد خود از پارامترهای متفاوتی در این تب استفاده می کند.
گذینه Application Policy شما را قادر می سازد که عملکرد این Certificate را مشخص کنید.
نکته: Application Policy را با نام های دیگری چون called extended key usage or enhanced key usage نیز می شناسند.
در مثال بالا سرتیفیکت تمپلت User سه کار عمده را انجام می دهد:
- رمزگذاری کردن اطلاعات.
- امن کردن E-Mailهای ارسالی و دریافتی.
- احراز کردن کلاینت برای منابع شبکه.
شما می توانید این عملکرد را بنا به نیاز سازمان خود تعقیر دهید. برای اینکار Application Policy را انتخاب کنید و دکمه Edit را کلیک کنید:
شما با تنظیم Issuance Policy می توانید قوانینی تعریف کنید که هر Subjectی که این Certificate را درخواست دهد باید این قوانین را رعایت کند و برای Issue کردن این Certificate می توانید شرایطی را تعریف کنید. همانطور که می دانید هر درخواستی که به سمت CA Server ارسال می شود CA Server موظف است بر اساس یکسری Policyها یا سیاست به این درخواست پاسخ دهد.
در کادر بالا شما گذینه ای دارید به نام Enable requestor specified issuance policies که با تیک زدن آن به کلاینتها اجازه می دهید سیاستهای که در بالا تعریف کردیم را در درخواست خود مشخص کنند. وگرنه درخواست آنها برای این سرتیفیکت Fail می شود.
با ادیت کردن Key Usage میتوان Certificate را به انجام دادن کارهای محدودی کرد یا عملکردهای متعدی به عملکردهای آن اضافه کرد. شما بوسیله تنظیمات بالا میتوانید نحوه استفاده کردن از این Certificate را کنترول کنید.
و بقیه پرامترها که میتوانید آنها را در لینک زیر مطالعه کنید:
Certificate Template Extensions
https://technet.microsoft.com/library/cc754305
در تب Subject Name می توانید تعیین کنید که نام استفاده شده برای این Certificate چگونه ایجاد شود. هر Certificate برای اینکه برروی Subjectی اعمال شود باید برای خود یک نام انتخاب کند. شما بوسیله تنظیمات بالا می توانید تعیین کنید این نام چگونه برای Subject انتخاب شود. که چندین گذینه دارید.
با انتخاب Supply the Request شما این نام را باید در CSR مشخص کنید. این فرایند را می توانید در این مقاله بخوانید.
گذینه دیگری وجود دارد به نام Build from this Active Directory information که این اطلاعات را از ساختار Active Directory استخراج میکند.
نکته: یکی از مزایای استفاده از Enterprise CA این مورد می باشد. و همچنان که می دانید این قابلیت در Stand-Alone CA موجود نیست و شما باید این اطلاعات را در CSR مشخص کنید. برای اطلاعات بیشتر در مورد تنظیمات بالا لینک زیر را مطالعه کنید:
Subject Names
https://technet.microsoft.com/en-us/library/cc753994(v=ws.11).aspx
در تب Security شما باید مشخص کنید چه کسی مجوز مدیریت این Certificate Template را داشته باشد؟ و همچنین این Certificate Template بر روی چه کسانی اعمال شود؟ و چگونه اعمال شود؟
شما علاوه بر بقیه Permissionها دو Permission متفاوت دارید:
Enroll= اگر شما این مجوز را به گروهی دهید آن گروه می توانند بصورت دستی از طریق Snap-In Certificate Console یا از طریق Certificate Enrollment Web Service آن را درخواست و بر روی خود اعمال کنند.
AutoEnrollmet= اگر این مجوز را به گروهی دهید Certificate Template بصورت اتوماتیک بر روی کلاینتها اعمال می شود و شما نیاز به انجام کار خاصی ندارید.
نکته: اگر می خواهید پروسه AutoEnrollmet بصورت کاملا اتوماتیک اعمال شود تنظیمات زیر که در تب Request Handling می باشد را بصورت پیش فرض رها کنید.
بعد از انجام تنظیمات بالا و دادن Permission به گروه ها OK کنید تا Certificate Template ایجاد شود.
نکته: ما هم اینک یک Certificate Template Version 4 ساختیم. که از قابلیتهای جدیدی استفاده می کند. پس به خاطر داشته باشید این قابلیتهای جدید فقط بر روی Windows 8 and Windows Server 2012 به بالا اعمال می شود. بعد از انجام مراحل بالا باید این Certificate Template را به CA Server معرفی کنیم برای اینکار
بعد از انجام مراحل بالاEnroll کردن Certificate Template بصورت دستی (Enrollment) و بصورت اتوماتیک (Auto-Enrollment) را توضیح می دهیم.
آموزش تنظیمات Certificate Enrollment
بر روی کلاینتها دستور MMC را اجرا کنید و کنسول Certificate را انتخاب کنید:
My user account: manage certificates related to your account (personal certificate);
Service account: manage certificates related to a service (IIS, LDAP etc.);
Computer account: manage certificates related to the computer (or remote computer).
نکته: چون این Certificate برای Userهای دومین ایجاد شده در Snap-in بالا User Account را انتخاب کنید.
با زدن دکمه Enroll این Certificateبر روی این کلاینت اعمال می شود.
آموزش تنظیمات Certificate Auto-Enrollment
نکته: قابلیت Auto-Enrollment فقط در محیط دومین قابل پیاده سازی می باشد.
برای اینکه کاربرها بتوانند اتوماتیک این Certificate را درخواست دهند و بر روی خود عمال کنند ما باید یک Group Policy برای آنها ایجاد می کنیم. برای اینکار کنسول Group Policy Management را اجرا کنید:
گذینه های آن ساده هستن و نیازی به توضیح ندارند.
نکته: مراحل بالا را بر روی User and Computer انجام دهید.
بعد از اجرای دستور Gpupdate /force این Certificate بصورت اتوماتیک بر روی کلاینتها اعمال می شود.
در آخر این مقاله نکته ی درباره رمزگذاری اطلاعات را یاد آوری کنم که دید بهتری به شما می دهد:
By default, EFS certificates are self-signed; that is, they don't need to obtain certificates from a CA. When a user first encrypts a file, EFS looks for the existence of an EFS certificate. If one isn't found, it looks for the existence of a Microsoft Enterprise CA in the domain. If a CA is found, a certificate is requested from the CA; if it isn't, a self-signed certificate is created and used. However, more granular control of EFS, including EFS certificates and EFS recovery, can be established if a CA is present. You can use Windows 2000 or Windows Server 2003 Certificate Services.
در آخر برای عیب یابی این پروسه لینک زیر را مطالعه کنید:
Troubleshooting Certificate AutoEnrollmet in Active Directory Certificate Services (AD CS)
http://social.technet.microsoft.com/wiki/contents/articles/3048.troubleshooting-certificate-autoenrollment-in-active-directory-certificate-services-ad-cs.aspx
در جلسه اینده Renew کردن Certificate یا ایجاد یک Data Recovery Agent را آموزش خواهم داد.
در قسمتهای قبلی اشاره کردیم که چرا یک Certificate باید مدت زمان داشته باشد. وقتی Subjectی سرتیفیکیتی برای او صادر می شود سه پارامتر زیر را بر روی آن چک می کند:
- باطل بودن Certificate
- مدت زمان اعتبار این Certificate
- آیا CAی که این Certificate را صادر کرده معتبر می باشد؟
قانونی در زیر ساخت کلید عمومی وجود دارد که اگر CA’s Certificate منظورم سرتیفیکت خود CA Server مدت زمان اعتبار آن به پایان برسد تمام Certificateهای صادر شده آن باطل خواهد شد. این قانون شامل Root CA, Subordinate CA and Issuing CA می باشد.Certificateها بسته به نوع آنها مدت زمان خاصی برای خود دارند که در جدول زیر آنها را مشاهده می کنید:
مدت زمان Certificateها در یک ساختار سلسله مراتبی می تواند متفاوت باشد و این تفاوت به مدت زمان Root CA’s Certificate بستگی دارد. مثال می زنم: فرض کنید در حین نصب Root CA مدت زمان CA’s Certificate آن را بر روی 5 سال تنظیم می کنیم. وقتی Root CA قصد داشته باشد Certificateی به subordinate CA صادر کند مدت زمان آن Certificate زیر 5 سال می باشد به عنوان مثال دو سال. پس در سه سال اول هر Certificateی از Root CA صادر شود مدت زمان اعتبار آن Certificate دو سال می باشد. وقتی که سه سال اول تمام شد Root CA مدت زمان اعتبار Certificate ها را کاهش می دهد. تا به 4.5 برسد که در این صورت Certificate ها زیر 6 ماه صادر خواهند شد.
- قانون دوم
هیچ CA Server در دنیا وجود ندارد که Certificateی صادر کند که مدت زمان آن Certificate بیشتر از مدت زمان CA’s Certificate باشد.با توجه به تعاریف بالا باید مکانیزمی وجود داشته باشد که قبل از Expire شدن Certificate آن را از نو ایجاد کرد (Renew) ما کلا به دو دلیل Certificateها را Renew می کنیم: (این مسئله را با علت وجود مدت زمان بر روی Certificate اشتباه نگیرید).
- جلوگیری از Expire شدن Certificateها.
- جلوگیری از صادر شدن Certificateها با مدت زمان کوتاه.
Renew کردن CA’s Certificate تاثیر مستقیمی بر روی نحوه اعتبار سنجی CA Server توسط کلاینتها دارد. بهتراست با یک سوال شروع کنیم:
با Renew کردن Root CA’s Certificate چه اتفاقاتی بر روی کلاینتها و Subordinate CA می افتد؟
قبل از جواب دادن به این سوال باید عرض کنم موقع Renew کردن یک Certificate ما دو روش مهم برای این کار داریم:
- Renew کردن Certificate با کلید قبلی.
- Renew کردن Certificate با ایجاد دو کلید جدید.
در مواقعی که ما از روش اولی استفاده کنیم هیچ اتفاق و واکنش خاصی بر روی ساختار PKI نمی افتد و مانند قبل ساختار PKI به کار خود ادامه می دهد. ولی اگر در پروسه Renew کردن ما یک جفت کلید جدید ایجاد کنیم واکنشهای زیر اتفاق می افتد و مدیر ساختار PKI باید از آنها با خبر باشد.برای اینکه کلاینتها به یک CA Server اعتماد داشته باشند باید CA’s Certificate آن CA بر روی کلاینت ذخیره شود و از این به بعد Certificate های صادر شده از این CA را با CA’s Certificate مقایسه و اعتبار سنجی می شوند. پس در نتیجه هر Certificate به CA’s Certificate متصل و اعتبار سنجی می شود. چگونه یک Client می تواند به CA’s Certificate دسترسی داشته باشد؟ و Certificateها چگونه با CA’s Certificate اعتبار سنجی شوند؟ بوسیله سه پارامتر زیر:
- Subject Key Identifier
- Authority Key Identifier
- Authority Information Access
SKI حاوی یک KeyID می باشد که متعلق به Public key روت CA می باشد و بصورت هش رمزگذاری شده است. این KeyID بصورت اتوماتیک به فیلد AKI اضافه می شود.
- نکته: فیلد AKI بر روی هر Certificateی که CA صادر می کند اعمال می شود.
و AIA هم شامل مخازنی مانند LDAP and URL می باشد که محل دانلود CA’s Certificate را مشخص میکند.پس نتیجه گیری می کنیم کلاینتها بوسیله AIA به CA’s Certificate دسترسی و آن را دانلود می کنند و بوسیله SKI and AKI که بر روی Certificateها تعبیه شده خود را با CA’s Certificate مقایسه و اعتبار سنجی می کنند. وقتی ما CA’s Certificate را با یک حفت کلید جدید Renew کنیم یک Certificate کاملا جدید با پارامترهای SKI and AKI جدید ایجاد می شود. با این شرایط تکلیف Certificateهای قبلی و عملیات Validation چه خواهد شد؟؟؟
در این صورت همه Certificateهای قبلی باید باطل شوند و کلاینتها باید دوباره CA’s Certificate را دانلود کنند و بر روی خود اعمال کنند!!!!!!!!!!! برای حل این مشکل Windows بصورت اتوماتیک دو Certificate ایجاد می کند یک Certificate که بوسیله CA’s Certificate قدیمی Sign شده و CA’s Certificate جدید را تصدیق و معتبر می کند. و Certificate دوم که بوسیله CA’s Certificate جدید Sign شده و CA’s Certificate قدیمی را تصدیق و معتبر می کند.
نمی خوام بیشتر از این ریز بشم ولی کلا اگر یک Certificate قدیمی بخواهد مدت زمان خود و اعتبار خود را چک کند به Ca's Certificate قدیمی متصل می شود که این Certificate مستقیما به Certificate جدید وصل می باشد و برعکس. و به لطف این دو Certificate، سرتیفیکتهای قدیمی وجدید می توانند به کار خود ادامه دهند.لیست این Certificate ها را می توانید در مسیر زیر پیدا کنید:
وقتی این دو Certificate ایجاد شد بصورت اتوماتیک در مخازن AIA اپلود می شوند و بر روی کلاینتها Distribute می شوند و در Intermediate and Trusted Root CA certificate store ذخیره خواهند شد.
بخاطر داشته باشید PKI Client ها فقط در زمانvalidation از این Certificateها استفاده می کنند. و یکی از این Certificate ها در Intermediate و Trusted Root CA certificate store ذخیره خواهد شد.پس شما به عنوان یک مدیر PKI باید همیشه به این توجه داشته باشید که این Certificate ها بر روی PKI Client Domain-Joined and Non-Domain Joined اعمال بشه و در مخازن AIA وجود داشته باشند. و کلاینتها بتوانند به URLهای تعریف شده در AIA دسترسی داشته باشند و اما Renew کردن Root CA’s Certificate: برای اینکار:
اگر می خواهید از همان کلید قبلی استفاده کنید گذینه No را انتخاب و Ok کنید. ولی اگر می خواهید یک کلید خصوصی و عمومی جدید ایجاد کنید گذینه Yes را انتخاب و Ok کنید.طبق گفته بالا در مواقعی کلید جدید ایجاد کنید که کلید های قبلی CA سرور در معرض خطر باشد. نکته: Renew کردن Certificate پروسه ی هستش که بیشتر بر روی Root CA and Subordinate CA ها انجام میشه نه بر روی هر Certificateی که CA صادر می کند. ناگفته نماند که Renew کردن Certificate ها بر روی کلاینتها بصورت اتوماتیک انجام می شود (به لطف GPO)
یا خود کاربر می تواند این پروسه را انجام دهد (به شرطی که مجوز اینکار را داشته باشد)
در هنگام ایجاد Certificate Template شما می توانید مدت زمان اعتبار این Certificate و همچنان مدت زمانی که سرتیفیکت Renew می شود را تعیین کنید. و همچنان می توانید از قابلیت جدیدی که در Windows Server 2012 ایجاد شده Certificate را با کلید قبلی Renew کنید.
اجازه بدید اخر این مقاله را با یک سوال تموم کنم: ایا با Renew کردن Root CA’s Certificate نیازی به Renew کردن Subordinate CA هست یا نه؟؟؟؟
در این قسمت یکی از سرویس های Microsoft CA به نام Certification Authority Web Enrollment را برسی می کنیم.شما با نصب این سرویس یک Web Page ایجاد می کنید که کاربران از طریق این page بتوانند با CA Server در تعامل باشند. این سرویس با ادرس https://////certsrv در دسترس می باشد که قسمت ServerName آن سروری می باشد که این سرویس را میزبانی می کند و عبارت certsrv که حتما باید با حروف کوچک نوشته شود و در انتهای ادرس باشد.سرویس CA Web Enrollment شما را به CA Server وصل می کند و به شما توانائی انجام کارهای زیر را می دهد.
- Requesting certificates from the CA.
- Requesting the CA's certificate.
- Submitting a certificate request by using a PKCS #10 file.
- Retrieving the CA's certificate revocation list (CRL).
دو ماه پیش بحثی را شروع کرده بودم، که علت پیداش این سلسله آموزشی همین بحث بود (یکی از فوائد بحث) بعد... سوالاتی کرده بودم که بعضی از این سوالات مربوط به همین سرویس بوده که سعی می کنم بصورت جامع در ادامه این آموزش به آنها پاسخ بدم. یکی از سوالات این بود که چه عملیاتی می توانیم در Certificate authority Web Enrollment انجام دهیم؟ که پاسخ این سوال را در بالا مشاهده کردید.
خب کی وکجا از این سرویس استفاده کنیم؟ شما وقتی CA Server در مد Enterprise نصب کنید کاربران شبکه با استفاده از Snap-in MMC می توانند درخواست Certificate و غیره دهند و بعلاوه بوسیله Certificate Template می توان Certificate های مورد نیاز را بصورت اتوماتیک به کاربران اعمال کرد. پس در چنین شرایطی استفاده از CA Web Enrollment زیاد عقلانی نیست. پس این سرویس را در چه شرایطی پیاده سازی کنیم؟
پاسخ: این سرویس به همراه CA Serverی نصب می شود که در مد Stand-alone باشد. تا کاربران بتوانند بوسیله یک Web Page درخواست Certificate و غیره دهند. در بعضی از سناریوها این سرویس را به همراه CA Server در مد Enterprise نصب می کنند تا کاربرانی که جوین دومین نیستند بتوانند درخواست Certificate و غیره دهند.شما می توانید این سرویس را بر روی خود CA Server نصب کنید. یا بر روی یک سرور جدا. دلایلی که باعث میشه این سرویس را بر روی یک سرور جدا نصب کنیم:
One reason why you might deploy this configuration is if you currently have a Windows 2000 / Window Server 2003 Certification Authority and need to be able to deploy certificates to Windows Vista and Windows Server 2008 machines via the CA web site pages. Another reason might be because you want to offer certificate enrollment to Internet-based users but do not want to expose your Certification Authority to the Internet.
برای نصب این سرویس بر روی یک سرور جدا لینک زیر را مطالعه کنید.
How to configure the Windows Server 2008 CA Web Enrollment Proxy
https://blogs.technet.microsoft.com/askds/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy/
ولی اگر می خواهید این سرویس را بر روی خود CA Server نصب کنید با ما همراه باشید.برای آموزش این سرویس من یک CA Server بصورت Stand-alone نصب کردم و الان قصد دارم این سرویس را بر روی CA Server نصب کنم. برای اینکار وارد Server Manager شوید و گذینه زیر را انتخاب کنید:
همه تنظیمات را بصورت پیش فرض قرار دهید و Next کنید تا این سرویس نصب شود.
بعد از نصب اگر وارد کنسول IIS شوید مشاهده می کنید که یک Virtual Directory به نام certsrv ایجاد شده است.
الان به عنوان یک کامپیوتر Workstation یا Domain Joint می خواهم از خدمات CA Server بوسیله این سرویس استفاده کنم.
- نکته: اگر این سرویس را بر روی Windows server 2012 نصب کنید کاربران Windows XP نمی توانند از خدمات آن استفاده کنند.
- نکته: مرورگر پیشنهادی برای کار کردن با این سرویس Internet Explorer 10 به بعد می باشد.
برای خوشکل شدن سناریو سرویس DNS را بر روی CA Server نصب می کنم و یک Zone به نام ITPRO.IR ایجاد می کنم و رکورد PKI.ITPRO.IR را به CA Web Enrollment اختصاص می دهم.برای شروع ادرس زیر را در مرورگر وارد می کنم:
Ok!!!! تا اینجا رو فاکتور بگیرید.در این سناریو ما یک CA Server بصورت Stand-alone در یک شبکه Flat ایجاد کردیم. اولین کاری که باید انجام دهیم شناسی کردن این CA سرور به Client/Server می باشد. (ایجاد رابطه اعتماد) خب برای اینکار بعد از متصل شدن به CA Web Enrollment گذینه زیر را را انتخاب می کنیم:
و در مرحله آخر این Certificate را در Trusted Root Certification Authorities ایمپورت می کنیم
کار تمام شد
- نکته خیلی مهم: گاهی وقتا موقعه کار کردن با این سرویس Error زیر را دریافت می کنید:
که میگه به منظور تکمیل درخواست شما Web Site ی که سرویس CA Web Enrollment بر روی آن میزبانی شده حتما باید احراز هویت آن بر روی Https تنظیم شود.برای حل این مشکل حتما باید یک Certificate از CA درخواست دهید و این Certificateرا به این وب سایت Bind کنید.برای اینکار وارد کنسول IIS شود و گذینه Server Certificate را انتخاب و گذینه زیر را کلیک کنید:
و مراحل زیر را دنبال کنید:
قسمت Common name باید با ادرسی که در مرورگر وارد می کنید یکی باشد.
بعد از ایجاد درخواست وارد کنسول CA Server شوید و گذینه زیر را انتخاب کنید:
فایلی تکستی که چند لحظه پیش در IIS ایجاد کردید را انتخاب و Open کنید. بعد از آن وارد کانتینر Pending Request شوید و Certificate مورد نظر را Issue کنید
الان وارد کانتینر Issued Certificated شوید و گذینه زیر را انتخاب کنید:
بعد از اتمام شدن مراحل فوق دوباره به کنسول IIS بروید و مراحل زیر را انجام دهید:
الان این Certificate را به این وب سایت Bind کنید.
الان باید بتوانید با ادرس https:://pki.tosinso.com/certsrv بدون هیچ مشکلی وصل شوید.
خب دوستان سرویس ما بدون هیچ مشکلی کار می کند و می توانیم کارهای روزمره خود را انجام دهیم. شما با Publish کردن این سرویس می توانید به کاربران سازمان، بیرون از سازمان این خدمات را ارائه دهید.هم اکنون می توانید با مطالعه لینک زیر عملکرد های این سرویس را امتحان کنید.
Certification Authority Web Enrollment Guidance
https://technet.microsoft.com/en-us/library/hh831649(v=ws.11).aspx
نکته: گرچه بیشترین استفاده این سرویس همراه Stand-alone CA می باشد ولی در محیط های که CA از نوع Enterprise باشد و بیرون از سازمان کاربرانی دارید که می خواهند از خدمات CA استفاده کنند بهترین گذینه استفاده از سرویس CA Web Enrollment هستش.
در این قسمت قصد دارم هدف استفاده از زیر ساخت کلید عمومی بصورت سلسله مراتبی یا CA Hierarchy را توضیح دهم. نکته: بدون مطالعه قسمت های قبلی از این سری آموزش درک مطالب ارائه شده در این قسمت میسر نیست.هدف و ایجاد یک زیر ساخت کلید عمومی را در قسمت های قبلی برسی کردیم و چرا باید از Certificate در سازمانها استفاده کنیم را نیز گفتیم.در سازمانهای خیلی خیلی بزرگ ساختار کلید عمومی را بصورت سلسله مراتبی یا Hierarchy ایجاد می کنند. چرا اینکار را می کنند را در ادامه توضیح می دهم.
فرض کنید یک سازمان با هزاران کاربر که همگی از ساختار PKI استفاده می کنند به علت ناشی گری یکی از ادمینها یا صانحه ای ساختار PKI از بین برود... می توانید تخمین بزنید صدماتی که این سازمان در این رابطه متحمل می شود چقدر است؟ موقعیت و اعتبار آن سازمان چه می شود؟ اگر فکر می کنید چیز خاصی اتفاق نیفتاده و سازمان همچنان می تواند به کار خود ادامه دهد باید عرض کنم هنوز اهمیت و ماهیت این ساختار را متوجه نشده اید. علاوه بر ایجاد پایداری در ساختار PKI این روش دارای مزیتهای می باشد که در ادامه یاد آوری میکنم. برای اینکه سازمانها از این اتفاقات بیمه شوند و از مزیتهای آن بهره مند شوند ساختار PKI را بصورت سلسله مراتبی پیاده سازی می کنند. خود این ساختار سلسله مراتبی شامل چندین مد می باشد:
- One-Tier Hierarchy
- Two-Tier Hierarchy
- Three-Tier Hierarchy
One-Tier Hierarchy چیست؟
در این مد ما فقط یک CA Server داریم که هم بوجود آورنده ساختار PKI می باشد وهم با منابع شبکه در ارتباط است Issuing CA این نوع ساختار (به قول مایکروسافت) در هیچ سناریوئی توصیه شده نیست.
This one-tier hierarchy is not recommended for any production scenario
اگر اسیبی CA Server را تهدید کند در واقعه کل ساختار PKI را تهدید می کند. سازمانی که بیش از 1000 کاربر داخل سازمان یا خارج سازمان داشته باشد Import کردن CA’s Certificate این سرور کار چندان آسانی نیست و با از بین رفتن این سرور کار بعضی از سرویس های شبکه مختل می شود و دوباره نصب کردن این سرویس هم هزینه بر است و هم زمان بر. این مد بصورت موقت استفاده می شود. مثلا پیمانکاری برای انجام پروژه ی در یکی از سازمانها مستقر می شود و برای ارتباط با پرسنل خود از Wireless استفاده می کند و چون اطلاعات حساسی رد و بدل می شود توسط ساختار PKI ارتباطات را رمزگذاری می کند و همچنین پرسنل خود توسط این ساختار احراز هویت می کند. (خواهشا یک پیمانکار خارجی را با یک پیمانکار ایرانی مقایسه نکنید).
Three-Tier Hierarchy چیست؟
در این مد از سه لول استفاده می شود. Root CA بوجود آورنده ساختار PKI که بصورت Offline می باشد. Intermediate CA که یک واسط بین Root CAها و Issuing CA ها می باشد که بصورت Offline می باشند. و لول سوم Issuing CA ها می باشند که مستقیما با خود کاربر در ارتباط هستند و بصورت Online فعالیت می کنند.علت وجود Intermediate CA در این ساختار تعریف سیاست های مختلف برای هر یک از Issuing CA می باشد. به عنوان مثال می توانم سیاستهای متفاوتی بر روی Issuing CA 1 تعریف کنم که فقط برای کاربران این CAباشد و بقیه CAها نیز سیاستهای مختلفی اعمال شود.
و یکی دیگر از دلایل آن ایجاد پایداری در این نوع ساختار می باشد. فرض کند تمام Issuing CA ها بنا به دلایلی از بین رفتند شما در این ساختار خیلی راحت بعد از نصب این سرویس و درخواست یک Certificate از CA های بالا دستی می توانید این سرورها را ریکاوری کنید بدون نیاز به Import کردن هر گونه Certificateی. و مزیت دیگر آن باطل کردن مجموعه زیادی از Certificate می باشد. فرض کنید Certificate تمام کاربران قسمت فروش هک شود در چنین شرایطی لازم نیست تک تک Certificateها را باطل کنید کافیست سرتیفیکت CA سرور آن قسمت را در Intermediate CA باطل کنید.
- نکته: در بیشتر داکیومنتها به این نوع CA ها Policy CA گفته می شود.
Two-Tier Hierarchy چیست؟
یکی از دلایل مهم استفاده از Three-Tier Hierarchyو Intermediate CA تعریف سیاستهای مدیریتی بر روی برخی از Issuing CA می باشد. در سازمانهای که این موضوع برای آنها زیاد مهم نباشد معقول نیست هزینه ی در این رابطه کنند. پس آنها از مد Two Tier Hierarchy استفاده می کنند که هم به صرفه می باشد و هم پایداری و اطمینان در این ساختا را ضمانت میکند.در این مد همانند مد قبلی اگر Issuing CAها را خطری تهدید کند به راحتی می توان با استفاده از Root CA که بصورت Offline می باشد آنها را ریکاوری کرد. و علاوه بر آن مزیتهای که مد قبلی دارا بود را شامل می شود.
شما در تصاویر بالا اصطلاحی به نام Offline and Online دارید شاید برای بعضیا سوال باشه که چرا CA های غیر از Issuing Caها را Offline می کنند؟؟؟؟ CAی که از طریق شبکه بتوان به آن دسترسی داشت و یا با کاربران در تعامل باشد را Online و بر عکس این CA را Offline می گویند. به دلیل اهمیت Root CA ها و اطلاعاتی که آنها نگهداری می کنند همیشه ارتباط آنها را از شبکه قطع می کنند تا احیانا اگر خطری متوجه CA زیر دستی باشد بتوان با CA های بالا دستی آنها را به مدار برگرداند این تعریف برای Intermediate CA ها نیز صدق می کند.
- اگر همیشه این CA های مهم خاموش باشند!!! پس چه استفاده ی دارند؟
سرورهای Offline در شرایط زیر Online می شوند:
- ارسال Certificate به CAهای پایین دستی. به عنوان مثال Submit کردن درخواست Intermediate CA توسط Root CA.
- Expire شدن لیست CRL مربوط به Root CA or Intermediate CA.
- Renew کردن Certificateهای پایین دستی.
- و در مواقع اضطراری.
رابطه اعتماد در CA Hierarchy چگونه است؟
برای اینکه کاربری بتواند به CA ی اعتماد داشته باشد باید کلید عمومی آن را در خود ذخیره کند. در یک ساختار سلسله مراتبی مهمترین CAکه رابطه اعتماد را ایجاد می کند Root CA می باشد. و همانطور که می دانید CA های پایین دستی Root CA توسط خود Root CA’s Certificate مورد اعتماد می شود. بصورت خلاصه باید بگم برای اینکه کاربری بتواند به ساختار سلسله مراتبی PKI اعتماد داشته باشد به Root CA’s Certificate نیاز دارد. به نظر شما چرا باید اینطوری باشد؟؟؟
وقتی Root CA سرتیفیکتی به Intermediateها ارسال می کند این سرتیفیکت حاوی امضائی می باشد که توسط آن کلید خصوصی خود را ایجاد کرده پس در نتیجه Intermediateها و Issuing CA توسط کلید عمومی Root CA که در خود ذخیره کرده اند می توانند امضای کلید خصوصی Root CAرا اعتبار سنجی کنند. پس در نتیجه کاربران به Intermediate and Issuing CAها اعتماد دارند چون به Root CA اعتماد دارند. پس در ایجاد CA Hierarchy یکی از پروسه های مهم Import کردن Root CA’s Certificate بر روی کلاینتها و CA های پایین دستی Root CA می باشد.
نکاتی که در ایجاد یک CA Hierarchy باید لحاظ شود
اولین قدم برای ایجاد این ساختار در یک سازمان لحاظ کردن نیازمندی های آن سازمان می باشد. شما باید مشخص کنید از چه مد در CA Hierarchy استفاده کنید؟ وکدام یک از این مدها جوابگوی نیازمندی های سازمان می باشد، مزایا و معایب هر کدام چه می باشد؟ بعد از مشخص کردن پارامتر فوق باید نوع CA را مشخص کنید، به عنوان مثال Stand-alone, Enterprise؟؟؟ نکته بعدی مشخص کردن طول عمر Certificateها می باشد.
Root CA با چه مدت زمانی Certificate ها را به CA پایین دستی صادر کند؟ Issuing CA با چه مدت زمانی Certificate ها را به کاربران صادر کند؟ توصیه ای که در این رابطه در CA Hierarchy میشه دو برابر بودن طول عمر CA بالا دستی از CA پایین دستی می باشد. به عنوان مثال: اگر Intermediate CA سرتیفیکتی را با طول عمر5 سال به Issuing CA صادر کند باید Certificate خودش دو برابر این طول عمر باشد. توصیه مایکروسافت در CA Hierarchy بدین صورت می باشد:
- Root CA’s Certificate 20 Years
- Intermediate CA’s Certificate 10 Years
- Issuing CA’s Certificate 5 Years
- نکته: تعریف بازه های زمانی بالا به سیاستهای سازمان شما بستگی دارد.
فاکتور آخر تعیین جائی برای ذخیره کردن اطلاعات مربوط به AIA and CDP می باشد. یکی از مهمترین قسمتی های که می تواند تجربه ادمین در یک ساختار PKI را به زهرمار تبدیل کند تنظیم بد این دو پارامتر می باشد. CDP در ساختار CA Hierarchy باید به محل ذخیره سازی کل لیستهای CRL سرورهای CA اشاره کند و همچنین AIA که به CA’s Certificate های سرورهای CA اشاره می کند.در قسمت بعدی ما یک ساختار سلسله مراتبی در مد Three-Tier Hierarchy ایجاد می کنیم و چیزای که قبل از ایجاد این ساختار لازم بود شما بدانید را در اینجا توضیح دادم تا در قسمت بعدی امادگی کامل را داشته باشید.
در قسمت قبلی ما توضیحاتی درباره ساختار PKI بصورت سلسله مراتبی دادیم و در این قسمت می خواهیم بصورت عملی این ساختار را پیاده سازی کنیم پس با ما همراه باشید. نکته: بدون مطالعه کردن قسمت های قبلی درک مطالب این قسمت میسر نیست. ساختار کلی سناریوی ما بصورت زیر می باشد:
آموزش تنظیمات اولیه Web Server
اولین قسمت در پیاده سازی این سناریو نصب DC و سرویس DNS می باشد. بعد از نصب این دو سرویس باید IIS را قبل از نصب هر گونه CA Server نصب کنید. چون Web Server اطلاعات AIA and CDP کل ساختار را نگهداری می کند.
بعد از نصب IIS شما باید کارهای زیر را بر روی Web Server انجام دهید:
- ایجاد فولدری به نام CertEnroll بر روی Web Server و Share کردن آن.
- مجوز دادن Full به گروه Cert Publishers و Everyone در Share Permission بر روی این فولدر.
- دادن مجوز Full به گروه Cert Publishers در Security Permission و مجوز Read & Execute و list folder… به گروه Everyone
- بعد از انجام مراحل بالا کارهای زیر را بر روی IIS انجام دهید:
- ایجاد یک Virtual Directory به نام CertEnroll در IIS.
- دادن مجوز به گروه های ANONYMOUS LOGON بر روی این فولدر در کنسول IIS
- فعال کردن گذینه Allow double escaping در Request Filtering
- فعال کردن ابشن Directory Browsing.
انجام مراحل فوق را می توانید در قسمت سوم از سلسله آموزش های این مجموعه پیگیری کنید.
فقط لازمه بگم وقتی شما IIS را بر روی خود CA سرور نصب کنید گاهی وقتا پارامترهای AIA and CDP بخوبی کار نمی کنند و Unable to Download را نشان می دهند که برای رفع این مشکل باید Directory Browsing را فعال کنید:
آموزش ایجاد Alias CNAME برای پارمترهای AIA/CDP
بعد از انجام مراحل فوق ما باید یک Alias CNAME برای پارامترهای AIA/CDP ایجاد کنیم.
در این سناریو این Alias CNAME بصورت زیر می باشد:
http:// PKI.Mahshaher.Com
این Alias CNAME به Web Server اشاره دارد که در این سناریو IP آن می شود 192.168.100.103
آموزش نصب Standalone Offline Root CA
در این مرحله باید Root CA را نصب کنیم. برای اینکار به Server Manager رجوع کنید و این سرویس را بصورت Stand-alone نصب کنید. در حین نصب شما باید مدت زمان Root Ca’s Certificate را مشخص کنید که در این سناریو بر روی 20 سال تنظیم شده است.
نکته: برای نصب این سرویس به قسمت دوم این سلسله آموزشی رجوع کنید.
بعد از نصب Root CA یکسری تنظیماتی هستش که شما باید آنها را انجام دهید. این تنظیمات شامل:
- کپی کردن Root CA’s Certificate and Root CRL list به پوشه CertEnroll
- تنظیم کردن پارمترهای ValidityPeriodUnits و ValidityPeriod
- Map کردن اسم Forest به Root CA.
- تنظیم پارامترهای AIA and CDP
- تنظیم کردن CRLPeriod
در مرحله اول باید اسم Forest را به این Root CA مپ کنیم برای اینکار دو دستور زیر را با مجوز Administrator اجرا کنید:
Certutil -setreg CA\DSConfigDN "CN=Configuration,DC=mahshaher,DC=local" certutil -setreg ca\DSDomainDN “DC=DC,DC=mahshaher,DC=local”
ما از اسم های این سناریو استفاده کردیم.
بعد از آن سرویس adcs را ریستارت کنید.
قدم بعدی تنظیم تنظیم کردن پارمترهای ValidityPeriodUnits و ValidityPeriod می باشد. تا جائی که من دیدم در بیشتر آموزشهای فارسی این دو پارامتر را از قلم می اندازند. خب این دو پارامتر چی هستن؟؟؟
CA Server وقتی بصورت Stand-alone نصب می شود Certificateها را با مدت زمان یک سال صادر می کند (Lifetime Certificate) و وقتی که یک سال این Certificate به اتمام رسد شما باید این Certificate را Renew کنید که مستلزم Online کردن Root CA می باشد. فکر نکنم کس باشه که دوست داره هر سال Root CA را انلاین کنه؟ پس در نتیجه ما باید به Root CA بگیم که Certificateها را با طول عمر بیشتری صادر کند. در این سناریو ما این پارامتر را بر روی 10 سال ست می کنیم. برای اینکار دو دستور زیر را بر روی Root CAاجرا کنید:
Certutil -setreg CA\ValidityPeriodUnits 10 Certutil -setreg CA\ValidityPeriod "Years"
سرویس adcs را ریستارت کنید.
قدم بعدی باید AIA/CDP را تنظیم کنیم. (در تنظیم این دو پارامتر نهایت دقت را به خرج دهید)
برای تنظیم AIA از دستور زیر استفاده کنید:
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pki.mahshaher.com/CertEnroll/%1_%3%4.crt"
برای تنظیم CDP از دستور زیر استفاده کنید:
certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:http://pki.mahshaher.com/CertEnroll/%3%8%9.crl"
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید. (تنها پارامتری که در این دستورات نیاز دارید تعقیر دهید فقط http می باشد. تا اخر این آموزش اینو یادتون باشه)
در آخر سرویس adcs را ریستارت کنید. دوستان دو دستور بالا دو مخزن در CDP and AIAایجاد می کند:
- مخزنی که بر روی Root CA ذخیره شده است.
- و مخزنی که بصورت http و به Alias CNAME که قبلا ایجاد کردیم اشاره دارد.
در نهایت شما باید مقدار CRLPeriod را تنظیم کنید. CRLPeriod چی هستش؟؟؟
شما بوسیله این پارامتر تعیین می کنید کی و چه وقت لیست CRLمربوط به Root CA اکسپایرشود. (با Expire شدن این لیست Root CA باید Online شود و دوباره CRL را رفرش کند.)
برای تنظیم این مقدار از کانتینر Revoked Certificate یک Properties بگیرید:
همانطور که می بینید بر روی 10 سال ست کردیم تا هر 10 سال یکبار CRL این CA اکسپایر شود. پس چرا Delta CRL را غیرفعال کردیم؟؟؟ کار Delta CRL چی بود؟؟؟
اخرین تعقیراتی که پس از انتشار Base CRL ایجاد می شد را در خود نگهداری می کند. و چون Root CA به CA Serverهای محدودی Certificate صادر می کند و هر 10 سال یک بار لیست Base CRL را منتشر میکند. فعال کردن این گذینه معقول نیست.
بعد از انجام مراحل بالا لیست CRL را بوسیله مراحل زیر منتشر یا Publish کنید:
مهمترین مرحله:
محتویات پوشه زیر را در پوشه CertEnroll در Web Server کپی کنید.
C:\Windows\System32\CertSrv\CertEnroll
خب الان Root CA را بگذارید روشن باشه بریم سراغ پیکربندی Intermediate CA
آموزش نصب Standalone Offline Intermediate CA
مراحل نصب این سرویس مانند Root CA می باشد با این تفاوت که مدت زمان Intermediate CA’s Certificate بر روی 10 سال (در این سناریو) ست می شود. و یک درخواست برای Root CA ایجاد می شود.
Next کنید و Setup را به پایان برسونید. مراحلی که شما باید در Intermediate CA انجام دهید:
- کپی کردن Intermediate CA’s Certificate and it’s CRL list به پوشه CertEnroll
- نصب Root CA’s Certificate and Root CA CRL list بر روی Intermediate CA
- تنظیم کردن پارمترهای ValidityPeriodUnits و ValidityPeriod
- Submitکردن درخواست Intermediate CA به Root CA
- مپ کردن Forest name بر روی Intermediate CA
- تنظیم پارامترهای AIA and CDP
- تنظیم CRLPeriod
در اولین قدم Root CA’s Certificate و Root CA CRL را بر روی Intermediate CA کپی کنید و در مسیری که این فایلها را کپی کردید دستورات زیر را اجرا کنید:
certutil -addstore -f root "Root-CA_Mahshaher-Root-CA.crt" certutil -addstore -f root "Mahshaher-Root-CA.crl"
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید.
قدم دوم مپ کردن Forest name بر روی Intermediate CA می باشد.
Certutil -setreg CA\DSConfigDN "CN=Configuration,DC=mahshaher,DC=local" certutil -setreg ca\DSDomainDN “DC=DC,DC=mahshaher,DC=local”
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید.
قدم بعدی تنظیم کردن پارمترهای ValidityPeriodUnits و ValidityPeriod
Certutil -setreg CA\ValidityPeriodUnits 5 Certutil -setreg CA\ValidityPeriod "Years"
در Root CA این مقدار را ما بصورت 10 سال تنظیم کردیم ولی در Intermediate CA ما Certificate را با طول عمر 5 سال به Issuing CA صادر می کنیم.
قدم بعدی تنظیم پارامترهای AIA and CDP می باشد.
(AIA) certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pki.mahshaher.com/CertEnroll/%1_%3%4.crt"
(CDP) certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n10:http://pki.mahshaher.com/CertEnroll/%3%8%9.crl"
فک نکنم توضیح خاصی بخاد. قدم بعدی تنظیم CRLPeriod می باشد.
توضیح دادم
قدم بعدی Publish کردن CRL می باشد. برای اینکار همانند Root CA از کانتینر Revoked Certificates یک Properties بگیرید و گذینه Publish را کلیک کنید و در آخر New CRLرا انتخاب و OK کنید.
مهمترین مرحله:
به مسیر زیر بروید و محتویات آن را در پوشه CertEnroll که بر روی Web Server می باشد کپی کنید.
آخرین مرحله Submit کردن درخواست Intermediate CA به Root CA می باشد.
هنگام نصب Intermediate CA در مراحل Setup که در بالا نشان دادم یک درخواست در درایو C بر روی Intermediate CA ایجاد شد. این فایل را به Root CA منتقل کنید.
بر روی Root CA مراحل زیر را انجام دهید:
فایلی که در Root CA کپی کردید را به بهش معرفی کنید. بعد از Open کردن یک Certificate در کانتینر Pending ایجاد می شود. آن Certificate را Issue کنید. (اگر با این مراحل اشنائی ندارید به آموزش های قبلی رجوع کنید)
وقتی Certificate را Issue کردید به کانتینر Issuing Certificates بروید و آن Certificateرا با کلید خصوصی Export کنید.
در تصویر بالا سرتیفیکتهای که با Request ID=4,5 هستن ذهن شما را مشوش نکنند. اینها مربوط به تمرین های من هستتش که خواستم تاثیراتی که بعد از Renew کردن Root CA’s Certificate اتفاق می افتد را ببینم.
وقتی که Certificate را Export کردید آن را به Intermediate CA منتقل کنید.
بعد از انتقال، مراحل زیر را در Intermediate CA انجام دهید.
بعد از انتخاب Install CA Certificate باید فایلی که کپی کرید را معرفی و Ok باید بدون هیچ مشکلی Intermediate CA استارت شود. در این مرحله می توانید با خیال راحت Root CA را خاموش کنید. بریم برای تنظیم Issuing CA
آموزش نصب Enterprise Mahshaher-Issuing-CA
این سرویس را در مد Enterprise و بصورت Subordinate نصب کنید. و مدت زمان CA’s Certificate آن را بر روی 5 سال ست کنید. (در این سناریو)
نکته: فقط سروری که به دومین Join شده یا بر روی خود DC است می تواند بصورت Enterprise نصب شود.
در پروسه نصب باید محل ذخیره سازی درخواستی که برای Intermediate CA ایجاد می شود را مشخص کنید.
Next کنید و Setup را کامل کنید. کارهای که باید در Mahshaher-Issuing-CA انجام دهیم:
- نصب Root CA’s Certificate و Root CA CRL بر روی Issuing CA
- کپی کردن Mahshaher-Issuing-CA’s Certificate به پوشه CertEnroll
- Publish کردن Root CA’s Certificate در کل Forest
- Submit کردن درخواست Issuing CA به Intermediate CA
- Publish کردن CRL List
- تنظیم کردن AIA/CDP
ما چنتا کار که قبلا بر روی Root CA and Intermediate CA انجام می دادیم را تنظیم نمی کنیم. می دونید چرا؟؟؟؟
نیازی به مپ کردن اسم Forest نداریم چون داریم CA را بر روی DC و در محیط دومین نصب می کنیم.
نیازی به تنظیم کردن پارمترهای ValidityPeriodUnits و ValidityPeriod نیست چون این مقادیر در خود Template Certificate تنظیم می شوند
نیازی به تنظیم کردن CRLPeriod نیست چون این Issuing CA می باشد و با کاربر در تعامل می باشد و شاید روزانه چندین Certificate بنا به دلایلی باطل شود. در نتیجه تنظیمات پیش فرض آن مناسب می باشد.
خب اولین کارمون نصب Root CA’s Certificate و Root CA CRL در Issuing CA می باشد. برای اینکار دستورات زیر را اجرا کنید:
certutil -addstore -f root "Root-CA_Mahshaher-Root-CA.crt" certutil -addstore -f root "Mahshaher-Root-CA.crl"
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید.
قدم دوم Publish کردن Root CA’s Certificate در کل Forest. برای اینکار از Group Policy استفاده کنید.
و Root CA’s Certificate را Import کنید.
قدم بعدی تنظیم کردن AIA/CDPمی باشد. برای اینکار دستورات زیر را بر روی Issuing CA اجرا کنید.
نکته: دستورات پایین با دستورات قبلی که بر روی Root CA and Inter.. اجرا می کردیم یکسان نیست. با اجرای دستورات زیر ما دو مخزن به علاوه مخازن موجود، اضافه خواهیم کرد. یک مخزن مربوط به LDAP هستش و یکی پوشه شیر CertEnroll که بر روی Web Server می باشد.
(AIA) certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.mahshaher.com/CertEnroll/%1_%3%4.crt"
(CRL) certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://pki.mahshaher.com/CertEnroll/%3%8%9.crl\n65:file://\\dc.mahshaher.local\CertEnroll\%3%8%9.crl"
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید. (فقط پارامترهای http and file مربوط به سازمان خود را تعقیر دهید)
بعد از اجرای دستورات فوق سرویس adcs را ریستارت کنید.
قدم بعدی که خیلی مهمه کپی کردن Mahshaher-Issuing-CA’s Certificate به پوشه CertEnroll می باشد.
حتما تعجب کردید که چرا CRL لیستها را کپی نکردیم؟؟؟؟ برای جواب این سوال باید به تصویر زیر نگاه کنید:
در بالا ما در قسمت CRL Period تعریف کردم که بعد از گذشتن 1 هفته لیست CRL این CA Server را در مسیرهای بالا ذخیره کنه. ما در بالا چه مسیرهای داریم؟؟ http, Ldap and File پارمتر File به پوشه شیر شده CertEnroll اشاره دارد یعنی اگر ما الان CRL را Publish کنیم این لیستها بصورت اتوماتیک به این پوشه شیر شده کپی میشه. (فعلا چیزی رو Publish نکنید). قدم بعدی Submit کردن درخواست Mahshaher-Issuing-CA به Intermediate CA می باشد. به درایو C بروید و فایل درخواست این CA را به Intermediate CA منتقل کنید. و مراحل زیر را در Intermediate CA انجام دهید:
بعد از کلیک کردن گذینه بالا پنجره ی باز می شود و از شما فایل در خواست Mahshaher-Issuing-CA را می خواهد. بعد از معرفی کردن فایل و Open کردن Certificateی در کانتینر Pending Certificates ایجاد می شود.آن را Issue کنید. بعد از Issue کردن این Certificate آن را به همراه کلید خصوصی آن Export کنید. و در نهایت فایل Export شده را به Mahshaher-Issuing-CA منتقل کنید. بعد از انتقال این Certificate، آن بر روی Mahshaher-Issuing-CA نصب کنید. (تمام این مراحل را با تصویر در قسمت Intermediate CA توضیح دادم) در لحظه استارت شدن سرویس Mahshaher-Issuing-CA شاید با هشدار زیر رو به رو شوید:
در حال حاضر این سرویس قادربه برسی لیستهای CRL سرورهای قبلی نیست. نگران نباشید و برای ادامه OK کنید. بعد از استارت شدن سرویس Issuing CA لیستهای CRL این سرویس را Publish کنید.
اگر در هنگام Publish کردن CRL هر گونه اخطاری دریافت کردید بدانید و آگاه باشید که D: پارامترهای CDP را بصورت صحیح تنظیم نکردید. یه سری به پوشه CertEnroll که آن را شیر کردید بزنید و از کپی شدن لیست CRL این سرور مطمئن شوید.
آموزش نصب Enterprise Ahvaz-Issuing-CA
این سرویس را در مد Enterprise و بصورت Subordinate نصب کنید. و مدت زمان CA’s Certificate آن را بر روی 5 سال ست کنید. (در این سناریو)
کارهای زیر را بر روی این سرور انجام دهید:
- نصب Root CA’s Certificate بر روی Ahvaz-Issuing-CA
- Publish کردن Root CA’s Certificate در دومین Ahvaz.Mahshaher.Local
- تنظیم کردن مقادیر CDP/AIA
- Submit کردن درخواست Ahvaz-Issuing-CA به Intermediate CA
- انتقال Ahvaz-Issuing-CA’s Certificate and it’s CRL List به پوشه CertEnroll شیر شده بر روی Web Server.
بیشتر کارها که قراره بر روی این سرورانجام دهیم تکراریه ولی توضیح می دهم.
Root CA’s Certificate و Root CRL list را بوسیله دو دستور زیر بر روی Ahvaz-Issuing-CA نصب کنید.
certutil -addstore -f root "Root-CA_Mahshaher-Root-CA.crt" certutil -addstore -f root "Mahshaher-Root-CA.crl"
برای Publish کردن Root CA’s Certificate در دومین Ahvaz.Mahshaher.Local از Group Policy استفاده کنید.
قدم بعدی تنظیم کردن مقادیر CDP/AIA
دودستور پایین مخازنی مانند Mahshaher-Issuing-CA در Ahvaz-Issuing-CA ایجاد می کند.
(AIA) certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.mahshaher.com/CertEnroll/%1_%3%4.crt"
(CRL) certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://pki.mahshaher.com/CertEnroll/%3%8%9.crl\n65:file://\\dc.mahshaher.local\CertEnroll\%3%8%9.crl"
از پامترهای مخصوص سازمان خود در دستورات بالا استفاده کنید.فقط پارامترهای http and file مربوط به سازمان خود را تعقیر دهید.
بعد از اجرای دستورات فوق سرویس adcs را ریستارت کنید.
نکته مهم: در صورتی از پارمتر File در CDP استفاده کنید که ارتباط لایه دوبا دومین ماهشهر داشته باشید. قدم بعدی Submit کردن درخواست Ahvaz-Issuing-CA به Intermediate CA سه بار این پروسه را در این مقاله توضیح دادم فکر نکنم لازم باشه توضیح بدم که چکاری باید انجام دهید. وقتی که سرویس این سرور ران شد Ahvaz-Issuing-CA’s Certificate را به پوشه CertEnroll در Web Server منتقل کنید. الان لیست CRL را Publish کنید. باید مطمئن شوید لیستهای CRL این سرور در پوشه Certenrll کپی شده باشه. اینم پوشه CertEnroll ما در این سناریو:
به احتمال زیاد پوشه شما Certificateها و لیستهای CRL کمتری نسبت به پوشه بالا داره. ( تست های زیادی انجام دادم که اینطور زیاد شدن D: در این مرحله شما می توانید Intermediate CA را خاموش و از مدار خارج کنید.
آموزش نصب و تنظیم OCSP سرور
خب ما در این سناریو OCSP را در دومین Ahvaz.mahshaher.local نصب خواهیم کرد. کارهای که ما باید بر روی این سرور انجام دهیم: OCSP را به دومین ahvaz.mahshaher.local جوین کنید. (در این سناریو)
نصب سرویس OCSP
ایجاد A Record برای این سرویس در DNS Server
ایجاد سرتیفیکت تمپلیت OCSP Response Signing بر روی دو سرور Mahshaher-Issuing-CA و Ahvaz-Issuing-CA
ایجاد دو Revocation Configuration بر روی OCSP یکی برای Mahshaher-Issuing-CA و یکی برای Ahvaz-Issuing-CA.
ایجاد URL سرویس OCSP در تنظیمات مربوطه به AIA برروی هر دو سرور Mahshaher-Issuing-CA و Ahvaz-Issuing-CA
تمام مراحل فوق را من در قسمت چهارم از این سری آموزش توضیح دادم. به آن قسمت رجوع کنید.
آموزش تست ساختار CA Hierarchy
ابزار pkiview.msc را در یکی از DC ها اجرا کنید و چک کنید تمام پارامترهای مربوط به AIA/CDP با وضعیت OK نشان داده شود.
در همان کنسول بالا بر روی Enterprise PKI راست کلیک کنید و گذینه Manage AD Containers را انتخاب کنید و پرامترهای زیر را چک کنید که در وضعیت OK باشند.
الان توسط ابزار زیر AIA, CDP and OCSP را چک کنید. (در مورد نحوه کار کردن این ابزار به قسمت چهارم این سری آموزش رجوع کنید.)
الان یک Windows 10 نصب و جوین یکی از دومین ها کنید و سعی کنید از دو Issuing-CA درخواست Certificate بدید.
در مرحله آخر یک Certificate را Export کنید و در درایو C ذخیره کنید و دستور زیر را اجرا کنید:
certutil -verify -urlfetch c:\test.cer
خروجی دستور را چک کنید و مطمئن شوید تمام مسیر Certificate path بصورت successfully باشد.
خب دوستان اینم از ساختار سلسله مراتبی PKI امیدوارم مشکلات و ابهاماتی که دوستان در راه اندازی چنین ساختاری دارن رفع شده باشه و بتونن حداکثر استفاده از این سرویس مهم و قوی را داشته باشند.
برای سناریوی بالا من حداقل یک هفته مطالعه و تمرین داشتم و تا جائی که می توانستم ریزترین جزئیات آن را برای شما توضیح دادم. مطمئنم شما همین سناریو با کمی تفاوت را می توانید در دنیای واقعی راه اندازی کنید.
در قسمت های بعدی قابلیتهای جدیدی که در Win Server 2008 ارائه شده به نام Certificate Enrollment Policy Web Service و Certificate Enrollment Web Service را آموزش خواهم داد.
در این قسمت متد Cross-forest Certificate Enrollment را بصورت خلاصه برسی و آموزش میدهیم.
Cross-forest Certificate Enrollment چیست؟
سازمانهای Enterprise که دارای چندین (AD DS) Forest می باشند یک PKI بصورت مرکزی بر روی یکی از Forestها راه اندازی می کنند و توسط یکی از CA Server ها آن Forest می توان به سایر Forestها Certificate صادر کرد.
Cross-forest enrollment enables enterprises to deploy a central PKI in one Active Directory Domain Services (AD DS) forest that issues certificates to domain members in other forests.
این روش باعث کاهش تعداد CA Serverها در بقیه Forest ها می شود. و همچنین می توان از یک نقطه مرکزی ساختار PKI را مدیریت کرد.
نکته: با امدن Windows Server 2008 R2 قابلیتی بوجود آمد به نام Certificate Enrollment Web Services که بوسیله آن می توان روش بالا را بدون رابطه Trust بین Forestها برای Forestهای دیگر و کاربران اینترنت پیاده سازی کرد. در آموزش بعدی آن را برسی می کنیم.
پیش نیازهای Cross-forest Certificate Enrollment:
- یک رابطه Trust بصورت Two-way بین Forestها.
- نصب یک Enterprise CA Server بر روی Resource Forest.
- و سیستم عاملهای که این روش را ساپورت کنند. این OS شامل:
- Windows XP
- Windows Server 2003
- Windows Vista
- Windows Server 2008
- Windows 7
- Windows Server 2008 R2
- Windows Server 2012 & R2
- Windows 10
نکته: برای پیاده سازی این روش حتما باید Enterprise CA Server داشته باشید در این روش Stan-alone CA Server ساپورت نمی شود.
ما در این روش دو اصطلاح داریم که دانستن آنها ضروریه:
Resource forest: فارستی که Enterprise CA را میزبانی می کند و به بقیه Forestها Certificate صادر می کند.
Account Forest: فارستی که از Resource Forest سرویس دریافت می کند.
- :Example scenario
در سیستم عاملهای که این روش را ساپورت نمی کنند می توانند از توپولوژی زیر استفاده کنند.
پیاده سازی Cross-forest Certificate Enrollment در ساختارهای Enterprise
برای اموزش این روش دو Forest یکی به نام Mahshaher.Local و دیگری Tehran.Local ایجاد و بین آنها یک رابطه Trust بصورت Two-way ایجاد کردم.
Create a Two-Way, Forest Trust for Both Sides of the Trust
https://technet.microsoft.com/en-us/library/cc816590(v=ws.10).aspx
نکته: برای راحتی کار در قسمت Outgoing Trust Authentication Level--Local Forest گذینه Forest-wide authentication. را انتخاب کنید. وگرنه:
مرحله بعدی نصب Enterprise CA بر روی Mahshaer.Local می باشد. برای اینکار به قسمت دوم این سری آموزش رجوع کنید.
مرحله بعدی فعال کردن LDAP referral می باشد. به لطف LDAP referral هستش که ما می توانیم از روش Cross-forest Certificate Enrollment استفاده کنیم.
برای فعال کردن LDAP referral دستور زیر را بر روی Enterprise CA اجرا کنید:
certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
قدم بعدی اضافه کردن Enterprise CA Computer Account در گروه Cert Publisher مربوط به Account Forestها می باشد.
قدم بعدی تنظیم کردن مخازن AIA/CDP می باشد. این مخازن را جوری تنظیم کنید که Account Forest ها بتوانند به این مخازن دستری داشته باشند. برای اطلاع بیشتر به قسمت سوم رجوع کنید.
مرحله بعدی Publishکردن Root CA’s Certificate (در سناریوهای که ساختار PKI بصورت سلسله مراتبی داشته باشید) و Enterprise Ca’s Certificate در Account Forestها می باشد. در این سناریو Root CA’s Certificate and Enterprise CA’s Certificate را به Tehran.Local منتقل می کنیم ودستورات زیر را وارد می کنیم:
certutil -dspublish -f RootCA certutil -dspublish -f NTAuthCA certutil -dspublish -f SubCA
اطلاعات Certificate در Active Directory در سه جای مهم ذخیره می شود:
- Enrollment services
- Certificate templates
- OID
در مرحله بعدی ما باید این سه کانتینر را در Account Forest کپی کنیم. قبلی از اینکار ما باید به ادمین فارست Mahshaher.Local این مجوز را بدهیم. برای اینکار کاربر Administrator یا گروه Domain Admins فارست Mahshaher.local را در Local Administrators دومین کنترولر Tehran.local عضو می کنیم.
بعد از مجوز دادن به کاربر ادمین بوسیله اسکریپت محتویات این سه کانتینر را در Account Forest کپی می کنیم. برای اطلاعات بیشتر درباره اسکریپت ونحوه ایجاد آن لینک زیر را بخوانید:
https://technet.microsoft.com/en-us/library/ff961506(v=ws.10).aspx
بعد از ایجاد اسکریپت دستور زیر را بر روی تک تک Account Forestها اجرا کنید:
./PKISync.ps1 -sourceforest -targetforest -f
نکته: یکی از عیب های این روش ( نمیشه اسمشو عیب گذاشت ولی خب یک جور دردسر زیادی برای ادمین حساب میشه) با تعقیر محتویات این سه کانتینرادمین دوباره باید محتویات این کانتینرها را در Account Forestها کپی کند. در شرایط عادی وقتی لازم میشه این کانتینرها را کپی کنید که یک Certificate Template جدید ایجاد کنید.
برای اتوماتیک کردن پروسه بالائی لینک زیر را بخوانید:
https://technet.microsoft.com/en-us/library/ff955844(v=ws.10).aspx
مرحله بعد باید به گروه های Domain Users and Domain Computers های Account Forest بر روی CA Server مجوز Request Certificate دهیم:
قدم بعدی (اختیاری) قابلیت AutoEnrollmet را برای Account Forestها فعال کنید. برای فعال کردن این قابلیت به قسمت ششم این سری آموزش مراجعه کنید.
و مرحله آخر ایجاد Certificate Template برای Account Forestها می باشد. برای اطلاع بیشتر درباره ایجاد Certificate Template به قسمت ششم مراجعه کنید.
- نتیجه تنظیمات:
در این قسمت مفهوم و کاربرد Certificate Enrollment Policy Web Services را برسی می کنیم. Certificate Enrollment Policy Web Services به دو رول زیر اشاره دارد:
- Certificate Enrollment Policy Web Service (CEP)
- Certificate Enrollment Web Service (CES)
در مرحله اول مفاهیم و کاربرد هر کدام از این رولها را برسی می کنیم.در ابتدا باید بگم این دو رول با آمدن Windows Server 2008 R2 ایجاد شده اند و امکانات خارق العاده به سرویس AD CS اضافه کردن.
Certificate Enrollment Policy Web Service چیست؟
CEP یکی از رول های AD CS می باشد که User and Computer ها را قادر می سازد اطلاعات و سیاستهایcertificate enrollment را بدست آورند. اگر این رول را با رول Certificate Enrollment Web Service نصب کنید کاربران خارج از سازمان مانند کاربران اینترنت را قادر می سازد عملیات Certificate Enrollment را انجام دهند.
CEP درخواستها را بوسیله https از کاربران دریافت می کند و با استفاده از پروتکل LDAP به Domain Controller وصل می شود و اطلاعات را استخراج می کند و به کلاینتها بر می گرداند. در نسخه های قبلی AD CS فقط کاربرانی که عضو Domain بودن می توانستن از LADP استفاده کنند و سیاستهای Certificate Enrollment را از DC بدست آورند. ولی با امدن این رول کاربران خارج از سازمان و کاربرانی که عضو دومین نیستن می توانند به این اطلاعات دسترسی داشته باشند. شما با Publish کردن این رول قادر خواهید بود:
- از قابلیت Cross-forest Certificate Enrollment بدون ایجاد Trust بین Forestها استفاده کنیم. برای اشنائی و استفاده از قابلیت فوق به قسمت یازدهم مراجعه کنید.
- کاربران اینترنت مانند موبایلها و بقیه دیوایسها می توانند از خدمات PKI سازمان بهره مند شوند.
شاید یکی سوالی داشته باشه که سیاستهای های PKI که این رول آنها را استخراج می کند چیست؟ این سیاستها نحوه جواب دادن CA به کاربران و نحوه Enroll کردن Certificate ها و Certificate Templateها را مشخص می کند. و همچنین یک سری قوانین برای اثبات یک CA مورد اعتماد برای کاربران وضع می کند. و چه Certificate ی می توان آنها را درخواست کرد و چه CA Server های می توانند چنین Certificate های را ارئه دهند.
Certificate Enrollment Policy Web Service چیست؟
CES همانند CEP می باشد که بوسیله پروتکل https درخواست Certificate را از کاربران دریافت می کند و بوسیله پروتکلDCOM درخواستها را به CA Server واگذار می کند. در نسخه های قبلی فقط کاربران عضو دومین می توانستند از DCOM استفاده کنند. ولی با امدن این قابلیت کاربران خارجی می توانند از خدمات PKI استفاده کنند.
فرق بین Certification Authority Web Enrollment و Certificate Enrollment Web Services در چیست؟
CA Web Enrollment اولین بار در Windows 2000 ارائه شده و کاربر را قادر می سازد که بوسیله یک Web Page که با ادرس https://Your-Server/certsrv قابل دسترس می باشد درخواست خود را در این سرویس اپلود کنند و پارمترهای مختلفی از قبیل لیست CRL و CA’s Certificate را دانلود کنند.CA web enrollment بوسیله یک مرورگر هم زمان می تواند فقط به یک کاربر سرویس دهد و برای اینکار نیاز به تنظیمات و پیش نیازی ندارد. در ضمن یکی از عیب های این سرویس دستی بودن درخواست ها توسط کاربران می باشد.
مثلا اگر کاربری اطلاعات کافی از این سرویس ندارد نمی تواند از این سرویس استفاده کند. ولی Certificate Enrollment Web Services بیشتر بر روی اتومات کردن این پروسه فکوس کرده و کاربر و Application ها می توانند بصورت اتوماتیک درخواست Certificate دهند.Certificate Enrollment Web Services و Certification Authority Web Enrollment هر دو از پروتکل https برای اتصال با کاربران استفاده می کنند، و برای استفاده از Certificate Enrollment Web Services نیازمند Windows 7 به بالا می باشد.
مزایای استفاده از Certificate Enrollment Web Services چیست؟
استفاده از CEP//CES دو مزیت رو به ارمغان میاورد:
- Forest Consolidation
- Perimeter network certificate enrollment
در نسخه های قبل از Win 2088 R2 در سازمانهای که چندین AD DS Forest دارند برای اتومات کردن Certificate Enrollment باید در هر فارست یک Enterprise CA Server نصب کرد که هزینه و مدیریت زیادی مطلبد و همچنین هر Forest نیازمند Certificate Template های خود و همچنین نیازمند ایجاد یک Trust از نوع Two-way بین فارست بود. (در two tier PKI)
با امدن رول های Certificate Enrollment Web Services چنین سازمانهای می توانستند بدون ایجاد Trust و با نصب یک Enterprise CA Server در یکی از فارستها به مقصود خود برسند.
قبل از Win 2008 R2 برای اینکه کاربران بتوانند از قابلیت Certificate Enrollment بصورت اتومات استفاده کنند نیازمند این بودند که بصورت مستقیم به شبکه سازمان متصل باشند و عضو دومین شوند. با امدن قابلیت Certificate Enrollment Web Services و قرار دادن این سرورها در قسمت DMZ شبکه کاربران خارج از سازمان و کاربرانی که بصورت مستقیم به شبکه سازمان متصل نیستد می توانند از قابلیت Certificate Enrollment بصورت اتوماتیک استفاده کنند.
در قسمت بعدی یکی از ویژگی های جدید که در Windows Server 2012 معرفی شده به نام Key Based Renewal را برسی می کنیم.
در این قسمت قابلیت Key Based Renewal را برسی می کنیم.قابلیت Key Based Renewal اولین بار در Windows Server 2012 معرفی شده است. این قابلیت باعث می شود کاربرانی که عضو دومین نیستند بصورت اتوماتیک Certificateهای خود را Renew کنند.برای اطلاع بیشتر درباره Renew کردن Certificate ها به قسمت هفتم از این سری آموزشی مراجعه کنید.
شاید بپرسید چرا ا برای این پروسه نیازمند این قابلیت هستیم؟
جواب : برای اینکه Subject ها بصورت اتومات بتوانند Certificate های خود را Renew کنند CA Server نیازمند اطلاعات مهمی می باشد. هویت درخواست کنند، ایا این درخواست کنند در خود سازمان فعالیت می کند یا در فارست های دیگر، مجوز این کار را دارد یا نه و ....
در درون سازمان تمام این اطلاعات بوسیله متد احزاز هویت ویندوز به نام Windows Integrated قابل دستیابی می باشد. ولی متاسفانه این متد برای کاربران خارج از سازمان کارائی ندارد. پس Key Based Renewal از دارنده خود Certificate و بوسیله خود Certificate آن Subject را احراز هویت می کند. در تعریف دیگر هویت هر Subjectی Certificate ی می باشد که دارد.
هر Subjectی که توانائی دسترسی به کلید خصوصی خود دارد می تواند قبل از Expire شدن Certificate آن را Renew کند.
اجازه بدید یک نگاهی به نیازمندی ها و تنظیمات این قابلیت بیندازیم تا بهتر این قابلیت را درک کنیم.
پیش نیازهای Key Based Renewal در تنظیمات Certificate Template ها
اولین تنظیمی که بر روی Certificate Template ها انجام می شود فعال کردن گذینه زیر می باشد:
با فعال کردن گذینه زیر این قابلیت بر روی Certificate Template فعال می شود و Subjectهای که این Certificate بر روی آنها اعمال می شود می توانند بصورت اتوماتیک Certificate های خود را Renew کنند.
نکته: قبل از اعمال تنظیمات بالا تنظیمات تب Subject Name را انجام دهید. (در زیر آمده است) بدون تنظیم آن تب گذینه های فوق فعال نمی شوند.
نکته بعدی: علاوه بر تنظیمات بالا شما باید مجوز لازم برای کاربران خارج از سازمان در تب Security اعمال کنید.
شما با فعال کردن گذینه بالا به Certificate Template اجازه می دهید که از پارمترهای که بر روی آن ست می شود بعنوان Subject Name استفاده شود.
به علت اینکه خود Certificate هویت درخواست کنند را مشخص می کند ما باید Client Authentication را بر روی این Certificate Template اضافه کنیم.
تنظیمات بالا پیش نیازهای پیاده سازی این قابلیت بود که برای اطلاع بیشتر درباره تنظیمات Certificate Template به قسمت ششم از این سری آموزش رجوع کنید.
علاوه بر تنظیمات بالا ما باید به Certificate Enrollment Policy دسترسی داشته باشیم. و همانطور که می دانید نمی توانیم از حالت پیش فرض Certificate Enrollment Policy استفاده کنیم چون استفاده از LDAP نیازمند عضو بودن در دومین هستش. (بوسیله LDAP اطلاعات Subject از AD استخراج و هویت Subject ها مشخص می شود)
پس آن چیزی که ما نیاز داریم استفاده از سرویس Web Enrollment Policy Service /CEP می باشد که در قسمت دوازدهم آن را برسی کردیم.
نیازمندی های Key Based Renewal در Certificate Enrollment Policy Service
همانطور که می دانید کاربران خارج از سازمان نمی توانند از متد Windows Integrated استفاده کنند پس ما نیازمند متدی برای احراز هویت Subjectهای خارج از سازمان هستیم که علاوه بر متد Windows Integrated دو متد دیگر برای اینکار داریم:
- Username/Password
- Client Certificate
درباره Client Certificate قبلا توضیح دادیم و متد Usernamepassword هم کاربران با وارد کردن User Pass خود می توانند خود را در CEP احراز هویت کنند.
و همچنان نیازمند فعال کردن این قابلیت بر روی CEP هستیم
نیازمندی های Key Based Renewal در Certificate Enrollment Web Service /CES
هنگامی که شما سرویس CES را نصب و تنظیم می کنید می توانید آن را برای Certificate Enrollment و Key Based Renewal تنظیم کنید یا می توانید آن را فقط در مد Renewal only mode تنظیم کنید.
Renewal only mode چیست؟
بخاطر اینکه سرویس CEP در ناحیه DMZ شبکه قرار دارد و برای ارتباط با CA نیازمند ایجاد Delegate با CA Server می باشد (آموزش بعدی مفصل توضیح خواهم داد) یک هکر می تواند از این تنظیمات به نفع خود استفاده کند و کارهای ناخواسته ای را انجام دهد، بخاطر همین دلیل ما می توانیم سرور CES را جوری تنظیم کنیم که فقط Certificate ها را Renew کند و کسی اجازه ندارد درخواست Certificate جدید دهد. (فقط Certificate های که قبلا بر روی Subjectها اعمال شده را Renew می کند.)
نکته: سرویس CES با استفاده از متد Client Certificate سابجکت ها را احراز می کند و سپس از اعتبار خود استفاده می کند و درخواست را به CA Server ارائه می دهد و پس از بازگشت جواب از طرف CA Server آن را به سمت آن Subject ارسال می کند.
قسمت بعدی انتخاب یک Service Account می باشد.اهمیت این قسمت را در بخش بعدی از این سری آموزش برسی می کنیم.
در تصویر زیر شما باید نوع احراز هویت را در CES بر روی Client Certificate Authenticate ست کنید.
نکته: نوع احراز هویت در CEP می تواند با نوع احراز هویت در CES فرق داشته باشد.
علاوه بر فعال کردن Key based renewal در CEP شما باید این قابلیت را در CES نیز فعال کنید.
در آخر به اینم اشاره کنم که اگر Certificateی که Kay based renewal بر روی آن فعال است بنا به دلایلی بخواهیم باطل کنیم، برای اینکار مراحل زیر را انجام دهید: (متنش آسونه)
- Remove the template that has key-based renewal enabled from each CA that is issuing the template.
- Revoke the appropriate certificates.
- Publish an updated CRL for each CA that was issuing the template that had key-based renewal enabled.
- Reissue the certificate template that has key-based renewal to the appropriate certification authorities for issuance.
در این آموزش ما اصطلاح وکاربرد Key Based Renewal را توضیح دادیم و همچنین Renewal-only mode را نیز توضیح دادیم و گفتیم کی از این قابلیت استفاده کنیم و همچنین پیشنیازهای Key based renewal را به شما نشان دادیم.
در آموزش بعدی ما ساختار و تنظیمات راه اندازی CEP/CES را برسی و اماده سازی می کنیم.
در این قسمت پیش نیازها و تنظیماتی که برای پیاده سازی CEP/CES لازم می باشد را برسی می کنیم.قبل از هر چیز بهتر است سناریو و کاربرد دو رول CESP/CES را توضیح دهیم.یکی از چالشهای سازمان های بزرگ که خود مسئول زیر ساخت کلید عمومی خود هستند صادر کردن و Renew کردن Certificate به کاربران خود در خارج از سازمان می باشد. با آمدن ویندوز سرور 2008 R2 مایکروسافت این مشکل بزرگ را با ارائه دو رول CEP/CES حل کرده است.
این دو سریس باعث می شود که کاربران خارج از سازمان بتوانند بصورت اتوماتیک درخواست Certificate دهند و بر روی خود اعمال کنند و با قابلیت Key Based Renewal که در آموزش قبلی آن را برسی کردیم بصورت اتوماتیک بتوانند Certificate های خود را قبل از Expire شدن Renew کنند.خب!!! برای پیاده سازی این دو سرویس باید مراحل زیر را طی کنیم:
- Installation Requirements
- CA Requirement
- Client Requirement
- Network Connectivity Requirement
- Firewall Requirement
- Authentication Method Consideration
- Delegation Requirement
- Renewal-only Mode Requirement
- Renewal Requirement
- Service Account Configuration
- پیش نیازهای نصب:
- برای نصب و کانفیگ این دو رول باید عضو گروه Enterprise Admin و Local Administrator بود.
- کامپیوتری که می خواهید یکی از این دور رول را بر روی آن نصب کنید باید عضو Domain باشد.
- FFL ساختار باید از Windows Server 2008 به بالا باشد.
- این دو رول باید بر روی Windows Server 2008R2 به بالا نصب شوند.
- اگر از قابلیت Key based renewal استفاده می کنید سرورCA باید Windows server 2012 به بالا باشند.
- می توان این دو رول را بر روی یک کامپیوتر نصب کرد.
- می توان این دو رول را بر روی هر نسخه ای از Windows Server 2008 R2 or Windows server 2012 نصب کرد.
- شما می توانید این دو رول را در Windows server 2012 بر روی مد Core Installation نصب کنید.
- این دو رول برای ارتباط از SSL/TLS یا https با کلاینتها استفاده می کنند. پس قبل از نصب شما باید Certificate ی که حاوی Server Authentication باشد بر روی آن کامپیوتر اعمال کنید.
- پیش نیازهای CA Server:
این پیش نیازها بر روی CA Serverی اعمال شود که ترافیک این دو رول به سوی آن هدایت می شود.
- در ساختار CES/CEP فقط از Enterprise CA Server پشتیبانی می شود.
- اگر کلاینتها از متد Client Certificate Authentication برای احراز هویت در CES استفاده کنند باید CA Server بر روی Windows Server 2008R2 نصب شود.
- اگر بر روی رول CES قابلیت Renewal-only mode فعال باشد CA Server باید بر روی Windows Server 2012 نصب شود.
- پیش نیازهای کلاینت ها
- برای استفاده از این دو رول سیستم عامل کلاینتها حتما باید Windows 7 به بالا باشند.
- اگر قابلیت Key-based renewal بر روی Certificate Template ها فعال باشد کلاینتها باید از Windows 8 به بالا استفاده کنند.
پیش نیازهای ارتباط کلاینتها با CESCEP و ارتباط CESCEP با AD DS and CA Server
یکی از مهمترین مراحل پیاده سازی این سناریو ارتباط همه یNode ها با هم دیگس مخصوصا که این دو رول در ناحیه DMZ شبکه قرار دارند. تمام ارتباطات کلاینتها با این سرویس ها از طریق پروتکل https صورت می گیرد. پس فقط ترافیک https 443 برای ارتباط کلاینتها با این دو رول لازم است. و ارتباط رول CEP با AD DS از طریق پروتکل LDAP or LDAPS و بوسیله پورت 389/636 انجام می شود و ارتباط CES با CA Server از طریق پروتکل DCOM صورت می گیرد که از پورتها بصورت تصادفی یا رندم استفاده می کند. گرچه شما می توانید این پورتهای رندم را در CA Server تنظیم و محدود کنید. برای اینکار لینک زیر را مطالعه کنید:
How to configure RPC dynamic port allocation to work with firewalls
https://support.microsoft.com/en-us/kb/154596
نیازمندی های Firewall
اگر بین رول CEP و AD DS فایروالی باشد شما باید پورتهای زیر را برای ارتباط این دو سرور تنظیم کنید:
Kerberos ports: 464, 440 LDAP ports: 389, 636
برای تنظیم Firewall برای رول CES شما باید CA Server را تنظیم کنید که از پورتهای مشخصی استفاده کند تا بتوان آن پورتها را بر روی Firewall تنظیم کرد.
برای تنظیم پورتهای CA Server لینک زیر را مطالعه کنید:
محدود کردن پورتهای RPC و عبور ترافیک Certificate Enrollment در TMG
- ملاحضاتی درباره نحوه احراز هویت در این سناریو:
در این سناریو ما سه نوع روش احراز هویت داریم:
- Windows integrated authentication
- Client certificate authentication
- Username and password authentication
اگه نخوام زیاد زوم کنم و توضیح بدم خلاصه کلام در روش Windows integrated authentication اینست که فقط برای کاربان عضو دومین کاربرد دارد. اگر رول CES/CEP را برای کاربران داخل سازمان پیاده سازی کردید از این متد استفاده کنید.
و اما متد Client certificate authentication. اگر Certificate ی بر روی کامپیوتری اعمال شود آن کامپیوتر می تواند از این متد استفاده کند. و همچنین این روش نیازمند اتصال کامپیوترها بصورت مستقیم با دومین نیستند. استفاده از این متد همراه متد Username and password authentication می تواند امنیت بهتری برای سازمان به ارمغان بیاورد. و بهتر بتوان کاربران بیرون از سازمان را احراز هویت کرد.
متد Username and password authentication که ساده ترین و کم امنیت ترین روش در این سناریو به حساب می آید. این روش نیازی به اعمال کردن Certificate بر روی کامپیوتر ندارد و برای کاربران خارج از سازمان کارائی دارد. بصورت خیلی ساده User & Pass را وارد می کنید و در CES احراز هویت می شوید.
- نیازمندی های Delegation:
این Delegation را با Delegationی که بر رویOU ها اعمال میشه اشتباه نگیرید. در اینجا Delegation به یک سرویس اجازه می دهد که به عنوان یک User Account or Computer Account وارد عمل شده و به منابع شبکه دسترسی داشته باشد.
برای اشنائی با Delegation مقاله زیر را دانلود و قسمت Delegating authentication را مطالعه کنید:
https://www.microsoft.com/en-US/download/details.aspx?id=53314
وقتی از Delegation استفاده می کنیم که شرایط پایین فراهم باشد:
- سرویس CES بر روی کامپیوتری غیر از CA Server نصب شده است.
- وقتی که کاربران بیرون از سازمان درخواست Certificate دهند. پروسه Certificate Enrollment
- وقتی از متد احراز هویت Windows integrated authentication and Client certificate authentication استفاده بشه.
Delegation برای شرایط پایین لازم نیست:
- CA Server و CES بر روی یک کامپیوتر نصب شده باشند.
- از متد احراز هویت Username and password authentication استفاده کنیم.
خب... اگر در هنگام کانفیگ این دو رول گذینه Use the built-in application pool identity را انتحاب کنید شما باید عملیات Delegation را بر روی Computer Accountی که CES را میزبانی می کند انجام دهید ولی اگر سرویس CES بر روی یک User Account اجرا شود شما در مرحله اول باید یک SPN برای آن User ایجاد کنید و بعد از Delegation را برای آن User تنظیم کنید.
برای ایجاد SPN برای یک User از دستور setspn استفاده می کنیم. برای ایجاد SPN برای Userی به نام CES و کامپیوتری با دامنه cpandl-ces1.cpandl.com دستور زیر را اجرا می کنیم:
setspn -s http/cpandl-ces1.cpandl.com cpandl\ces
نوع Delegation ی که شما باید تنظیم کنید بستگی به متد احراز هویت دارد:
- اگر از متد Windows integrated authentication استفاده کنید باید گذینه Use Kerberos only را انتخاب کنید.
- اگر از متد Client certificate authentication استفاده کنید باید گذینه Use any authentication protocol. را نتخاب کنید.
در آموزش آتی این تنظیمات را بصورت عملی نشان می دهیم.
- نیازمندی های Renewal-only mode:
برای سازمان های که قصد ندارند از Delegation استفاده کنند (استفاده از Delegation چون به کاربران خارج از سازمان مجوز دسترسی به بعضی از منابع داخلی شبکه را می دهد همیشه همراه با ریسک پیاده سازی می شود) و نمی خواهند رول CES را بر روی CA Server نصب کنند می توانند از Renewal-only mode استفاده کنند.
با فعال کردن این قابلیت بر روی CES کامپیوترها و Subjectهای که بر روی آنها از قبل Certificate اعمال شده می توانند بصورت اتوماتیک Certificate های خود را قبل از Expire شدن Renew کنند.
برای فعال کردن این قابلیت شما باید CA Policy Module flag را توسط دستور زیر فعال کنید:
certutil -config "CAConfig" -setreg policy\EditFlags +EDITF_ENABLERENEWONBEHALFOF
به جای CA Config شما باید Config CAساختار خودتون رو بذارید:
به عنوان مثال :
Certutil -config " DC.MAHSHAHER.LOCAL\Mahshaher-Issuning-CA" -setreg policy\EditFlags +EDITF_ENABLERENEWONBEHALFOF
- نیازمندی های Service Account:
هنگام تنظیم رول CES از شما خواسته میشه که Use the built-in application pool identity را انتخاب کنید یا Service Account؟؟؟ که گذینه دوم پیشنهاد شدس.
بصورت پیش فرض CEP از اعتبار DefaultAppPool (ApplicationPoolIdentity) استفاده می کند. شما می توانید بعد از اتمام و نصب سرویس CEP تنظیمات پیش فرض را پاک کنید و از Service Account استفاده کنید.
به نکات زیر توجه کنید:
- CEP/CES یا باید از Use the built-in application pool identity استفاده کنند یا Service Account. (برای زمانی که هر دو رول بر روی یک سیستم نصب میشوند سعی کند هر دو رول از یک متد استفاده کنند یا application pool identity یا Service Account)
- شما نمی توانید از Local User استفاده کنید.
- در تنظیمات بالا می توان از قابلیت Managed service accounts استفاده کرد.
Service Account برای سرویس CES باید:
- عضو گروه IIS-IUSRS باشد.
- مجوز Request Certificate بر روی CA Server داشته باشد.
CES/CEP در چه توپولوژی کاربرد دارد؟
Intranet with a Single Forest
در ساده ترین حالت CES/CEP می توانند در یک فارست فعالیت کنند و بر روی Issuing-CA نصب شوند ولی توصیه می شود هر کدام از این رول ها را بر روی یک سیستم جدا نصب و پیکربندی شوند. در چنین سناریوهای متد احراز هویت Windows integrated Authentication می باشد.
Intranet with Multiple Forests
در این حالت که سازمان دارای چندین AD DS Forest می باشد شما می توانید ساختار PKI را در یک فارست راه اندازی کنید و از همان نقطه مدیریت کنید و علاوه بر اینها شما می توانید برای دیگر فارست ها Certificate صادر کنید. تنها فرقی که این سناریو با سناریوی Cross-forest Certificate Enrollment دارد نیاز به ایجاد رابطه Trust ندارید.
باز هم در این سناریو متد احراز هویت Windows integrated Authentication می باشد.
Perimeter Network & Branch Office
در سناریوهای که CES/CEP در DMZ شبکه قرار دارند. در چنین سناریوهای User and Computerهای که عضو دومین نیستند یا از طریق VPN به شعبه اصلی وصل می شوند می توانند درخواست Certificate دهند. در این ساختار هر دو رول در قسمت DMZ قرار دارند و کلاینتها از طریق پروتکل https می توانند با آنها ارتباط برقرار کنند. این ساختار برای کاربرانی مفید می باشد که بیشتر اوقات خارج از سازمان فعالیت می کنند یا شعبه های دیگر که از طریق VPN به سازمان وصل می شوند. به تصویر زیر توجه کنید:
همچنین می توان از توپولوژی زیر استفاده کرد:
CES/CEP را می توان بر روی شعبه های دیگری پیاده سازی کرد و ترافیک آن شعبه با شعبه های دیگر را به بسوی شعبه اصلی هدایت کرد.
در اینجا پیش نیازهای راه اندازی CEP/CES را برسی کردیم در جلسه آینده که آخرین قسمت این سری آموزشی می باشد این دو رول را پیاده سازی می کنیم.
در این قسمت قصد دارم سرویسهای Certificate Enrollment web Services را بصورت عملی یاد بگیریم. در ابتدا سناریوی زیر را در نظر بگیرید:
هدف از ایجاد این سناریو: کارمند و پرسنل سازمان Mahshaher.Local که بیشتر در خارج از سازمان فعالیت می کنند بتوانند درخواست Certificate دهند و همچنین بتوانند Certificate خود را بصورت اتوماتیک Renew کنند.نحوه چیدمان و قرار گیری سرورها در سناریوی بالا را با دقت نگاه کنید. ما طبق دستورالعمل های که در قسمت چهاردهم این آموزش مطرح شد و طبق سناریوی بالا پیش می رویم. ما از قبل Firewallها ، Active Directory ، Certificate Authority و همچنان Web Server و RODC را نصب و کانفیگ کردیم. به عنوان مثال برای نصب و کانفیگ RODC و همچنین Join کردن CEP//CES از طریق آن لینک زیر را مطالعه کنید:
برای Publish کردن Web Server (به منظور Publish کردن لیست CRL) در قسمت Perimeter Network لینک زیر را مطالعه کنید:
در سناریوی بالا ما پورتهای DCOM مربوط به CA Server را محدود کردیم و همچنین پورتهای مورد نیاز را در Back-End Firewall به منظور Certificate Enrollment سرورهای موجود در Perimeter Network را آزاد کردیم. برای اینکار لینک زیر را مطالعه کنید:
و همچنین در آخر کار سرور CEP/CES را در Front-End Firewall پابلیش کردیم:
اولین قدم ایجاد یک Zone به نام Mahshaher.com می باشد که رکوردهای CEP//CES Server و همچنین Web Server در آن ایجاد می شود و در مرحله نصب RODC این Zone باید به RODC ریپلیکت شود. و بعد از آن DNS موجود بر روی RODC را در Front-End Firewall پابلیش می کنیم. کاربران اینترنت از رکوردهای این DNS برای دسترسی به لیست CRL و همچنان سرور CEP//CES استفاده می کنند.
قدم بعدی در این سناریو ما سرویس CEP and CES را با هم بر روی یک سرور نصب و کانفیگ می کنیم. سیستم عامل CEP//CES را نصب می کنیم من از Windows Server 2012 R2 نسخه datacenter استفاده می کنم. و تنظیمات TCP//IP را بر روی آن ست می کنیم.
- نکته: DNS آن باید بر روی RODC سرور ست شود. و از طریق آن به دومین Join شود. و همچنین مطمئن شوید بتواند به لیست Certificate Templateها دسترسی داشته باشد.
قبل از اینکه رولهای CEP//CES را نصب کنیم در ابتدا باید یک Service Account ایجاد کنیم. این اکانت برای Run کردن Application های مربوط به CEP//CES در IIS استفاده می شود.
برای اینکار من یک User Account به نام CEP در Write Domain Controller ایجاد می کنم:
مرحله بعدی باید یک SPN برای این User ایجاد کنیم:
setspn -s http/CEP/CES_Server_Name.Your_Domain.com Domain\User
در مرحله بعدی باید به این User پرمیژن Request Certificates بر روی CA Server دهیم:
و در مرحله بعدی باید تنظیمات Delegation را برای این یوزر انجام دهیم:
در بالا شما باید دو پارامتر rpcss and HOST را انتخاب کنید.و در آخر باید این User را در سرور CEP//CES عضو گروه IIS__IUSER کنید.
قدم بعدی نصب سرویس certificate Enrollment Policy web service and certificate enrollment web service هستش. برای اینکار Server Manager را اجرا و گذینه Active Directory Certificate Services را انتخاب و نکست می کنیم در مرحله بعدی دو گذینه زیر را انتخاب می کنیم:
و این دو رول را نصب می کنیم. بعد از نصب گذینه زیر را کلیک کنید:
- نکته مهم: قبل از اینکه نکست کنید ترافیک بین این سرور را با Write Domain Controller در Back-End Firewall بصورت Full باز کنید. در غیر این صورت Error زیر را دریافت می کنید.
چون در این مرحله سرور CEP/CES محتویات Schema را ابدیت می کند. بعد از نصب می توانید تنظیمات Back-End Firewall را به حالت قبل برگردانید.
برای کانفیگ، دو رول بالا را انتخاب و نکست می کنیم.
در بالا باید CA Server ساختار را به سرور CEP/CES معرفی کنیم.
در بالا نوع احراز هویت را برای سرویس CES بر روی User name and password ست می کنیم و نکست کنید.
در بالا Service Accountی که پیش تر ایجاد کردیم را وارد می کنیم. توجه کنید که فرمت وارد کردن Service Account باید بدین صورت باشد:
Your_Domain\Service_Account
در بالا نوع احراز هویت برای سرویس CEP را بر روی گذینه مشخص شده ست می کنیم و نکست کنید.
در بالا قابلیت Key-based renewal را بر روی CEP فعال می کنیم. برای اطلاع بیشتر درباره این قابلیت قسمت سیزدهم از این سری آموزش را مطالعه کنید.
سرویسهای CEP//CES برای ارتباط با کلاینتها از پروتکل SSL//TLS استفاده می کنند. پس در صفحه بالا باید یک Certificate برای این منظور از CA Server درخواست دهیم. که در بالا مشخص کردم بعدا اینکار را انجام می دهیم.
سرویس CEP//CES نصب شد. برید یه سانتافه نه ببخشید یک نسکافه بخورید تا برگردیم به ادامه تنظیمات. :)قدم بعدی درخواست یک سرتیفیکت برای ارتباطات SSL از CA Server می باشد. برای اینکار در سرور CES//CES و در کنسول IIS گذینه Server Certificate را انتخاب کنید:
در مثال بالا برای Enroll.mahshaher.com باید یک A Record در DNS ایجاد شود. پرسنل خارج از سازمان با این URL به CEP//CES وصل می شوند. بعد از تکمیل درخواست باید این Certificate را در IIS بایند کنید.
قدم بعدی نصب سرویس های CEP and CES با احراز هویت Client Certificate Authentication می باشد. دستور زیر را برای نصب CEP با متد احراز هویت Client Certificate Authentication تایپ کنید:
cd cert:\LocalMachine\My Install-AdcsEnrollmentPolicyWebService -AuthenticationType Certificate -KeyBasedRenewal -SSLCertThumbprint (dir -dnsname Common_Name).Thumbprint
سرویس CEP با متد Client Certificate Authentication نصب شد. توجه کنید که در قسمت Dir –dnsname باید Common name که هنگام درخواست Certificate ایجاد کردید را وارد کنید. به اینم توجه کنید علاوه بر متد Client Certificate Authentication در دستور بالا شما قابلیت Key-based renewal را هم فعال می کنید.الان سرویس CES را همانند سرویس بالا نصب می کنیم. ابتدا باید مقدار Config را توسط دستور زیر بدست بیاورید:
Certutil
بعد از آن دستور زیر را تایپ کنید:
cd cert:\LocalMachine\My Install-AdcsEnrollmentWebService -CAConfig "Your_value" -SSLCertThumbprint (dir -dnsname Your_Common_Name).Thumbprint -AuthenticationType Certificate -RenewalOnly –AllowKeyBasedRenewal
قدم بعدی اطمینان حاصل کردن از ست شدن Service Account بر روی Application های مربوط به CEP//CES می باشد:
قدم بعدی تنظیم URL های مربوط به سرویس CEP//CES می باشد. بصورت پیش فرض URL های مربوط به CEP//CES از FQDNهای مربوط به شبکه داخلی استفاده می کند. ولی کاربران بیرون از سازمان با دامنه اینترنتی به CEP//CES وصل می شوند پس باید URL مربوط به CEP//CES را با FQDNهای دامنه اینترنتی تنظیم کنیم. برای اینکار:
مقدار بالا هنگام درخواست Certificate نمایش داده می شود.
همنیکار را برای بقیه Applicationها قسمت URL انجام دهید.
قدم بعدی تنظیم کردن msPKI-Enrollment-Servers می باشد. این Attribute ادرس URL مربوط به سرویس CES و متد احراز هویت آن را در ساختار Active Directory پخش می کند. اگر شما یک دستور Certutil را اجرا کنید خروجی آن:
ما باید خروجی بالا را بصورت زیر ست کنیم:
https://enroll.mahshaher.com/Mahshaher-Root-CA-01_CES_UsernamePassword/service.svc/CES https://enroll.mahshaher.com/Mahshaher-Root-CA-01_CES_Certificate/service.svc/CES
برای اینکار ابزار ADSI Edit را اجرا میکنیم و
و دو URL بالا را وارد می کنیم. (از مقادیر سازمان خود استفاده کنید) برای اینکه این تعقیرات بر روی RODC و بقیه سرورها اعمال شود مدت 20 دقیقه یا بیشتر وقت میطلبه که تعقیرات Replicate شوند. اگر الان دستور certutil را اجرا کنید خروجی:
- نکته: اگر در نام گذاری CA Server فاصله ی باشد. شما نمی توانید این سناریو را عملی کنید. برای حل این مشکل و نحوه تنظیم کردن msPKI-Enrollment-Servers لینک زیر را بخوانید:
Implementing Certificate Enrollment Web Services in Windows Server 2012 That Uses an Issuing CA With Spaces in the Name
https://social.technet.microsoft.com/wiki/contents/articles/15668.implementing-certificate-enrollment-web-services-in-windows-server-2012-that-uses-an-issuing-ca-with-spaces-in-the-name.aspx
قدم بعدی تنظیم کردن Certificate Template برای استفاده از قابلیت Key-Based renewal می باشد. این تنظیمات را پیشتر در قسمت سیزدهم توضیح دادم. در اینجا مراحل انجام اینکار را بصورت شماتیک نشان خواهم داد.
در آخر هم دستور زیر را بر روی CA Server اجرا می کنیم:
Certutil -config "Config_Value" -setreg policy\EditFlags +EDITF_ENABLERENEWONBEHALFOF
بعد از اجرای دستور فوق سرور CA Server را ریستارت می کنیم.خب!!!!! کل تنظیمات لازم را انجام دادم الان فقط می مونه تست کردن این سناریو....
- نکته: باید مطمئن شوید کامپیوترهای خارج از سازمان به CA Server اعتماد داشته باشند. برای اینکار سرتیفیکت Root-CA را بر روی این کلاینتها نصب کنید.
برای تست این سناریو کنسول Certificate را در کلاینت اجرا کنید و:
در بالا باید URL سرویس CEP که مربوط به متد احراز هویت User/name Password می باشد را وارد کنید.
https://enroll.mahshaher.com/KeyBasedRenewal_ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP
- نکته: در بالا باید Userی را معرفی کنید که مجوز لازم بر روی Certificate Template داشته باشد.
سرویس ما با موفقیت validate شد.
- نکته مهم: در هنگام Validate کردن شاید پیغام خطای Time out دریافت کنید، شما به این پیغام توجهی نداشته باشید و چندین بار پروسه Validate را تکرار کنید. (بیشتر Blogهای مایکروسافت این نکته را متذکر شدن)
- نکته: تنظیمات بالا را فقط بر روی کانتینر Local Computer انجام دادم. برای اینکه Certificate های مخصوص User را از این طریق درخواست و Enroll کنید باید تنظیمات بالا را هم بر روی کانتینر User انجام دهید.
الان چک کنیم ببینیم می توانیم یک Certificate درخواست دهیم:
در بالا لینک مشخص شده را کلیک کنید. برای اینکه این سرتیفیکت درخواست داده شود باید یک سری اطلاعات وارد کنیم. یادتون نره تنظیمات Subject Name در Certificate template بر عهده خود کاربر واگذار شده است.
شاید در هنگام Enroll کردن پیغام Time Out دریافت کنید ولی شما دوباره سعی کنید. وقتی درخواست شما بصورت موفقیت آمیز ارسال شد، این درخواست بصورت Pending قرار میگیرد که شما باید این درخواست را در CA Server تائید و Issue کنید.
الان Certificate تائید شده را درخواست و بر روی این کامپیوتر نصب می کنیم برای اینکار:
سرتیفیکت را با استفاده از متد User mane password با موفقیت Enroll و نصب کردیم. اماده ید متد Client Certificate Authentication را تست کنیم؟؟؟ برای اینکار کنسول Local Security Policy را اجرا کنید و به:
همانند تنظیمات بالا URLمربوط به CEP را در کادر زیر وارد می کنیم:
https://enroll.mahshaher.com/KeyBasedRenewal_ADPolicyProvider_CEP_Certificate/service.svc/CEP
تیک گذینه بالا را بزنید تا آن را تبدیل به متد پیش فرض برای Renew کردن Certificate ها کنیم.
- نکته: علاوه بر تنظیمات بالا قابلیت AutoEnrollmet را نیز فعال کنید تا در زمان مقرر سرتیفیکت بصورت اتوماتیک Renew شود:
- نکته: ما از احراز هویت Certificate authentication استفاده می کنیم تا بتوانیم بصورت اتوماتیک Certificate ها را Renew کنیم. (اینو یادتون باشه)
الان اجازه دهید Certificate قبلی را Renew کنیم ولی قبل از Renew کردن مقدار thumbprint سرتیفیکت قبلی را چک کنیم:
الان توسط مراحل زیر Certificate بالا را Renew کنید:
سرتیفیکت ما با موفقیت Renew شد. برای چک کردن می توانید مقدار thumbprint قبلی را با thumbprint جدید مقایسه کنید:
تبریک میگم به هدفتون رسیدید. بلاخره این سناریوی غول پیکر را با موفقیت انجام دادید.
- نکته: علاوه بر سناریوی بالا میتوانید از CES//CEP درForest های دیگر استفاده کنید. برای اطلاع بیشتر لینک زیر را مطالعه کنید:
Test Lab Guide Mini-Module: Cross-Forest Certificate Enrollment using Certificate Enrollment Web Services
http://social.technet.microsoft.com/wiki/contents/articles/14715.test-lab-guide-mini-module-cross-forest-certificate-enrollment-using-certificate-enrollment-web-services.aspx
برای انجام دادن این سناریو 15 روز وقت گذاشتم که واقعا منو به چالش کشونده بود و یکی از بهترین اوقات من بود.(چون این سناریو را با Best Practice های خودش انجام دادم) توصیه می کنم حتما سناریو بالا را در یک محیط لابراتوار تست وتمرین کنید. دوستان متاسفانه این آخرین قسمت از سری آموزش های مربوط به PKI و سرویس های آن در Microsoft هستش، در این سری آموزش تمام سرویس های مرتبط به جز Network Device Enrollment Service را توضیح و آموزش دادم. وتمام منابع مورد استفاده Blogهای تخصصی مایکروسافت بود است (منابع فارسی در این رابطه به هیچ وجه پیدا نکردم که این سرویس ها را بصورت کامل توضیح و آموزش دهد). انشالله در ادامه تمام منابع و Recourse های که استفاده کردم را بصورت جداگانه برای دوستان می گذارم تا دوستانی که مایلند بیشتر در این رابطه تحقیق کنند به منابع و مقالات جامعی دسترسی داشته باشند.
منبع تمام آموزشها لینک های زیر می باشد:
Designing and Implementing a PKI: Part I Design and Planning (The Best)
https://blogs.technet.microsoft.com/askds/2009/09/01/designing-and-implementing-a-pki-part-i-design-and-planning/
Certification Authority Guidance
https://technet.microsoft.com/en-us/library/hh831574(v=ws.11).aspx
Active Directory Certificate Services Step-by-Step Guide
https://technet.microsoft.com/en-us/library/cc772393(v=ws.10).aspx
Certificates (Best)
https://technet.microsoft.com/en-us/library/cc700805.aspx
Certification Authority Trust Model
https://technet.microsoft.com/en-us/library/cc962065.aspx
How do I create a certificate trust list for a domain?
http://windowsitpro.com/security/how-do-i-create-certificate-trust-list-domain
Administrator Control of CA Certificate Trusts
http://windowsitpro.com/article/security/administrator-control-ca-certificate-trusts-145361
Active Directory Certificate Services (Best)
https://technet.microsoft.com/en-us/windowsserver/dd448615.aspx
Identify Your Certificate Requirements
https://technet.microsoft.com/en-us/library/cc961518.aspx
Building an Enterprise Root Certification Authority in Small and Medium Businesses (Best)
https://technet.microsoft.com/en-us/library/cc700804.aspx
Configuring Certificate Revocation
https://technet.microsoft.com/library/cc771079.aspx
Configure WEB1 to Distribute Certificate Revocation Lists (CRLs)
https://technet.microsoft.com/en-us/library/jj125381(v=ws.11).aspx
PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies
https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/
How to change the expiration date of certificates that are issued by a Windows Server 2003 or a Windows 2000 Server Certificate Authority
https://support.microsoft.com/en-us/kb/254632
Configure the CDP and AIA Extensions on CA1
https://technet.microsoft.com/en-us/library/jj125369(v=ws.11).aspx
Online Responder Installation, Configuration, and Troubleshooting Guide
https://technet.microsoft.com/en-us/library/cc770413(v=ws.10).aspx
Public Key Infrastructure Part 8 – OCSP responder
http://www.tech-coffee.net/public-key-infrastructure-part-8-ocsp-responder/
Forcing the Expiration of Locally Cached Certificate Revocation Lists
http://windowsitpro.com/security/forcing-expiration-locally-cached-certificate-revocation-lists
Implementing an OCSP Responder: Part VI Configuring Custom OCSP URIs via Group Policy
https://blogs.technet.microsoft.com/askds/2009/08/21/implementing-an-ocsp-responder-part-vi-configuring-custom-ocsp-uris-via-group-policy/
Certificate Enrollment Web Services in Active Directory Certificate Services
http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx
Windows Server 2012: Certificate Template Versions and Options
http://social.technet.microsoft.com/wiki/contents/articles/13303.windows-server-2012-certificate-template-versions-and-options.aspx
Certificate Template Concepts
https://technet.microsoft.com/en-us/library/cc754749
Certificate Templates Overview
https://technet.microsoft.com/en-us/library/cc730826(v=ws.10).aspx
Configuring a Certificate Template
https://technet.microsoft.com/library/cc731511
Q: What's the impact of renewing the enterprise root CA's certificate on our existing PKI clients and subordinate CAs?
http://windowsitpro.com/security/q-whats-impact-renewing-enterprise-root-cas-certificate-our-existing-pki-clients-and-subord
Certification Authority Web Enrollment Guidance
https://technet.microsoft.com/en-us/library/hh831649(v=ws.11).aspx
Configuring An Offline Root CA With 2 Tier PKI Hierarchy
https://www.rickygao.com.au/blog//configuring-an-offline-root-ca-with-2-tier-pki-hierarchy/
AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment (The Best)
http://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx
AD CS: Cross-forest Certificate Enrollment with Windows Server 2008 R2
https://technet.microsoft.com/en-us/library/ff955842(v=ws.10).aspx
Certificate Enrollment Policy Web Service Guidance
https://technet.microsoft.com/en-us/library/hh831625.aspx
Test Lab Guide: Demonstrating Certificate Key-Based Renewal
https://technet.microsoft.com/en-us/library/jj590165(v=ws.11).aspx
Enabling CEP and CES for enrolling non-domain joined computers for certificates
https://blogs.technet.microsoft.com/askds/2010/05/25/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers-for-certificates/
Certificate Enrollment Web Services in Active Directory Certificate Services
http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx
New Active Directory Certificate Services (PKI) Features in Windows Server 2012
https://blogs.technet.microsoft.com/xdot509/2013/03/29/new-active-directory-certificate-services-pki-features-in-windows-server-2012/
News and information for public key infrastructure (PKI) and Active Directory Certificate Services (AD CS) professionals (The Best)
https://blogs.technet.microsoft.com/pki/