Security Alert The identity of this web site or the integrity of this connection cannot be verified in filekit

رفع خطای Word: Security Alert – The identity of this web site or the integrity of this connection cannot be verified

خطای Word: Security Alert – The identity of this web site or the integrity of this connection cannot be verified

این هشدار یعنی Word/Windows نتوانسته اتصال HTTPS را «قابل اعتماد» تشخیص دهد. از دید فنی، اعتبارسنجی TLS شکست خورده یا ناقص است: یا گواهی (Certificate) مشکل دارد، یا زنجیره گواهی کامل نیست، یا نام دامنه با CN/SAN منطبق نیست، یا پاسخ‌های بررسی ابطال (CRL/OCSP) در دسترس نیست، یا در مسیر، Proxy/TLS Inspection گواهی را دستکاری کرده است.

Microsoft Word HTTPS / TLS Certificate Chain CRL / OCSP IIS Reverse Proxy / WAF WebDAV / SharePoint-like Windows Trust Store

چرا مهم است؟

این هشدار یعنی امکان حمله‌ی «مرد میانی» (MITM) یا misconfiguration واقعی وجود دارد. در محیط سازمانی، اغلب به یکی از این‌ها ختم می‌شود: Full Chain ناقص روی سرور، نام دامنه غلط، یا TLS inspection بدون نصب Root CA روی کلاینت.

علت‌های رایج (Root Causes)

1) زنجیره گواهی ناقص (Intermediate/Full Chain)

سرور فقط leaf certificate را می‌دهد و intermediateها را نمی‌فرستد. بعضی کلاینت‌ها با AIA آن را پیدا می‌کنند، اما Word/WinHTTP/Proxy ممکن است نتواند.

2) عدم انطباق نام (CN/SAN mismatch)

URL که Word به آن وصل می‌شود با مقادیر SAN (یا CN قدیمی) یکی نیست؛ مثل redirect به hostname داخلی، یا تفاوت FQDN و shortname.

3) گواهی منقضی/لغوشده/نامعتبر

Expired certificate، یا صادرکننده نامعتبر/ناشناخته، یا مشکل در EKU/Key Usage.

4) Revocation check شکست می‌خورد (CRL/OCSP)

کلاینت به URLهای CDP/AIA یا OCSP دسترسی ندارد (Proxy/Firewall/DNS). نتیجه: Word هشدار integrity/identity می‌دهد یا خطای revocation.

5) TLS Inspection / Proxy گواهی را عوض می‌کند

اگر سازمان SSL inspection دارد ولی Root CA آن روی کلاینت نصب نیست، Word گواهی را untrusted می‌بیند.

6) SNI/Bindings اشتباه در IIS یا Load Balancer

روی IP مشترک، سرور گواهی سایت دیگری را می‌دهد (بدون SNI درست)، یا binding اشتباه است.

Runbook سریع (کمترین زمان تا تشخیص)

URL را در مرورگر (Edge/Chrome) باز کنید و روی قفل SSL کلیک کنید
ببینید مرورگر هم warning می‌دهد یا فقط Word. اگر مرورگر هم هشدار داد، مشکل تقریباً قطعاً در certificate/chain/hostname است.
Certificate chain را بررسی کنید (روی کلاینت)
در جزئیات گواهی، وضعیت chain باید OK باشد و intermediateها موجود باشند. اگر “missing intermediate” دیدید، باید روی سرور Full Chain نصب/ارسال شود.
نام دامنه واقعی که Word استفاده می‌کند را پیدا کنید
Word گاهی redirect را دنبال می‌کند یا از لینک‌های داخلی استفاده می‌کند. اگر به hostname داخلی یا alias ریدایرکت شوید، احتمال mismatch زیاد است.
Revocation connectivity را چک کنید
اگر شبکه دسترسی به OCSP/CRL را نمی‌دهد، یا WinHTTP proxy غلط است، Word هشدار می‌دهد.
وجود TLS inspection را بررسی کنید
issuer گواهی را نگاه کنید: اگر به‌جای CA عمومی، نام CA سازمان/Proxy را می‌بینید، یعنی MITM قانونی (inspection) دارید و باید Root CA آن به Trust Store کلاینت deploy شود.

تست‌های دقیق‌تر (برای تیم فنی)

1) تست زنجیره و نام با PowerShell

این‌ها برای «دیدن» گواهی و زنجیره از نگاه کلاینت خوب‌اند. (دستورها بسته به سیاست سازمان ممکن است نیاز به دسترسی داشته باشند.)

# تست ساده TLS handshake و نمایش گواهی سرور
# (در پاورشل 7+ می‌توانید از openssl هم استفاده کنید اگر موجود باشد)
# روش عمومی: گواهی را از مرورگر export کنید و chain را بررسی کنید.

# بررسی اینکه سایت در Trusted Root/Intermediate ها به درستی وجود دارد:
certmgr.msc

2) اگر IIS دارید: Full Chain و Bindings

در IIS Manager > Site > Bindings > https: گواهی درست انتخاب شده؟
اگر چند سایت روی یک IP هست: SNI فعال و hostname درست set شده؟
گواهی را با Full chain (leaf + intermediate) نصب کنید.

3) اگر Reverse Proxy/WAF دارید

آیا termination TLS روی WAF انجام می‌شود و WAF گواهی دیگری ارائه می‌کند؟
آیا WAF/Proxy گاهی گواهی متفاوت (fallback) می‌دهد؟
آیا مسیرهای Office/WebDAV به pool متفاوت با گواهی متفاوت می‌خورند؟

راهکارها (Client-side)

اعتماد به CA درست: اگر CA سازمانی است، Root/Intermediate را در Trusted Store نصب/Deploy کنید (GPO/Intune).
رفع مشکل Proxy برای revocation: WinHTTP proxy را درست کنید تا OCSP/CRL قابل دسترس باشد.
به‌روزرسانی Windows/Root Certificates: روی سیستم‌های قدیمی، root store ممکن است قدیمی باشد.
استفاده از FQDN رسمی: لینک‌ها را به hostname‌ای تغییر دهید که واقعاً در SAN گواهی آمده است.

راهکارها (Server-side)

نصب/ارسال Full Chain: leaf به‌تنهایی کافی نیست؛ intermediateها باید ارائه شوند.
اصلاح CN/SAN mismatch: گواهی باید SAN شامل تمام hostهای واقعی (و ترجیحاً بدون internal redirect) داشته باشد.
اصلاح Redirectها: ریدایرکت به hostname داخلی یا پروتکل/پورت دیگر را حذف یا استاندارد کنید.
اصلاح IIS Bindings و SNI: روی هاست‌های چندگانه، گواهی درست به hostname درست bind شود.
OCSP stapling / دسترسی revocation: اگر سازمان revocation را سخت‌گیرانه چک می‌کند، دسترسی شبکه به OCSP/CRL را فراهم کنید.

تشخیص از روی «متن هشدار»

اگر پیام دقیقاً “identity … cannot be verified” باشد

اغلب: untrusted issuer / chain issue / MITM proxy / نام دامنه ناسازگار.

اگر پیام درباره “revocation information …” باشد

اغلب: دسترسی نداشتن به CRL/OCSP یا WinHTTP proxy misconfig.

آیا می‌شود این هشدار را نادیده گرفت؟

از نظر امنیتی توصیه نمی‌شود. در محیط‌های سازمانی، نادیده گرفتن آن معمولاً فقط مشکل زیرساخت TLS را پنهان می‌کند و بعداً به خطاهای upload/open عجیب‌تر می‌رسید. بهتر است chain/hostname/proxy را درست کنید.

چرا گاهی فقط Word هشدار می‌دهد ولی مرورگر نه؟

چون Word ممکن است از مسیرهای WinHTTP/Office-specific استفاده کند که با مرورگر متفاوت است (خصوصاً برای proxy، credential delegation، یا revocation checks). همچنین Word ممکن است به URL متفاوتی (بعد از redirect) برود که شما در مرورگر تست نکرده‌اید.

چک‌لیست یک‌صفحه‌ای (برای اجرا در تیم)

✅ URL نهایی (بعد از هر redirect) دقیقاً همان hostname موجود در SAN باشد.
✅ گواهی منقضی نیست و EKU مناسب (Server Authentication) دارد.
✅ Full Chain ارائه می‌شود (Intermediateها missing نیستند).
✅ Root/Intermediate CA در کلاینت‌ها trusted است (به‌خصوص در TLS inspection).
✅ دسترسی به OCSP/CRL برقرار است (یا policy بررسی ابطال مناسب تنظیم شده).
✅ IIS binding/SNI درست است و سایت روی cert صحیح پاسخ می‌دهد.

جمع‌بندی

هشدار Security Alert – The identity of this web site or the integrity of this connection cannot be verified یعنی اعتبارسنجی TLS از دید Word/Windows قابل اعتماد نیست. در ۸۰٪ موارد مشکل با یکی از این‌ها حل می‌شود: Full Chain ناقص، CN/SAN mismatch، یا TLS inspection بدون Root CA روی کلاینت.