رفع خطای رمزگذاری SQL Server - راه حل با یک کلیک
SQL Server متصل می شود، سپس ورود به سیستم را رد می کند زیرا نمی تواند به گواهی سرور اعتماد کند. این یک مشکل شبکه نیست و داده های شما از بین نمی روند - مشکل اعتماد است. اصلاحات را به ترتیبی که ویدیو نشان می‌دهد کار کنید: گزینه سمت کلاینت سریع، همان سوئیچ در یک رشته اتصال برنامه، و اصلاح مناسب روی خود سرور.
📑فصل‌ها
- خطای ورود به سیستم - "زنجیره گواهی توسط مرجعی صادر شد که قابل اعتماد نیست"
- این خطا واقعاً به چه معناست - رمزگذاری درخواست می‌شود، گواهی سرور نمی‌تواند هویت آن را ثابت کند
- رفع سریع مشتری - گواهی سرور اعتماد در پنجره اتصال SSMS
- همان اصلاح در یک رشته اتصال برنامه
- راه حل مناسب - به سرور یک گواهی واقعی به مشتریان بدهید که به تنهایی به آن اعتماد دارند
- تأیید رفع مشکل - دوباره به روش سختگیرانه متصل شوید و ثابت کنید که رمزگذاری واقعاً فعال است
📋 بررسی اجمالی و راهنمای گام به گام
خطا را بخوانید - مشکل اعتماد است، مشکل شبکه نیست
شبکه شما خوب است و سرور در حال اجرا است. اتصال به SQL Server رسید، سرور یک کانال رمزگذاری شده برای ورود به سیستم ارائه کرد و رایانه شما آن را رد کرد زیرا گواهی هویت سرور توسط کسی که رایانه شما به آن اعتماد ندارد امضا شده است. خطای کامل SSMS نشان می دهد:
به‌طور پیش‌فرض، SQL Server از ورود به سیستم با گواهی امضایی که خودش ایجاد می‌کند محافظت می‌کند. یک گواهی نامه خودامضا ترافیک را رمزگذاری می کند، اما نمی تواند ثابت کند که سرور واقعاً سرور شماست، بنابراین مشتریانی که درخواست رمزگذاری تأیید شده دارند آن را رد می کنند. هر اصلاح صادقانه یکی از این دو چیز است: کاری کنید که کلاینت آگاهانه این سرور خاص را بپذیرد (مرحله 2 و 3)، یا به سرور یک گواهی را که مشتریان به تنهایی به آن اعتماد دارند (مرحله 4) بدهید.
رفع سریع مشتری در SSMS - گواهی سرور اعتماد
این مسیر سریعی است که در ویدیو نشان داده شده است. هیچ چیز روی سرور تغییر نمی کند. به این یک اتصال می گوید که گواهی سرور را بدون بررسی اینکه چه کسی آن را امضا کرده است بپذیرد. در پنجره SSMS اتصال به سرور، روی گزینه‌ها کلیک کنید تا برگه‌های اضافی باز شود، به برگه ویژگی‌های اتصال بروید، رمزگذاری را روی اجباری تنظیم کنید (یا آن را به‌صورت پیشنهادی رها کنید)، گواهی سرور مطمئن را علامت بزنید، و روی C کلیک کنید. ورود بلافاصله انجام می شود.
همان اصلاح در داخل رشته اتصال برنامه
اگر برنامه ای به جای 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 عمومی با استفاده از Authentication سرور دریافت کنید. آن را با کلید خصوصی آن به فروشگاه گواهی رایانه محلی در دستگاه SQL Server وارد کنید. سپس روی گواهی کلیک راست کنید، همه وظایف → مدیریت کلیدهای خصوصی را انتخاب کنید و به حساب سرویس SQL Server مجوز خواندن روی کلید خصوصی بدهید. SQL Server Configuration Manager را باز کنید، SQL Server Network Configuration را گسترش دهید، روی Protocols for MSSQLSERVER کلیک راست کنید، Properties را انتخاب کنید و گواهی را در برگه گواهی انتخاب کنید. در برگه پرچم‌ها همچنین می‌توانید ForceEncryption را روی بله تنظیم کنید، بنابراین هر مشتری ملزم به رمزگذاری است. سرویس SQL Server را مجددا راه اندازی کنید - این تغییر تا زمانی که این کار را انجام ندهید کاری انجام نمی دهد.
Fix the Strict Way را بررسی کنید
ورود به سیستمی که بی سر و صدا موفق می شود کمتر از آنچه مردم فکر می کنند ثابت می شود، زیرا برخی از ترکیبات تنظیمات بدون محافظت واقعی به یکدیگر متصل می شوند. هر دو نیمه را ثابت کنید. ابتدا، دوباره از یک کلاینت به روش سختگیرانه وصل شوید: با استفاده از نام DNS سرور - نام داخل گواهی - وصل شوید - رمزگذاری را روی اجباری تنظیم کنید و گواهی سرور اعتماد را بدون علامت بگذارید. ورود باید بدون اخطار موفقیت آمیز باشد. سپس، در همان جلسه، از سرور بپرسید که آیا اتصال واقعاً با اجرای این پرس و جو در SSMS رمزگذاری شده است یا خیر:
SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;encrypt_option نشان می دهد که درست نمره قبولی است. FALSE با ورود به سیستم فعال به این معنی است که اتصال با حذف حفاظت انجام شد و کار انجام نشد. این آزمون موفقیت آمیز خط پایان واقعی است: هر مشتری با پیکربندی صحیح، از جمله نسخه های SSMS آینده، اکنون با اعتبار سنجی کامل و بدون تنظیمات خاصی متصل می شود.
🏷️متغیرها و کلمات کلیدی جستجوی موضوع
🎙️ رونوشت کامل — برای بزرگ کردن ضربه بزنید
__TOK_24__
__TOK_25__
__TOK_26__
❓ سوالات متداول
آیا این آموزش 100% رایگان است؟
__TOK_27__
آیا مبتدیان می توانند از این راهنما پیروی کنند؟
__TOK_28__
اگر گیر کردم کجا می توانم سوال بپرسم؟
__TOK_29__