ایس کیو ایل سرور انکرپشن کی خرابی کو درست کریں - ایک کلک حل
SQL سرور جوڑتا ہے، پھر لاگ ان سے انکار کر دیتا ہے کیونکہ یہ سرور کے سرٹیفکیٹ پر بھروسہ نہیں کر سکتا۔ یہ نیٹ ورک کا مسئلہ نہیں ہے اور آپ کا ڈیٹا ختم نہیں ہوا ہے - یہ اعتماد کا مسئلہ ہے۔ اصلاحات کے ذریعے اس ترتیب سے کام کریں جس ترتیب سے ویڈیو انہیں دکھاتا ہے: فوری کلائنٹ سائیڈ آپشن، ایپ کنکشن سٹرنگ کے اندر وہی سوئچ، اور سرور پر ہی درست درستگی۔
📑باب
- لاگ ان کی خرابی - "سرٹیفکیٹ چین ایک اتھارٹی کی طرف سے جاری کیا گیا تھا جو قابل اعتبار نہیں ہے"
- خرابی کا اصل مطلب کیا ہے - خفیہ کاری کا مطالبہ کیا جاتا ہے، سرور کا سرٹیفکیٹ اس کی شناخت ثابت نہیں کرسکتا
- کلائنٹ کا فوری حل - SSMS کنیکٹ ونڈو میں سرور سرٹیفکیٹ پر اعتماد کریں
- ایک ایپلیکیشن کنکشن سٹرنگ کے اندر ایک ہی فکس
- مناسب حل - سرور کو ایک حقیقی سرٹیفکیٹ دیں جو کلائنٹ خود اعتماد کریں
- تصدیق کی تصدیق کرنا - سخت طریقے سے دوبارہ جڑیں اور ثابت کریں کہ خفیہ کاری واقعی آن ہے
📋 جائزہ اور مرحلہ وار گائیڈ
غلطی پڑھیں - یہ ایک ٹرسٹ کا مسئلہ ہے، نیٹ ورک کا مسئلہ نہیں۔
آپ کا نیٹ ورک ٹھیک ہے اور سرور چل رہا ہے۔ کنکشن ایس کیو ایل سرور تک پہنچ گیا، سرور نے لاگ ان کے لیے ایک انکرپٹڈ چینل کی پیشکش کی، اور آپ کے پی سی نے اس سے انکار کر دیا کیونکہ سرور کی شناخت ثابت کرنے والے سرٹیفکیٹ پر آپ کے پی سی پر بھروسہ کرنے والے کسی کے دستخط نہیں ہیں۔ مکمل غلطی SSMS ظاہر کرتی ہے:
پہلے سے طے شدہ طور پر، ایس کیو ایل سرور لاگ ان کی حفاظت خود دستخط شدہ سرٹیفکیٹ کے ساتھ کرتا ہے جو خود تخلیق کرتا ہے۔ خود دستخط شدہ سرٹیفکیٹ ٹریفک کو خفیہ کرتا ہے، لیکن یہ ثابت نہیں کر سکتا کہ سرور واقعی آپ کا سرور ہے، اس لیے جو کلائنٹ تصدیق شدہ انکرپشن کا مطالبہ کرتے ہیں وہ اسے مسترد کر دیتے ہیں۔ ہر ایماندار حل دو چیزوں میں سے ایک ہے: کلائنٹ کو اس مخصوص سرور کو جان بوجھ کر قبول کرنے پر مجبور کریں (مرحلہ 2 اور 3)، یا سرور کو ایک سرٹیفکیٹ دیں جو کلائنٹ کا خود اعتماد ہے (مرحلہ 4)۔
SSMS میں کوئیک کلائنٹ فکس - ٹرسٹ سرور سرٹیفکیٹ
یہ ویڈیو میں دکھایا گیا تیز رفتار راستہ ہے۔ یہ سرور پر کچھ نہیں بدلتا ہے۔ یہ اس ایک کنکشن کو بتاتا ہے کہ سرور کے سرٹیفکیٹ کو یہ چیک کیے بغیر کہ اس پر کس نے دستخط کیے ہیں۔ SSMS سرور سے جڑیں ونڈو میں، اضافی ٹیبز کو کھولنے کے لیے اختیارات پر کلک کریں، کنکشن پراپرٹیز ٹیب پر جائیں، انکرپشن کو لازمی پر سیٹ کریں (یا اسے پیش کردہ کے طور پر چھوڑ دیں)، ٹرسٹ سرور سرٹیفکیٹ پر نشان لگائیں، اور کنیکٹ پر کلک کریں۔ لاگ ان فوراً ہو جاتا ہے۔
ایپ کنکشن سٹرنگ کے اندر وہی فکس
اگر SSMS کے بجائے کوئی ایپلیکیشن ناکام ہو جاتی ہے تو وہی سوئچ اس کے کنکشن سٹرنگ میں رہتا ہے۔ واضح طور پر دو سیٹنگیں شامل کریں - Encrypt=True محفوظ چینل کو آن کرتا ہے، اور TrustServerCertificate=True SSMS چیک باکس کا کنکشن سٹرنگ اسپیلنگ ہے:
Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;مثال کی اقدار کی جگہ اپنا سرور کا نام، ڈیٹا بیس اور لاگ ان استعمال کریں۔ ٹریڈ آف بالکل ویسا ہی ہے جیسا کہ مرحلہ 2 میں چیک باکس ہے، ایک اضافی خطرہ کے ساتھ: بھیجے گئے ایپلیکیشن کی کنفیگریشن میں بیک کیا گیا، چھوڑ دیا گیا چیک ہر صارف پر، پوشیدہ اور مستقل طور پر لاگو ہوتا ہے۔ اسے ڈویلپمنٹ اور سٹیجنگ کنفیگریشنز میں رکھیں، اور پروڈکشن میں اسے مستعار وقت کے طور پر سمجھیں جب تک کہ مرحلہ 4 میں سرور سرٹیفکیٹ موجود نہ ہو۔
Encrypt کو بطور ڈیفالٹ آن کر دیا گیا۔ کنکشن سٹرنگز جنہوں نے کبھی بھی خفیہ کاری کا تذکرہ نہیں کیا، اس کا مطالبہ کرنا شروع کر دیا، ان سرورز کے خلاف جن کے خود دستخط شدہ سرٹیفکیٹ توثیق کو پاس نہیں کر سکتے۔ آپ کے ڈیٹا بیس کے بارے میں کچھ بھی نہیں بدلا۔ سٹرنگ کے اندر معاہدہ کیا. سیٹنگز کو واضح طور پر لکھنے کا مطلب ہے کہ اگلی ڈرائیور اپ ڈیٹ آپ کی پیٹھ کے پیچھے آپ کی ایپ کے رویے کو تبدیل نہیں کر سکتی۔مناسب حل - سرور کو ایک حقیقی سرٹیفکیٹ دیں۔
مستقل مرمت ایک بار سرور پر ہوتی ہے، اور اس کے بعد ہر کلائنٹ بغیر کسی چیک باکس اور بغیر کسی وارننگ کے سختی سے جڑ جاتا ہے۔ پہلے سرور کے پورے DNS نام کے لیے ایک سرٹیفکیٹ حاصل کریں (مثال کے طور پر sql01.company.local) اپنے اندرونی سرٹیفکیٹ اتھارٹی یا عوامی CA سے، سرور کی تصدیق کے استعمال کے ساتھ۔ اسے، اس کی نجی کلید کے ساتھ، SQL سرور مشین پر لوکل کمپیوٹر سرٹیفکیٹ اسٹور میں درآمد کریں۔ پھر سرٹیفکیٹ پر دائیں کلک کریں، تمام کام → نجی کلیدوں کا نظم کریں کا انتخاب کریں، اور SQL سرور سروس اکاؤنٹ کو نجی کلید پر پڑھیں کی اجازت دیں۔ کھولیں۔ جھنڈے ٹیب پر آپ ForceEncryption کو Yes پر بھی سیٹ کرسکتے ہیں لہذا ہر کلائنٹ کو انکرپٹ کرنا ضروری ہے۔ ایس کیو ایل سرور سروس کو دوبارہ شروع کریں - تبدیلی اس وقت تک کچھ نہیں کرتی جب تک آپ ایسا نہ کریں۔
درست طریقہ کی تصدیق کریں۔
خاموشی سے کامیاب ہونے والا لاگ ان لوگوں کے خیال سے کم ثابت ہوتا ہے، کیونکہ کچھ سیٹنگ کے امتزاج حقیقی تحفظ کے بغیر جڑ جاتے ہیں۔ دونوں حصوں کو ثابت کریں۔ سب سے پہلے، کسی کلائنٹ سے سخت طریقے سے دوبارہ جڑیں: سرور کے DNS نام کا استعمال کرتے ہوئے جڑیں - سرٹیفکیٹ کے اندر کا نام - خفیہ کاری کو لازمی پر سیٹ کریں اور ٹرسٹ سرور سرٹیفکیٹ کو بغیر نشان کے چھوڑ دیں۔ لاگ ان بغیر کسی وارننگ کے کامیاب ہونا چاہیے۔ پھر، اسی سیشن میں، سرور سے پوچھیں کہ کیا SSMS میں اس استفسار کو چلا کر کنکشن درحقیقت انکرپٹ ہوا ہے:
SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;encrypt_option دکھانا TRUE پاسنگ گریڈ ہے۔ ورکنگ لاگ ان کے ساتھ FALSE کا مطلب ہے کہ تحفظ کو چھوڑ کر کنکشن کامیاب ہو گیا، اور کام نہیں ہوا۔ وہ پاسنگ ٹیسٹ ہی اصل فنش لائن ہے: کوئی بھی صحیح طریقے سے تشکیل شدہ کلائنٹ، بشمول مستقبل کے SSMS ورژن، اب مکمل توثیق کے ساتھ جڑتا ہے اور کوئی خاص سیٹنگ نہیں ہے۔
🏷️موضوع کی تلاش کے متغیرات اور مطلوبہ الفاظ
🎙️ مکمل ٹرانسکرپٹ — پھیلانے کے لیے تھپتھپائیں۔
__TOK_24__
__TOK_25__
__TOK_26__
❓ اکثر پوچھے جانے والے سوالات
کیا یہ ٹیوٹوریل پیروی کرنے کے لیے 100% مفت ہے؟
__TOK_27__
کیا مبتدی اس گائیڈ پر عمل کر سکتے ہیں؟
__TOK_28__
اگر میں پھنس گیا ہوں تو میں کہاں سوال پوچھ سکتا ہوں؟
__TOK_29__