حماية خدمات WCF ( الجزء الخامس )

تحدث في المقالة السابقة كيف أنه يمكن استخدام الـ WSDL Offline كطريقة و وسيلة أمانه لحماية الخدمة و عدم عرضها على الملاء , و على الرغم من اننا قطعنا شوطا طويلا حتى الان في حماية خدمات الويب من الغرباء إلى أننا فعلا لم نفعل اي شيء لحماية خدمات الويب من الاصدقاء ما اقصده هنا بالأصدقاء هم الاشخاص الذين سيحصلون على Offline WSDL على الرغم من اننا نثق بهم نوعا ما إلى أنه يجب أن يحصل الاصدقاء إلا على ما يحتاجونه فعلا.

لنفكر مثلا بخدمة تقوم لعميلة التسديد لفاتورة ما حيث تحتوي الخدمة على ثلاثة طريقتين الطريقة الأولى من أجل طلب فاتورة جديدة حيث سيستخدم هذه الطريقة التطبيقات المختلفة لرفع فاتورة ما, بينما الطريقة الثانية تقوم بتأكيد عملية الدفع من قبل طرف ثالث حيث أن الطرف الثالث سوف يقوم بعملية التأكيد للفاتورة, و هنا يجب علينا الفصل بين الطرقتين حيث يجب أن يرى المستخدم الأول الطريقة التي تقوم بإنشاء فتورة فقط و الطرف الثالث الطريقة التي تؤكد على عملية الدفع, لنبدأ بعمل.

الخطوة الأولى: الحصول على الـ Offline WSDL , يمكنك استخدام الاداة المرفقة سواء Windows  أو على OSX , الصورة:

 

Screen Shot 2015-06-15 at 4.00.37 PM

بعد حصولك على ملف الـ WSDL افتح الملف بأي مفكرة ترغب هنا سأستخدم Visual Studio Code  , تتكون الفكرة من ثلاث خطوات الأولى ازالة الطرق غير اللازمة التي يجب على العميل ان لا يراها , ازالة المتغيرات التي تحتجاها هذه الطرق و اذا كانت الطريقة تعيد كائنا يجب ايضا أن يتم ازالتها.

الخطوة الثانية: ازالة الطرق, بعد حصولك على ملف الـ WSDL ابحث فيه عن الطريقة التي ترغب بإزالتها في مثالي هنا سأبحث عن الطريقة Initate payment , الشفرة قبل:

image

و الان للنظر لشفرة بعد ازالة الطريقة المذكورة سابقا:

image

 

الان سنتحاج إلى مسح جميع الكائنات التي تستخدمها هذه الطريقة, في العادة و اذا كان لا تستخدم Singel WSDL فإن جميع الكائنات تكون الملف XSD2 سأفتح الملف و ابحث عن الكائن PaymentRequest و الكائن , و الكائن PaymentRequestDetails  الشفرة قبل:

image

حيث ستصبح الشفرة بعد التعديل بشكل التالي:

image

 

سأحفظ الملف الأن و أبدأ باستخدامه مع مشروع تجربة لاحظ الصورة في الأسفل:

image

و بتالي تستطيع عزل المستخدمين بعضهم عن البعض دون الحاجة إلى بناء خدمات WCF جديدة أو بعثرتها بنشرها بين روابط مختلفة , في حين ان كلامها يستخدمان نفس الخدمة إلى أنه كل عميل سيرى ما يجب أن يراه فقط لا غير .

 

حماية خدمات WCF ( الجزء الرابع )

مرحبا تحدث في المقالات السابقة عن حماية خدمات الـ WCF سواء بواسطة استخدام الـ Ceritifcate  او باستخدام كلمة المرور و اسم المستخدم , في هذه المقالة سأتحدث عن حماية خدمات الويب من خلال عدم توفيرها للعامة , بمعني أخر لا يمكن الوصول للـ WSDL عن طريق المتصفح , حيث يجب على من يرغب التواصل مع الخدمة الحصول على ملف الـ WSDL كاملا أو جزء منه على حسب رغبتك وهو ما سأتحدث عنه في المقالة القادمة. تسمى هذه الطريقة بـ Offline WSDL و تعني الحصول على نسخة من الـ WSDL حيث ترسل هذه النسخة إلى العميل, من جهة العميل يقوم هو بتوليد الشفرة التي يحتاجها من أجل العمل من خلال ذلك الملف, لنبدأ:

الخطوة الأولى: الحصول على ملف الـ WSDL من أجل مشاركته مع العميل, يمكنك تشغيل الأداة Take WSDL Offline لعمل ذلك, افتح الاداة ثم اكتب الرابط الذي ترغب به , لاحظ أن الاداة سوف تقوم بتوليد كافة محتويات الـ WSDL بما في ذلك ملفات الـ XSD ,

Capture

Capture3

Capture4

الخطوة الثانية : الأن و قد حصلت على ملف الـ WSDL يمكنك بكل بسطة تعين الخاصية httpGetEnabled و httpsGetEanbled إلى false هذا سيجبر العميل على استخدام الـ offline WSDL بدل عن استخدام الرابط للوصول إلى الـ WSDL الشفرةم

   1: <behaviors>
   2:       <serviceBehaviors>            
   3:           <behavior name="MyServiceBehavior">
   4:             <serviceMetadata httpGetEnabled="false"  httpsGetEnabled="false"  />
   5:             <serviceDebug includeExceptionDetailInFaults="true"/>
   6:           </behavior>
   7:       </serviceBehaviors>
   8:   </behaviors>

اذا حاول العميل الأن الوصول للخدمة عن طريق الـ HTTP أو اي متصفح سيحصل على رسالة الخطأ Bad Request 400 , في الختام لماذا احتاج إلى عمل هذا الأمر, بكل بساطة لحماية الخدمة من المتطفلين لو كانت الخدمة مثلا مرفوعة على Server متصل بالويب سيكون امكانية الوصول امر غاية في السهولة من خلال استخدام أدوات الاستكشاف المختلف للموقع, لكن مع توفير هذه الطريقة فأنت ستكون متأكد بنسبة كبيرة جدا جدا بأن الشخص الذي يحاول التواصل معك هو الشخص المرخص و الذي حصل عى ملف الـ WSDL منك أنت.

حماية خدمات WCF ( الحزء الثالث )

مرحبا, تحدث في المقالات السابقة عن كيفية حماية خدمات الـ WCF باستخدام الـ Ceritifcate , سأتحدث في هذه المقالة عن حماية خدمات الـ WCF باستخدام كلمة المرور و اسم المستخدم و كيف  تتم عملية الـ Consuming لهذه الخدمة, سأقوم هنا بإنشاء مشروع WCF جديد, سوف يكون عملنا بأكمله تقريبا في ملف الويب Config .

بناء الخدمة

الخطوة الأولى عمل الـ Binding : سوف نحتاج أن نخبر الـ WCF بان هذه الخدمة تستخدم كلمة مرور و اسم مستخدم من أجل التحقق قبل تنفيذ أي اوامر , الشفرة:

   1: <bindings>
   2:   <basicHttpBinding>
   3:     <binding name="basicHttpBinding">
   4:       <security mode="TransportWithMessageCredential">
   5:         <message clientCredentialType="UserName"/>
   6:       </security>
   7:     </binding>
   8:   </basicHttpBinding>
   9: </bindings>

 الخطوة التالية: تحديد الـ Behavior من أجل تسجيل الدخول , يحث يمكنك استخدام الـ Active Dreicotry او Membership Provider أو ان تقوم بعمل شيء خاص بك, أعتقد أن الأول و التالي ابسط من أن نتحدث عنه لذلك سأقوم هنا بالحديث عن النوع الثالث و هو الـ Custom أضف Class جديد إلى المشروع و اسمه UserAuthecation او كما ترغب, الشفرة



   1: <behaviors>
   2:   <serviceBehaviors>
   3:     <behavior name="DefaultBehavior">
   4:       <serviceCredentials>
   5:         <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="WCFDemo.UserAuthcation, WCFDemo"/>
   6:       </serviceCredentials>
   7:       <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
   8:       <serviceDebug includeExceptionDetailInFaults="false"/>
   9:     </behavior>
  10:   </serviceBehaviors>
  11: </behaviors>

الخطوة الثالثة: علينا ربط كلا من الـ Binding و الـ behavior مع الـ Service و الشفرة:



   1: <services>
   2:   <service  name="WCFDemo.Service1" behaviorConfiguration="DefaultBehavior">
   3:     <endpoint bindingConfiguration="basicHttpBinding" contract="WCFDemo.IService1" binding="basicHttpBinding"/>
   4:   </service>
   5: </services>

الخطوة الرابعة: يجب أن تلاحظ الأن اذا حاولت تشغيل الخدمة ستطلب منك أن تستخدم HTTPS و ليس HTTP , في الـ IIS يجب أن تقوم بتفعيل الـ HTTPS , و لكن نحن حاليا في عملية التطوير حدد المشروع من نافذة Solution Exploere اضغط بزر الفأرة الأيمن  ثم اضغط على Ctrl + W + P ستظهر نافذة Properties في النافذة حدد SSL Enabled و عدلها إلى True .


image


الخطوة الخامسة: الأن أصبح إعدادات الخدمة جاهزة إذا حاولت تشغيل الخدمة ستجد بأنها تخبرك بأن الـ Class WCFDemo.UserAuthcation لم يشتق بعد من التنصيف UserNamePasswordValidator , و هو الخطوة الخامسة من أجل بناء تحقق خاص بنا, اشنق UserAuthcantion من UserNamePasswordValidator الموجود في الـ Reference : System.IdentityModel , هذا التصنيف عبارة عن abstract لذلك ستحتاج إلى وجود الطريقة الـ Validate , الشفرة:



   1: namespace WCFDemo
   2: {
   3:     using System.IdentityModel.Selectors;
   4:     using System.ServiceModel;
   5:  
   6:     public class UserAuthcation : UserNamePasswordValidator
   7:     {
   8:         public override void Validate(string userName, string password)
   9:         {
  10:             if(userName != "ALGHABBAN" && password != "123456")
  11:             {
  12:                 throw new FaultException(new FaultReason("User not Authenticat"), new FaultCode("401"));
  13:             }
  14:         }
  15:     }
  16: }

الشفرة في الأعلى ليست اختراع قنبلة ذرية كل ما في الأمر أنني أتحقق من اسم المستخدم و كلمة المرور في حالة أنهما غير متوافقة لما اريد أقوم برمي Fault Exception موضحا للمستخدم أن المستخدم غير مرخص له استخدم هذه الخدمة , شغل الخدمة الأن و حاول استخدام WSDLER معها.


Test1


test2


test3


test4


test6


test66


لاحظ في الصورة الأخير فقد تم إنشاء Time Stamp لعميل تسجيل الدخول لمدة خمسة دقائق , الأن نأتي لعملية الـ Consuming لهذه الخدمة من قبل الـ .net Application.


الـ Consuming للخدمة


لبدء العمل افتح مشروع جديد كما يحلو لك هنا سأقوم باستخدام الـ Console Application سأضيف Service كالمعتاد عن طريق شاشة Add Reference لأحظ أنه لا يمكنك استخدام Add Web Reference كما هو الحال مع asmx سابقا, المهم , بعد اضافة الخدمة إلى المشروع يمكنك مباشرة كتابة الشفرة التي تريد , لاحظ هنا كيف يتم تمرير كلمة المرور و اسم المستخدم, الشفرة:



   1: Service1Client client = new Service1Client();
   2: client.ClientCredentials.UserName.UserName = "alghabban";
   3: client.ClientCredentials.UserName.Password = "123456";
   4: System.Net.ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => true;
   5: Console.WriteLine(client.GetData(0));
   6: Console.ReadLine();

 


test65677


trest623043


test4755


تحميل نسخة من المشروع

حماية خدمات WCF ( الجزء الثاني )

مرحبا, تحدث في المقالة السابقة كيف يمكن بناء Ceritifcate و تثبيتها على جهاز العميل و الخادم من اجل بدء العمل مع حماية خدمات الويب من خلال استخدام الـ Ceritifcate , في هذا الجزء سنبدأ العمل مع هذه الشهادات, سوف نقوم ببناء خدمات ويب Hello Ceritifacte و التي تحتوي على الطريقة SayHello.

في البداية سأحتاج لتسجل شهادة العميل في قائمة الشهادة الموثوقة حيث سيرسل العميل هذه الشهادة مع كل طلب, أيضا سأحتاج تثبيت شهادة الخادم في المتجر MY الخاص بـ Local Computer حيث ستقوم الخدمة بأرسال هذه الشهادة إلى العميل و نفس الامر سنقوم بعمله و لكن بعكس الشهادات , بمعنى سنتثبت شهادة الخادم في جهات الموثوقة عند العميل و شهادة العميل في المتجر MY الخاص بـ Local Computer , ربما توضح الصورة الفكرة اكثر:

1- شهادة الخادم مثبتة في متجر Personel في الحاسب Local Computer .

Server

2- شهادة العميل مثبته في Truseted People  في الحساب Local Computer :

Client

الأن نأتي للعميل:

1- شهادة العميل مثبتة في المتجر MY في الحساب Local Computer:

Client

2- شهادة الخادم مثبتة في الجهات الموثوقة عند العميل:

 

server

بهذا نكون قد انتهينا بـ 50% من العمل , الأن نحتاج إلى أمرين , الأول من الخادم , حيث يجب أن نخبر الـ WCF بأنها ستستخدم الـ Ceritifcate كطبقة أمان و أن العميل يجب أن يزودني بهذه الشهادة, أيضا يجب على الخدمة أن توفر للعميل شهادة من طرفها, لعمل ذلك سنحتاج إلى endpoint و service behaviros و binding , نبدأ من الاساس:

الأول الـ : Binding

Binding

نحن في الـ Bindings نخبر العميل بأننا سنستخدم الـ Certificate كوسيلة للحماية, نأتي الأن إلى الـ Service Behaviros:

bahiver

هنا اقوم بإنشاء Service Bahaviors جديدة و امنحها الاسم الـ LoadCertitifate حيث تطلب هذه الخدمة من العميل شهادة على أن تكون مسجلة في الـ Trust او Personel , اخيرا يقوم الـ Bahaviors بتمرير الشهادة التي تحمل الاسم HelloCeritifcateServer إلى العميل.

النقطة الأخير علينا الأن إنشاء endpoint و ربطها بهذه الاعدادات , الشفرة:

end point

الأن الخدمة جاهزة للعمل, يمكنك باستخدام معالج Add Service References استدعاء الرابط , سينتج عند العميل أمر مشابه لهذا :

Certificate

اذا قمت الأن بتشغيل التطبيق , ستخبرك الخدمة بأنها بحاجة إلى شهادة موثقة للعمل, الصورة :

Cleint

الأن لتزويد الخدمة بشهادة سنحتاج إلى Bahavior , الشفرة:

client cert

الأن اذا حولت ارسال شهادة سينجح الأمر, الصورة:

 

Client Test

الأن اذا حذفنا الشهادة من قائمة الموثوقين في الخادم , سنجد بأنه ليس لدينا الصلاحية للوصول للخدمة:

error

ما زال لدينا مشكلة في حتى هذه النقطة , المشكلة أن الخدمة تثق بأي شهادة موجودة في الـ Trusted نحمل الاسم HellleCeritifcateClient و هذا الأمر طبعا غير صحيح عليا ان نتحقق بأن الشهادة المرسلة هي فعلا الشهادة التي نغرب بها لعمل ذلك سنحتاج التحقق بشكل يدوي.

1- في البداية سنحتاج إنشاء عملية توثيق يدوية و ذلك من خلال اشتقاق الكائن CertificateValidator من الكائن X509CertificateValidator هذا الكائن بدوره عبارة عن abstrac و لذك سيجبرك على وجود الطريقة Validate التي تستقبل الشهادة المرسلة من العميل, كل ما أحتاج فعله عن اذا هو التحقق من أن رقم Serial Number له متوافق مع الشهادة الموثقة , الشفرة:

Server sss

الأن و في ملف الـ Web.Config عليا أن اخبر الـ WCF باستخدام هذا التصنيف بدلا عن التصنيف الافتراضي , الشفرة:

 

khdsfkjsf

لاحظ في الشفرة التي في الأعلى أنني اخزن قيمة الشهادة في ملف الـ Web.Config , الشفرة:

lkglkge

و بهذا ليس فحسب يجب أن تكون الشهادة موجودة في قائمة Truested people بل أيضا يجب أن يكون الـ SerailNumber الخاص بها مساوي للقيمة التي في الأعلى, مازالت هناك مشكلة قائمة, حيث أن الشفرة التي في الأعلى تفترض أن الشهادات التي ستستقبلها شهادة واحدة فقط , بمعنى أن جميع التطبيق التي ستستخدم هذه الخدمة يجب ان تمرر نفس الشهادة , و هذا طبعا غير صحيح, لحل هذه المشكلة علينا إنشاء مصفوفة من الـ Serail Number و من ثم المرور على قيم هذه المصفوفة و البحث عن عنصر مطابقة لشهادة التي يتم يتمر تمريرها مع كل Requets الشفرة:

array

التغير الذي قمت به في الشفرة بسيط جدا, في البداية انا استخدم علامة " ; " للفصل بين كل Serail Number و اخر, ثم اقوم بالبحث عن الـ Serail Number داخل المصفوفة و مقارنته مع قيمة  الـ Serail Number الخاص بالشهادة اذا لم أعثر في المصفوفة على شيء مطابقة اقوم برمي استثناء بأن الشهادة غير موثقة, ملف الـ Web.Config :

=Cert 2

بهذا اكون قد انتهيت تقريبا من العمل مع الشهادات و WCF في المقالة القادمة سأتحدث كيف يمكنك استخدام كلمة المرور و اسم المستخدم مع WCF.

حماية خدمات WCF ( الجزء الأول )

مرحبا, سأتحدث في مجموعة من المقالات عن حماية خدمات الويب ( WCF ) على مختلف المستويات, ستتطرق هذه المقالات إلى النقاط التالية:

  • تأمين خدمات WCF باستخدام الـ Certificate .
  • تأمين خدمات الـ WCF باستخدام اسم مستخدم و كلمة المرور.
  • تأمين خدمات الـ WCF باستخدام الـ Certificate  واسم المستخدم و كلمة  المرور.
  • تامين خدمات الـ WCF باستخدام الـ Certificate  و اسم المستخدم و كلمة المرور و التشفير الثنائي العشوائي.

حتى نتمكن من إكمال العمل علينا في البداية الحصول على الشهادات الازمة للعمل, سواء الـ Root أو شهادة الـ Server او شهادة الـ Client , سيكون حديثنا في الجزء الأول عن إنشاء هذه الشهادات الثلاثة, و تثبيتها الخادم و العميل.

إنشاء شهادة الـ Certificate Authority :

في معظم الأحيان تستطيع الشركة أو المنظمة التي تعمل بها توفير شهادة موثقة من أحد الجهات مثل ( GoDaDay او Verisign) و غيرها من الشركات, و لكن قد تكون العملية مكلفة اذا ما احتجنا إلى شهادة مع كل تطبيق نحتاج إلى تطويره, لذلك يمكنك إنشاء شهادة حقيقة و لكن بوجود الـ Authority  خاصة بك, سيعمل الأمر بشكل أكثر من جيد و تؤدي هذه الشهادة الغرض المطلوب منها في توثيق و تشفير الاتصال و بيانات التي تنقل من خلالها العيب الوحيد في هذه الشهادة هو أنها ستكون حمراء طيلة الوقت, على أية حال لا تستخدم هذه التعليمات عند الانتقال إلى بيئة الانتاج.

افتح المفكرة, و انسخ الشفرة التالية:

   1: makecert.exe ^
   2: -n "CN=ALGHABBAN" ^
   3: -r ^
   4: -pe ^
   5: -a sha512 ^
   6: -len 4096 ^
   7: -cy authority ^
   8: -sv CARoot.pvk ^
   9: CARoot.cer
  10:  
  11: pvk2pfx.exe ^
  12: -pvk CARoot.pvk ^
  13: -spc CARoot.cer ^
  14: -pfx CARoot.pfx ^
  15: -po Test123


في المعامل –n يمكنك تمرير بيانات الشهادة إليك التفاصيل:


CN= اسم المنظمة التي وقعت الشهادة.


UO= القسم في المنظمة الذي سيستخدم الشهادة.


O= اسم المنظمة المستفيذة من الشهادة


L= مكان أو الحي الخاص بالمنظمة المستفيده من الشهادة.


S= الولاية للمنظمة المستفيده من الشهادة.


C= الدولة


يجب أن تلاحظ هنا بأن المتغير –po بأنه يستقبل علامة ** و هنا كلمة المرور الخاصة بهذه الشهادة و التي ستستخدمها لاحقا عند استيرادها في IIS مثلا, –pe و يعني أن المفتاح الخاصة بهذه الشهادة سيتم تولديه تلقائيا و تخزينه داخل الشهادة, –a نوع الهاش و –len طول التشفير, اسم الشهادة سوف يكون CARoot.cer و اسم ملف المفتاح سيكون CARoot.pvk .


الأن احفظ الملف باسم CARoot.cmd داخل المجلد في الاسفل,  الان افتح CMD و انت administrator  و توجه إلى الرابط المجلد التالي:


C:\Program Files (x86)\Windows Kits\8.0\bin\x64


اكتب اسم الملف و انتظر قليلا, ستظهر نافذة تطلب من كلمة المرور اضغط على None فلا فائدة منها تذكر كوني قمت بتزويد الشهادة فعلا بكلمة مرور من قبل من خلال المعامل po.


none


عد إلى المجلد C:\Program Files (x86)\Windows Kits\8.0\bin\x64 و قم بترتيب الملفت حسب تاريخ التعديل, الاحدث في الاعلى, مبروك يجب أن تشاهد الأن شهادة الـ Root كما ترى في الصورة في الاسفل:


ALGHABBAN Cert


 


في الحقيقة لا فائدة تذكر من الـ Root حقيقة :-) سوا أنك ستستخدم الـ Root من أجل أصدارة الشهادة المختلفة, سواء للعميل أو الخادم في كلا الحالتين أن ستقوم بأرسال الـ Root للعميل و الخادم, لأن سنقوم ببناء شهادة الخادم افتح المفكرة مجددا:



   1: makecert.exe ^
   2: -n "CN=alghabban.net" ^
   3: -iv CARoot.pvk ^
   4: -ic CARoot.cer ^
   5: -pe ^
   6: -a sha512 ^
   7: -len 4096 ^
   8: -b 01/01/2014 ^
   9: -e 01/01/2016 ^
  10: -sky exchange ^
  11: -eku 1.3.6.1.5.5.7.3.1 ^
  12: -sv ServerCert.pvk ^
  13: ServerCert.cer
  14:  
  15: pvk2pfx.exe ^
  16: -pvk ServerCert.pvk ^
  17: -spc ServerCert.cer ^
  18: -pfx ServerCert.pfx ^
  19: -po 1986Gabban2015*C



اعتقد أن الشفرة في الأعلى واضحة جدا مجددا n يمكنك فعل نفس الأمر في الرووت ,iv تعني الحصول على المفتاح الخاص بـ Root من ملف CARoot.pvk و b تعني تاريخ الشهادة و e تعني متى تنتهي, اخيرا ما يمز أن هذه الشهادة هي شهادة خادم هو eku و هو ما يعرف بـ OID او object Idintify .


ارجو أنك لم تغلق الـ CMD نفس ما فعلنا في الأعلى و لكن هذه المرة سنقوم بكتابة اسم الملف الجديد, مجددا لست بحاجة لكلمة مرور فتجاهل الأمر عد للمجلد, الأن نفس الأمر مع شهادة العميل, وهذه الخطوة ستحتاج لعملها مع كل عميل, الشفرة:



   1: makecert.exe ^
   2: -n "CN=alghabban.net" ^
   3: -iv CARoot.pvk ^
   4: -ic CARoot.cer ^
   5: -pe ^
   6: -a sha512 ^
   7: -len 4096 ^
   8: -b 01/01/2014 ^
   9: -e 01/01/2016 ^
  10: -sky exchange ^
  11: -eku 1.3.6.1.5.5.7.3.2 ^
  12: -sv ClientCert.pvk ^
  13: ClientCert.cer
  14:  
  15: pvk2pfx.exe ^
  16: -pvk ClientCert.pvk ^
  17: -spc ClientCert.cer ^
  18: -pfx ClientCert.pfx ^
  19: -po ****************


لأن نحتاج لتثبيت هذه الشهادات داخل متجر الشهادات, من قائمة ابدأ ابحث عن mmc ثم من file  اختر add/ remove snap-in ابحث الـ ceritifcate , الصورة:


compter


أكمل مع المعالج حتى الانتهاء, الأن ابحث عن المجلد Trusted Root Certification Authorities , افتح المجلد و توجه لـ Certificate بزر الفأرة الأيمن اضغط على All Task ثم Import  أكمل مع العالج حتى يطلب منك الشهادة , هذه المرة ستختار شهادة الـ Root , الصورة:



root cet


بنسبة لكلا من الخادم و العميل فإن عملية تثبيتهما ستكون في الـ Personal و لا يختلف الأمر عن خطوات الـ root , النتيجة,


alghabban cer2


alghabban server cert


بهذا نكون قد انتهينا من اعداد الشهادات , في المقالة القادمة سأتحدث عن استخدام هذه الشهادة لتأمين خدمات WCF .