خطای Word/Office: Security Alert — A secure connection with this site cannot be verified در filekit

رفع خطای Word/Office: Security Alert — A secure connection with this site cannot be verified (Certificate name mismatch)

خطای Word/Office: Security Alert — A secure connection with this site cannot be verified

این پیام یعنی Word/Office به یک سایت HTTPS وصل شده، اما نام سایت در URL با نام داخل گواهی TLS/SSL یکی نیست. این خطا به‌طور کلاسیک همان Certificate Name Mismatch است: یعنی کاربر به یک hostname وصل می‌شود، ولی سرور گواهی مربوط به hostname دیگری را برمی‌گرداند.

Microsoft Word / Office HTTPS / TLS Certificate Name Mismatch IIS WebDAV Reverse Proxy / WAF SNI SharePoint / AAM

متن پیام

Security Alert
A secure connection with this site cannot be verified.
Would you still like to proceed?

The certificate you are viewing does not match the name of the site you are trying to view.

معنای فنی پیام

اگر کاربر مثلاً به https://docs.example.com وصل شود ولی سرور گواهی portal.example.com یا server01.internal.local را ارائه کند، Word هشدار می‌دهد چون هویت مقصد قابل تأیید نیست.

این خطا دقیقاً چه زمانی رخ می‌دهد؟

برای معتبر بودن TLS، نامی که کاربر در URL باز می‌کند باید داخل گواهی وجود داشته باشد: یا در CN قدیمی، یا مهم‌تر از آن در SAN (Subject Alternative Name). اگر hostname مقصد در SAN/CN نباشد، کلاینت خطای name mismatch می‌دهد.

قاعده ساده

URL نهایی که Word واقعاً به آن وصل می‌شود باید با نام‌های موجود در گواهی همان endpoint مطابقت داشته باشد. نکته مهم اینجاست که URL نهایی ممکن است با URL اولیه یکی نباشد، چون redirect/rewrite/proxy می‌تواند آن را عوض کند.

رایج‌ترین علت‌ها

1) گواهی اشتباه روی سایت/Binding اشتباه در IIS

روی سایت HTTPS ممکن است certificate نادرست bind شده باشد، یا binding متعلق به سایت دیگری باشد.

2) مشکل SNI (Server Name Indication)

اگر چند سایت روی یک IP/Port هستند و SNI درست تنظیم نشده، سرور ممکن است گواهی پیش‌فرضِ سایت دیگری را برگرداند.

3) Redirect / Rewrite به hostname دیگر

کاربر URL درست را می‌زند، اما سرور یا reverse proxy او را به نام دیگری می‌فرستد که در گواهی پوشش داده نشده.

4) استفاده از نام داخلی/کوتاه (short name) به‌جای FQDN

مثلاً کاربر با https://fileserver/ وصل می‌شود در حالی که گواهی فقط برای fileserver.company.com صادر شده است.

5) Reverse Proxy / WAF / SSL Offload

در front-end یک گواهی وجود دارد، ولی redirect یا پاسخ نهایی کاربر را به hostname بک‌اند یا نام دیگری می‌برد.

6) Wildcard certificate ولی hostname خارج از scope آن است

مثال: گواهی *.example.com فقط یک سطح را پوشش می‌دهد، نه a.b.example.com.

7) Split DNS یا Alternate Access Mapping نادرست

در شبکه داخلی نامی resolve می‌شود که با نام public certificate فرق دارد. این در SharePoint/WebDAV محیط‌های hybrid زیاد دیده می‌شود.

8) WAF/Proxy به جای سرور اصلی، گواهی محصول خودش را نشان می‌دهد

اگر SSL inspection یا offloading غلط پیکربندی شده باشد، کلاینت certificate نامرتبط دریافت می‌کند.

نمونه‌های کلاسیک mismatch

کاربر باز می‌کند: https://dav.company.com/docs/file.docx ولی certificate برای www.company.com است.
کاربر باز می‌کند: https://share.company.com ولی redirect می‌شود به https://sp01.internal.local.
کاربر از short name استفاده می‌کند: https://portal ولی cert فقط portal.company.com را دارد.
چند سایت روی یک IP هستند اما SNI خاموش است و IIS گواهی سایت اول را به همه نشان می‌دهد.

اقدامات پیشنهادی برای کاربر

URL را دقیق بررسی کنید
مطمئن شوید کاربر از hostname رسمی و کامل (FQDN) استفاده می‌کند، نه نام کوتاه، IP، یا alias غیررسمی.
اگر لینک از داخل Word/Outlook/Portal آمده، URL نهایی را در مرورگر باز کنید
ببینید آیا redirect به hostname دیگری رخ می‌دهد یا نه. mismatch خیلی وقت‌ها روی URL نهایی پیدا می‌شود، نه آدرس اولیه.
روی Continue/Proceed عادت نکنید
چون این هشدار دقیقاً یعنی هویت سرور قابل تأیید نیست. در محیط سازمانی این می‌تواند نتیجه misconfiguration باشد، ولی از دید امنیتی شبیه حمله MITM هم به نظر می‌رسد.

راهکارهای فنی برای ادمین / تیم زیرساخت

1) بررسی SAN/CN گواهی

گواهی باید دقیقاً hostnameهایی را پوشش دهد که کاربران و Office واقعاً استفاده می‌کنند. تمرکز اصلی روی SAN است، نه فقط CN.

اگر URL واقعی docs.example.com است، همین نام باید در SAN باشد.
اگر redirect به files.example.com دارید، آن نام هم باید پوشش داده شود، یا redirect حذف شود.

2) IIS Binding و SNI را بررسی کنید

در IIS برای هر سایت HTTPS این موارد را کنترل کنید:

Host name درست باشد.
Require Server Name Indication (SNI) در سناریوهای multi-site فعال باشد.
certificate صحیح به همان binding متصل باشد.

3) Redirect / Rewrite / Reverse Proxy را اصلاح کنید

نکته بسیار مهم

خیلی از خطاهای Word در WebDAV از این‌جا می‌آیند که endpoint اولیه درست است، اما reverse proxy یا rewrite rule کاربر را به hostname داخلی/غیرقابل‌اعتماد می‌فرستد. باید Location headerها، rewrite ruleها، و absolute URLهای خروجی بررسی شوند.

4) از IP address یا short name استفاده نکنید

https://10.0.0.12/ تقریباً همیشه mismatch می‌دهد مگر گواهی برای IP صادر شده باشد.
https://server1/ هم معمولاً mismatch می‌دهد اگر cert فقط FQDN داشته باشد.

5) Split DNS / Internal DNS را با نام گواهی همسو کنید

اگر داخل شبکه نامی resolve می‌شود که با public certificate یکی نیست، یا باید DNS را اصلاح کنید یا گواهی‌ای بگیرید که همان hostname داخلی/مورد استفاده را هم پوشش دهد (البته استفاده از نام‌های داخلی غیراستاندارد معمولاً توصیه نمی‌شود).

6) اگر SSL Offloading یا WAF دارید، front-end hostname و certificate را مبنا قرار دهید

کاربر باید همیشه همان hostname رسمی front-end را ببیند.
هیچ redirect یا absolute URL نباید به backend/internal hostname اشاره کند.
در محصولات WAF/ADC، policyهای Host header rewrite و redirect rewriting باید چک شوند.

تست‌های سریع تشخیصی

در مرورگر، certificate را ببینید
نام Subject/SAN را با URL مقایسه کنید.
Redirect chain را چک کنید
ببینید آیا 301/302 شما را به hostname دیگری می‌برد یا نه.
از hostname رسمی به‌جای alias استفاده کنید
اگر با FQDN رسمی مشکل حل شد، issue همان name mismatch بوده است.
اگر فقط در یک شبکه رخ می‌دهد، Proxy/WAF را بررسی کنید
ممکن است دستگاه میانی certificate دیگری inject کند.

تشخیص سریع از روی رفتار

اگر در مرورگر هم همین هشدار را می‌بینید

مشکل تقریباً قطعاً در certificate, DNS, redirect یا proxy است؛ نه Word.

اگر فقط در Word دیده می‌شود

ممکن است Word به URL دیگری (مثلاً WebDAV endpoint یا Office URI) وصل شود که مرورگر مستقیماً به آن نمی‌رود.

آیا Wildcard همیشه کافی است؟

نه. مثلاً *.example.com، نام‌هایی مثل docs.example.com را پوشش می‌دهد، اما a.docs.example.com را پوشش نمی‌دهد.

اگر Certificate درست است ولی باز هم mismatch می‌بینیم؟

معمولاً یا redirect به نام دیگری وجود دارد، یا SNI/Binding اشتباه است، یا یک Proxy/WAF certificate دیگری برمی‌گرداند. در این سناریوها فقط نگاه کردن به certificate اولیه کافی نیست؛ باید endpoint نهایی بررسی شود.

جمع‌بندی

خلاصه فنی

این خطا تقریباً همیشه یعنی hostname مورد استفاده با SAN/CN گواهی تطابق ندارد. در Word و WebDAV، علت‌های اصلی عبارت‌اند از: redirect/rewrite غلط، IIS binding یا SNI نادرست، استفاده از نام داخلی/کوتاه، یا مداخله WAF/Proxy.