Access Server veb sertifikat xətası: boş CA paketini düzəltmək
Boş ca_bundle dəyəri və ya səhv PEM Admin interfeysini dayandırır. Yenidən başlatmadan əvvəl sertifikatı, açarı və zənciri bir dəst kimi yoxlayın, VPN PKI-yə toxunmayın.
DNS düzgün həll olunarkən yüklənməyən veb giriş səhifəsi adətən DNS problemi deyil. Xidmət jurnalı boş sertifikat paketi yolu və ya veb sertifikat və şəxsi açar üçün PEM təhlili xətası qeyd edirsə, HTTPS dinləyicisinin istifadə edilə bilən materialı yoxdur və ad həlli kömək etməyəcək. Düzəliş üç konfiqurasiya açarındadır və heç bir VPN müştəri sertifikatının yenidən verilməsini tələb etmir.
Üç açar əslində nəyə işarə edir
Fərdi veb sertifikat dəsti cs.cert, cs.priv_key və cs.ca_bundle ilə təsvir olunur. Hər biri fayla yol saxlayır və üçü veb xidməti tərəfindən birlikdə istifadə olunur. Səhv açarla sertifikat və ya əslində son sertifikat olan zəncir faylı boş dəyər kimi uğursuz olur: dinləyici brauzerin qəbul edəcəyi zəncir qura bilmir.
Bu açarlar Admin və Client veb interfeysinə aiddir. Onlar VPN müştərilərinə sertifikat verən PKI-dən ayrıdır, ona görə də onları dəyişmək müştəri profillərinə, server açarına və ya sertifikat orqanına toxunmağı tələb etmir. Veb TLS nasazlığını bütün PKI-ni yenidən qurmağa səbəb saymaq burada ən bahalı səhvdir.
Bir fərq vaxt qazandırır: açıq şəkildə boş fərdi dəyər heç bir üstünlük olmayan vəziyyətlə eyni deyil. Birincisi təhlilçiyə boş yol verir, jurnal sətri bunu deyir. İkincisi Access Server-i öz materialında saxlayır, buna görə bəzi hostlar yeniləmədən sonra yaxşı işə düşür, digərləri yox.
Mövcud fayl niyə yenə də təhlil olunmur
Təhlilçi faylın içindəki işarələnmiş blokları oxuyur, fayl adını yox. Şəxsi açar saxlayan .crt, tək sertifikat gözlənilən yerdə birləşdirilmiş zəncir və ya son sətri kəsilmiş fayl rədd edilir. RFC 7468 həmin oxunaqlı etiketləri ona görə müəyyən edir: oxucuya sonrakı obyektin növünü deyən yeganə şey onlardır.
Uzantıları deyil, obyektləri yoxlayın. Linux hostunda openssl x509 -noout -subject -issuer -in server.pem və openssl pkey -noout -check -in key.pem iki vacib suala cavab verir, ikisinin modulu və ya açıq açarını müqayisə etmək onların bir-birinə aid olduğunu sübut edir. Şəxsi açar çıxışını biletlərdən və söhbət jurnallarından uzaq saxlayın; yoxlama barmaq izi tələb edir, açar yox.
Boş yol da səhv fayl kimi şübhə doğurur, çünki hər ikisi qeyri-müəyyən sonrakı xətalar verir. Jurnal paket yolunun boş olduğunu deyirsə, faylı ayıklamadan əvvəl saxlanılan dəyəri oxuyun.
Qəsdən ehtiyat varianta keçin
Access Server CLI-ında üç yolu arqument kimi götürən və dəstin yararlı olub-olmadığını bildirən yoxlama var. Aşağıdakı yollar nümunədir; hostdakı qorunan yerlərlə əvəz edin:
sacli --ca_bundle=/secure/webcerts/chain.pem \
--cert=/secure/webcerts/server.pem \
--priv_key=/secure/webcerts/key.pem TestWebCertsİşləyən xidmətə toxunmadan əvvəl nəticəni oxuyun, yalnız sonra dəyərləri idxal edib quraşdırılmış versiya üçün sənədləşdirilmiş əməliyyatla tətbiq edin. rəsmi CLI dərsi yoxlama, konfiqurasiya bazasına idxal və tətbiq addımını əhatə edir, onun versiyası hər hansı xülasədən daha vacibdir.
İstifadəçilərin həqiqətən yazdığı adı yoxlayın
Fərdi material sınıq və etibarlı daxili ehtiyat variant varsa, sənədləşdirilmiş bərpa üç fərdi üstünlüyü silib Access Server-in həmin variantdan istifadə etməsinə icazə verməkdir. Əvvəlcə konsol girişini və cari konfiqurasiyanın ehtiyat nüsxəsini təşkil edin, çünki yenidən başladacağınız xidmət idarəetmə interfeysini təqdim edən xidmətdir.
sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this versionBütün konfiqurasiya bazasını təmizləmək sertifikat təmiri deyil. Həmin üç açarı hədəf alın, tətbiq edin və veb interfeysin cavab verdiyini təsdiqləyin. web-ssl qovluğundakı özüimzalı fayllar ehtiyat mənbəyidir, iş sahəsi deyil: onları üzərinə yazmaq və ya yenidən yaratmaq hostun yeganə işlək materialını silə bilər.
Ehtiyat variant işə düşdükdən sonra brauzerin başqa sertifikat göstərməsini gözləyin. Bu düzgün nəticədir və cavab onu etibarlı inzibati prosesinizlə yoxlamaqdır, istifadəçilərə sonrakı hər xəbərdarlığı keçməyi öyrətmək deyil.
Bərpa yalnız uğurlu girişdən sonra tamamlanır
TCP dinləyicisi görünəndə bərpa bitmir. DNS adını, sertifikat kimliyini və həmin ad üçün zənciri yoxlayın, sonra həm Admin, həm Client veb interfeysini açıb girişi tamamlayın. Port yoxlaması bunların heç birini sübut etmir.
Access Server 3.1 və sonrası hər SNI host adı üçün fərqli veb sertifikatları da təqdim edə bilər. Bu konfiqurasiya edilibsə, standart açarlar və host adına aid qeydlər ayrı dəstlərdir, IP ilə sınaq istifadəçilərin aldığından fərqli sertifikat göstərə bilər. Uğursuz ad üçün dəsti düzəldin və yoxlayın, sonra hadisəni bağlamazdan əvvəl giriş sınağını təkrarlayın.