پروکسی HTTPS هم باید زنجیرهٔ گواهی خود را ارسال کند
گواهی‌های میانی گمشده در شنوندهٔ TLS از سمت کارخواه تا Squid را جدا از گواهی وب‌سایت مقصد تشخیص دهید.
اگر کارخواهان پیش از رسیدن به یک وب‌سایت، پروکسی HTTPS را رد می‌کنند، زنجیره‌ای را که شنوندهٔ پروکسی می‌فرستد بررسی کنید. یک گواهی برگهٔ معتبر به‌تنهایی ممکن است گواهی‌های میانی موردنیاز کارخواه را فراهم نکند.
- نقطهٔ پایانی بررسی‌شده را مشخص کنید. نام میزبان را در URL پیکربندی‌شدهٔ پروکسی و خطای آن اتصال بخوانید. گواهی شنونده باید آن نام را پوشش دهد. گواهی یک وب‌سایت یا گواهی برای نام مستعار IP دیگر نمی‌تواند جای آن را بگیرد.
- پیکربندی زنجیرهٔ شنونده را بررسی کنید. پیکربندی پشتیبانی‌شدهٔ OpenSSL در Squid می‌تواند گواهی‌های میانی را در فایل گواهی بگنجاند. ترتیب را در مرجع شنونده برای نسخهٔ نصب‌شدهٔ Squid و بک‌اند TLS تأیید کنید؛ رفتار بسته‌ها یکسان نیست. نمونهٔ شنوندهٔ TLS در Squid 6.13 اعتماد شنونده را از TLS مقصد جدا نگه می‌دارد.
- اعتماد کارخواه را جداگانه بررسی کنید. ارسال گواهی‌های میانی به ساخت زنجیره کمک می‌کند، اما کارخواه هنوز به لنگر اعتماد ریشهٔ موردنظر نیاز دارد. واردکردن کل زنجیرهٔ سرور به یک مخزن ریشه بدون تفکیک، تغییری متفاوت از اصلاح آن چیزی است که سرور می‌فرستد.
راستی‌آزمایی را فعال نگه دارید. این کار پروکسی HTTPS موردنظر کارخواه را مشخص می‌کند. پس از تأیید آن اتصال، خطای گواهی وب‌سایت در مرحلهٔ بعد متعلق به نشست TLS مقصد از طریق پروکسی است، با بررسی جداگانهٔ نام میزبان و اعتماد خودش.