SSL بعد از انتقال وردپرس خراب شده است؛ تشخیص گواهی، HTTPS و Mixed Content

هشدار SSL پس از انتقال وردپرس لزوماً به معنی خرابی خود وردپرس نیست. ممکن است خطا پیش از اجرای PHP رخ دهد: DNS به مقصد اشتباه برود، Virtual Host گواهی دامنه دیگری را ارائه کند، نام Host در گواهی نباشد یا CDN در Edge گواهی متفاوتی داشته باشد. اگر TLS برقرار می‌شود اما صفحه هنوز ناامن است، علت بیشتر در Redirect، تشخیص HTTPS پشت Proxy یا Mixed Content قرار دارد.

پاسخ سریع: Hostname دقیق را از بیرون تست کنید، گواهی ارائه‌شده روی پورت 443 را ببینید و نام‌ها، تاریخ، صادرکننده و Chain آن را کنترل کنید. سپس مطمئن شوید DNS و CDN همان Host را به مقصد مورد انتظار می‌رسانند. فقط بعد از آن سراغ home و siteurl وردپرس، هدرهای Reverse Proxy، Redirect و منابع HTTP داخل صفحه بروید. به‌جای نصب فوری افزونه SSL یا صدور چندباره گواهی، اولین لایه خراب را اصلاح کنید.

نشانه دقیق خطای HTTPS را ثبت کنید

Hostname، پیام Browser، زمان، شبکه و Route درگیر را ثبت کنید. دامنه اصلی و www را جدا آزمایش کنید؛ پوشش یکی به معنی پوشش دیگری نیست. نتیجه را در یکی از این گروه‌ها قرار دهید:

• Name Mismatch: گواهی شامل Host درخواست‌شده نیست؛
• Expired یا Not Yet Valid: تاریخ گواهی یا ساعت سیستم مشکل دارد؛
• Untrusted Issuer یا Incomplete Chain: Client مسیر اعتماد کامل نمی‌سازد؛
• TLS Handshake Failure: Protocol، Cipher، SNI، Listener یا Edge شکست می‌خورد؛
• Too Many Redirects: HTTPS کار می‌کند اما لایه‌ها درباره Scheme یا Host اختلاف دارند؛
• هشدار قفل یا Asset مسدود: Document با HTTPS آمده اما درخواست ناامن دارد.

در صفحه ورود مدیریتی هشدار Browser را دور نزنید. تا زمانی که هویت گواهی درست نشده، از واردکردن Credential خودداری و با Client تشخیصی جداگانه تست کنید.

گواهی‌ای را ببینید که واقعاً ارائه می‌شود

Endpoint عمومی را همراه Server Name Indication بررسی کنید تا سرور اشتراکی Virtual Host درست را انتخاب کند:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -Iv https://example.com/

example.com را با Host واقعی جایگزین کنید. Subject Alternative Name، بازه اعتبار، Issuer و Intermediateهای برگشتی را ببینید. وجود فایل گواهی روی Disk ثابت نمی‌کند Listener عمومی همان را ارائه می‌کند.

اگر خطا فقط برای بعضی کاربران رخ می‌دهد، IPv4 و IPv6، چند پاسخ DNS، نقاط مختلف CDN و Trust Storeهای متفاوت را مقایسه کنید. Node قدیمی یا رکورد فراموش‌شده AAAA می‌تواند خرابی متناوب بسازد.

تأیید کنید DNS به Endpoint درست TLS می‌رسد

پاسخ‌های authoritative برای A، AAAA و CNAME را با برنامه مهاجرت مقایسه کنید. مشخص کنید TLS در CDN، Load Balancer، Control Panel، Reverse Proxy یا Origin وردپرس Terminate می‌شود. گواهی باید در همان Endpointی معتبر باشد که Browser به آن می‌رسد.

در زمان Propagation ممکن است مقصد قدیمی و جدید هم‌زمان ترافیک بگیرند. تا پایان پنجره Cutover، روی هر دو مقصد گواهی معتبر و Host Configuration سازگار نگه دارید. صرفاً چون یک Resolver IP جدید را نشان می‌دهد، مقصد قدیمی را حذف نکنید.

پوشش Hostname و زنجیره گواهی را کنترل کنید

همه Hostهای عمومی لازم باید در گواهی باشند: دامنه اصلی، www و Subdomainهای مورد نیاز. Wildcard مانند *.example.com دامنه اصلی example.com یا چند سطح Subdomain را پوشش نمی‌دهد.

وب‌سرور را با Full Chain مورد انتظار نرم‌افزارش تنظیم کنید، نه فقط Leaf Certificate. Private Key را محافظت کنید و هرگز در تست Browser، Ticket، Log یا Chat قرار ندهید. گواهی و Key باید با هم Match باشند؛ در صورت اختلاف، Reference سرور را اصلاح کنید و Key را دست‌کاری نکنید.

Virtual Host و SNI روی HTTPS را بررسی کنید

در IP اشتراکی، Listener پورت 443 با SNI یک Virtual Host را انتخاب می‌کند. server_name یا ServerName، مسیر Certificate، Document Root و Enabled Site را بررسی کنید. Default Virtual Host ممکن است گواهی معتبر دامنه‌ای دیگر را نشان دهد.

پیش از Reload، تنظیم وب‌سرور را Validate و یک نسخه سالم نگه دارید. Reload کنترل‌شده معمولاً از Restart بدون برنامه مناسب‌تر است، اما فرمان دقیق به سیستم‌عامل و روش استقرار بستگی دارد.

پیش از صدور دوباره، گواهی موجود را بررسی کنید

اگر میزبان از Certbot استفاده می‌کند، راهنمای رسمی Certbot این فرمان فقط‌خواندنی را برای Inventory گواهی‌ها ارائه می‌کند:

sudo certbot certificates

نام Certificate، دامنه‌ها، Expiry و مسیرهای Live را تأیید کنید. صدور اجباری مکرر می‌تواند Lineage تکراری بسازد، Reference سرور را پیچیده کند و به Rate Limit مرجع صدور برسد. اگر گواهی درست است، Listener ارائه‌کننده گواهی اشتباه را تعمیر کنید.

تمدید را پیش از انقضا آزمایش کنید

پس از اطمینان از گواهی فعال و Reference سرور، Workflow تمدید موجود را تست کنید:

sudo certbot renew --dry-run

Dry Run مسیر شبیه‌سازی‌شده تمدید را می‌آزماید و جای بررسی گواهی فعلی ارائه‌شده را نمی‌گیرد. برای HTTP-01 مطمئن شوید پورت عمومی 80 و /.well-known/acme-challenge/ به Webroot درست می‌رسند. برای DNS-01، Automation مجاز DNS را کنترل و Credential API را با Least Privilege محافظت کنید.

TLS لبه CDN را از TLS مبدأ جدا کنید

سایت Proxyشده می‌تواند دو اتصال رمز‌شده داشته باشد: Browser تا Edge و Edge تا Origin. هر دو را بررسی کنید. گواهی سالم Edge ممکن است Origin منقضی را تا زمان فعال‌شدن اعتبارسنجی Strict پنهان کند؛ گواهی سالم Origin نیز نبود Host در گواهی Edge را حل نمی‌کند.

از Encryption Mode مستند CDN استفاده و TLS اعتبارسنجی‌شده Origin را ترجیح دهید. برای پنهان‌کردن خطا حالتی انتخاب نکنید که ترافیک Origin را Cleartext می‌فرستد. Headerهای عمومی را با درخواست مجاز به Origin و Host صحیح مقایسه کنید.

کاری کنید وردپرس HTTPS پشت Proxy را تشخیص دهد

وقتی TLS پیش از وردپرس Terminate می‌شود، برنامه ممکن است در داخل HTTP دریافت کند و تصور کند بازدیدکننده هم HTTP آمده است. نتیجه می‌تواند URL ناامن، مشکل Login Cookie یا Redirect Loop باشد. مستند رسمی HTTPS وردپرس توضیح می‌دهد Proxy باید Scheme را منتقل و وردپرس آن را درست تشخیص دهد.

Forwarded Header را فقط از Proxy تحت کنترل بپذیرید. Origin عمومی نباید مقدار دلخواه X-Forwarded-Proto از Client را معتبر بداند. سیاست Host، Scheme و Client Address Header را یک طراحی واحد در نظر بگیرید.

URLهای وردپرس را بدون حدس بررسی کنید

پیش از تغییر، مقادیر تنظیم‌شده را بخوانید:

wp option get home
wp option get siteurl

در سایت عمومی HTTPS معمولی، URLهای تولیدشده باید Host و Scheme مورد انتظار را داشته باشند. بااین‌حال نصب Subdirectory می‌تواند مقادیر متفاوت قانونی داشته باشد و Constantهای WP_HOME یا WP_SITEURL ممکن است دیتابیس را Override کنند. مقدار قبلی را نگه دارید و فقط پس از شناخت معماری تغییر دهید.

Redirect Loop را از یک مالک در هر مرحله رفع کنید

همه Hopها را دنبال کنید:

curl -IL --max-redirs 10 https://example.com/

مشخص کنید هر Redirect از CDN، Load Balancer، وب‌سرور، Security Plugin یا WordPress آمده است. Loop رایج زمانی رخ می‌دهد که Edge، HTTP را به HTTPS می‌فرستد اما وردپرس به‌دلیل ناآگاهی از Scheme اصلی آن را برمی‌گرداند. Ruleهای رقیب دامنه اصلی و www نیز Loop دوم می‌سازند.

یک Host و Scheme مرجع انتخاب، تشخیص HTTPS را اصلاح و مالکیت تکراری Redirect را حذف کنید. راهنمای لینک‌های خراب پس از مهاجرت Chain و اعتبارسنجی Route را بیشتر توضیح می‌دهد.

Mixed Content را در منبع آن اصلاح کنید

Mixed Content یعنی Document با HTTPS، منبعی را با HTTP درخواست کند. Browserهای جدید بعضی درخواست‌ها را Upgrade و بعضی را Block می‌کنند؛ مرجع رسمی MDN درباره Mixed Content این تفاوت را توضیح می‌دهد. Console و Network را برای یافتن URL و Initiator دقیق بررسی کنید.

محتوای نوشته، Media URL، Theme Option، CSS تولیدشده، Page Builder، Widget، Font، Script، API و CDN Host را ببینید. منبع تحت مالکیت را به HTTPS ببرید و Dependency بیرونی بدون HTTPS را جایگزین کنید. Browser Protection را خاموش نکنید و افزونه‌ای نصب نکنید که بدون اصلاح URL ذخیره‌شده فقط هشدار را پنهان کند.

URLهای HTTP قدیمی را امن جایگزین کنید

با Dry Run سازگار با Serialization شروع کنید:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run

پیش از حذف --dry-run Matchها را مرور کنید. Replacement را به Host مورد نظر محدود و از دیتابیس Backup بگیرید. www، URL escaped، CDN قدیمی، CSS و مقدارهای محیطی را جدا جست‌وجو کنید. SQL خام می‌تواند داده Serialized افزونه و قالب را خراب کند.

در زمان عیب‌یابی HSTS را فعال نکنید

HTTP Strict Transport Security به Browser می‌گوید برای مدتی که ممکن است از Session فعلی طولانی‌تر باشد HTTPS را اجباری کند. آن را فقط وقتی فعال کنید که گواهی، همه Subdomainهای لازم، Redirect، Dependency بیرونی و تمدید خودکار اثبات شده باشند. گزینه‌های includeSubDomains و Preload دامنه خرابی را گسترش می‌دهند و به ارزیابی آمادگی جداگانه نیاز دارند.

اگر HSTS قبلاً ارائه شده، تعمیر Endpoint HTTPS معمولاً امن‌تر از درخواست برای دورزدن Policy است. حذف Header برای Browserهایی که آن را Cache کرده‌اند Rollback فوری نیست.

تعمیر کامل را اعتبارسنجی کنید

1. دامنه اصلی و www را از بیرون و روی IPv4 و IPv6 منتشرشده تست کنید.
2. نام‌ها، تاریخ، Chain و Status نهایی HTTPS را تأیید کنید.
3. صفحه اصلی، ورود، مدیریت، یک نوشته، Media، فرم، Checkout و Callbackهای لازم را تست کنید.
4. نبود Loop، Redirect میان Host ناخواسته و Assetهای HTTP را کنترل کنید.
5. مسیر CDN و Origin مجاز را جدا بیازمایید.
6. Dry Run تمدید و Timer یا Scheduler آن را بررسی کنید.
7. پس از DNS Propagation، Logهای TLS، برنامه و Proxy را مانیتور کنید.

تعمیر زمانی کامل است که Client تازه گواهی مورد انتظار بگیرد و برنامه به‌طور ثابت URLهای HTTPS تولید کند؛ نمایش قفل در یک Browser دارای Cache کافی نیست.

اشتباه‌های رایج

• صدور مکرر گواهی پیش از بررسی Endpoint ارائه‌کننده ترافیک
• پوشش www بدون دامنه اصلی یا برعکس
• نصب Leaf Certificate بدون Intermediate لازم
• استفاده از حالت ضعیف CDN برای پنهان‌کردن Origin خراب
• اعتماد به Forwarded Header از Client نامطمئن
• رفع Mixed Content با خاموش‌کردن محافظت Browser
• فعال‌کردن HSTS یا Preload پیش از آماده‌بودن تمدید و Subdomainها

چه زمانی کمک مهاجرت مناسب است؟

پایان TLS در CDN، چند Origin، IPv6، Domain Mapping در Multisite یا Checkout عملیاتی، تغییر آزمون‌وخطایی را پرریسک می‌کند. سرویس انتقال سایت وردپرس می‌تواند DNS، گواهی، Routing، URLهای وردپرس و کنترل‌های پس از Cutover را در محدوده مستند مهاجرت بررسی کند.

پرسش‌های متداول

چرا بعد از انتقال، گواهی دامنه دیگری نمایش داده می‌شود؟

DNS ممکن است به سرور اشتباه برسد یا Listener پورت 443 به‌دلیل نبود SNI Host در تنظیم مورد انتظار، Virtual Host پیش‌فرض را انتخاب کند.

چرا گواهی معتبر است اما Browser هنوز صفحه را ناامن می‌داند؟

HTML می‌تواند تصویر، Script، Style، Font یا Frame را با HTTP دریافت کند. Console و Network را بررسی و هر منبع را در محل تولید یا ذخیره آن اصلاح کنید.

آیا تغییر URL وردپرس گواهی نصب می‌کند؟

خیر. تنظیم URL فقط روی آدرس‌های تولیدشده برنامه اثر دارد. گواهی معتبر و Listener HTTPS باید از قبل در Endpoint عمومی TLS وجود داشته باشد.

چرا HTTPS پشت CDN باعث Too Many Redirects می‌شود؟

Edge و وردپرس ممکن است درباره Scheme اصلی اختلاف داشته باشند یا چند لایه Rule متعارض Host و HTTPS اجرا کنند. Scheme Forwarding قابل‌اعتماد را اصلاح و مالک Redirect را مشخص کنید.