گواهی برگه معتبر، زنجیره منقضی: عمق را بخوانید
خطای انقضا ممکن است به یک صادرکننده تعلق داشته باشد، نه به برگه. پیش از تمدید گواهی‌ای که هنوز به‌روز به نظر می‌رسد، عمق بررسی و ورودی‌های اعتماد را بخوانید.
گواهی سرور را بررسی می‌کنید، می‌بینید ماه‌ها روی ساعت مانده، و کلاینت هنوز اتصال را با پیام انقضا رد می‌کند. تاریخی که می‌خوانید متعلق به برگه است و شکایت می‌تواند درباره چیزی عمیق‌تر در مسیر باشد. بررسی از یک زنجیره عبور می‌کند و هر گواهی که این پیمایش انتخاب کند می‌تواند در پنجره اعتبار خودش شکست بخورد. پیش از تمدید هر چیزی بخوانید کدام‌یک شکست خورده است.
عمق نام گواهی‌ای را می‌گوید که شکست خورده است
در تشخیص OpenSSL، عمق 0 گواهی هدف است و عمق 1 صادرکننده‌ای که آن را امضا کرده، و اعداد بالاتر به سمت لنگر اعتماد ادامه می‌یابند. انقضای گزارش‌شده در عمق 1 با notAfter جاری روی برگه تناقض ندارد، پس بررسی دوباره گواهی قابل مشاهده هرگز خطا را توضیح نخواهد داد.
اثر انگشت گواهی شکست‌خورده را همراه با subject آن ثبت کنید، چون گواهی‌های مختلف می‌توانند نام CA یکسانی داشته باشند. امضای متقابل دقیقاً همین وضعیت را می‌سازد: همان مرجع بیش از یک بار، با تاریخ‌های اعتبار متفاوت ظاهر می‌شود، و بررسی‌کننده همانی را انتخاب کرد که انتظارش را نداشتید. برچسب آشنا شناسه نیست، و اثر انگشت چیزی است که دو شیء با نام مشترک را از هم متمایز می‌کند.
به محصولاتی که بیش از یک نقش گواهی دارند هم توجه کنید. در OpenVPN Access Server، گواهی‌هایی که از رابط‌های وب محافظت می‌کنند از گواهی‌های اتصال‌های VPN جدا هستند، پس مرورگری که صفحه مدیریت را باز می‌کند هیچ چیزی درباره مسیر تونل اثبات نمی‌کند.
ورودی‌های اعتماد با نامزدهای زنجیره یکی نیستند
دو ورودی را جداگانه و صریح به بررسی‌کننده بدهید. فایل اعتماد لنگرهایی را نگه می‌دارد که می‌پذیرید؛ بستهٔ غیرقابل‌اعتماد گواهی‌های میانی را نگه می‌دارد که برای ساختن مسیر ارائه می‌شوند. مخلوط کردنشان همان روشی است که مردم به‌طور تصادفی یک گواهی میانی را به ریشه ارتقا می‌دهند و بعد تعجب می‌کنند چرا همان خطا بین ماشین‌ها دنبالشان می‌کند.
$ openssl verify -verbose -show_chain -purpose sslserver \
-CAfile trusted-roots.pem -no-CApath -no-CAstore \
-untrusted intermediates.pem server.pemغیرفعال کردن مسیر و انبار پیش‌فرض با -no-CApath -no-CAstore آزمون را صادق نگه می‌دارد: نتیجه آنگاه به فایل‌هایی که نام بردید بستگی دارد، نه به آنچه ایستگاه کاری تصادفاً به آن اعتماد دارد. مرجع بررسی OpenSSL این گزینه‌ها و تشخیصی را که تولید می‌کنند مستند می‌کند.
-show_chain زنجیره ساخته‌شده را وقتی بررسی موفق است چاپ می‌کند، که برای تأیید اینکه مسیر همان است که قصد داشتید مفید است. وقتی شکست می‌خورد، عمق و subject گزارش‌شده را نگه دارید؛ این دو فیلد به خواننده بعدی می‌گویند کدام گواهی را بررسی کند.
چیزی که این کار نمی‌کند بازتولید سیاست هر کلاینت است. پین، محدودیت هدف یا بررسی هویت مخصوص کلاینت در کلاینت زندگی می‌کند، نه در این فرمان. این‌ها تنظیماتی هستند که باید وقتی بررسی روی سرور موفق است و اتصال هنوز شکست می‌خورد بررسی شوند. دو تشخیص را جدا نگه دارید، وگرنه گواهی سالمی را به دنبال خطای پینینگ تمدید می‌کنید.
بررسی چه چیزی را اثبات می‌کند و چه چیزی را بیرون می‌گذارد
این یک بررسی مسیر و هدف در برابر فایل اعتمادی است که خودتان ارائه کرده‌اید. برای بررسی نام HTTPS، نام میزبان مورد انتظار را از طریق گزینه مناسب اضافه کنید؛ برای اتصال VPN، بررسی‌های هویت پیکربندی‌شده کلاینت را نگه دارید و از مواد اعتمادی استفاده کنید که خود آن کلاینت واقعاً می‌خواند.
چیزی که سرور می‌فرستد مجموعه‌ای از نامزدهاست، نه مسیری که کلاینت شما در نهایت می‌سازد. اعتماد محلی و قواعد ساخت کتابخانه هر دو نتیجه را شکل می‌دهند، به همین دلیل همان پاسخ می‌تواند روی یک ماشین معتبر باشد و روی دیگری شکست بخورد. پیش از فرض ارزیابی یکسان، انبار اعتماد نگهداری‌شده و پیاده‌سازی TLS کلاینت شکست‌خورده را با کلاینت کارکننده مقایسه کنید. تفاوت در آنجا بسیاری از گزارش‌های «فقط این لپ‌تاپ شکست می‌خورد» را توضیح می‌دهد.
برای دیدن پنجره هر گواهی به‌جای یکی‌یکی، آن‌ها را به‌صورت مجموعه چاپ کنید:
$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
| openssl pkcs7 -print_certs -nooutفرمان دوم subjectها و صادرکننده‌ها را بدون رمزگشایی دستی هر فایل فهرست می‌کند، و این‌گونه گواهی میانی‌ای را می‌یابید که تاریخش گذشته در حالی که برگه هنوز خوب به نظر می‌رسد.
مسیر را بدون تضعیف بررسی تعمیر کنید
وقتی یک گواهی میانی منقضی یا گواهی متقاطع منسوخ ارائه می‌شود، زنجیره پشتیبانی‌شده فعلی صادرکننده را بگیرید و آن را از طریق جریان کاری گواهی مستند سرویس مستقر کنید. وقتی کلاینت لنگر نگهداری‌شده مورد نظر را ندارد، پیکربندی اعتماد مدیریت‌شده یا نرم‌افزار کلاینت را به‌روز کنید. در برابر میان‌بر علامت‌زدن هر گواهی در بسته به‌عنوان ریشه فقط برای ساکت کردن پیام مقاومت کنید.
برخورد با ریشه ارزش یک یادداشت را دارد، چون خلاصه‌ها اغلب آن را بزرگ می‌کنند. RFC 5280 لنگر را ورودی‌ای می‌داند که بیرون از مسیر آینده قرار دارد، در حالی که OpenSSL بررسی‌های اعتباری را مستند می‌کند که گواهی CA ریشه‌اش را شامل می‌شود. هر دو گزاره برای سیستم‌های خودشان درست‌اند؛ تعمیم رفتار انقضای ریشه یک کتابخانه به هر کلاینت پاسخ‌های غلط مطمئن تولید می‌کند.
پس از تغییر، روی کلاینت آسیب‌دیده احراز هویت تازه را اجباری کنید و تأیید کنید که پیام انقضای مشخص رفته است. برگه را فقط وقتی تمدید کنید که خود برگه نامناسب است. غیرفعال کردن بررسی‌های زمان یا بازگرداندن یک گواهی متقاطع تاریخی مسیر جاری معتبری نمی‌سازد؛ فقط شکست بعدی را به تأخیر می‌اندازد.