Çevirməzdən əvvəl: SSH açarı və OpenVPN sertifikatı

İdxal sertifikat xətası ilə uğursuz olur, ona görə ilk ağıla gələn addım çevirmə kimi görünür. Bu instinkt insanları fayl uzantısının dəyişdiyi, imtinanın isə tam eyni qaldığı bir yola aparır. authorized_keys faylındakı ssh-ed25519 sətri və OpenVPN müştəri sertifikatı ayrı-ayrı etimad obyektləridir: müxtəlif verənlər, müxtəlif kodlaşdırmalar və müxtəlif ləğvetmə yolları var. Bu yoxlamaları sıra ilə keçmək bir dəqiqə içində çevirmənin ümumiyyətlə kömək edib-etmədiyini söyləyir.

Əlinizdə hansı obyekt var?

İnsanların açar adlandırdığı beş şey var və onlardan yalnız biri TLS profilinin istədiyi şeydir. SSH açıq açarı tip prefiksi və base64 yükü olan tək sətirlik mətndir. OpenSSH sertifikatı həmin açarın üstünə imza, prinsipiallar və seçimlər əlavə edilmiş halıdır və onu ssh-keygen öz kiçik CA-sı kimi çıxarır. X.509 sertifikatı isə tamamilə başqa strukturdur: subyekt, etibarlılıq pəncərəsi, genişləndirmələr və sertifikat orqanının imzasını daşıyır. Şəxsi açar gizli yarıdır, verilmiş paket isə adətən sertifikat, onun zənciri və şəxsi açarın bir faylda olmasıdır.

İlk test bir əmrdir. openssl-i fayla yönəldin və ondan sertifikat strukturunu təhlil etməsini istəyin:

openssl x509 -in client.crt -noout -subject -issuer

Bu, yükləmə mümkün deyil və ya PEM xətası ilə uğursuz olursa, fayl nə ad verdiyinizdən asılı olmayaraq X.509 sertifikatı deyil. Adın dəyişdirilməsi içindəki ASN.1-i yenidən yazmır, açıq açar sətrini PEM başlıq mətninə bükmək də bunu etmir.

Profil ümumiyyətlə sertifikat istəyirmi?

Müştəri sertifikatları bir neçə autentifikasiya üsulundan biridir və işləyən TLS profillərinin çoxu onu heç vaxt istəmir. Server istifadəçiləri plagin, istifadəçi adı və parol və ya token arxa hissəsi ilə autentifikasiya edə bilər, eyni zamanda müştəridən serverin kimliyini yoxlamağı tələb edir. Profildə müştəri sertifikatı direktivi yoxdursa, heç bir sertifikat istənilməyəcək və heç bir çevirmə şlüzü onu istəməyə məcbur etməyəcək.

Köhnə statik açar konfiqurasiyaları üçüncü haldır. Onlar TLS əl sıxışmasından əvvələ aiddir və əvvəlcədən paylaşılmış gizli fayl gözləyir, buna görə də həmin sahəyə açıq açar yapışdırmaq da işləyə bilməz. Etimad məlumatının yanlış olduğuna qərar verməzdən əvvəl profilin həqiqətən nə istədiyini oxuyun.

Yenidən kodlaşdırmanın edə bildiyi və edə bilmədiyi şeylər

Şəxsi açarların həqiqətən qanuni alternativ qabları var. Eyni RSA və ya EC açarı ənənəvi PEM, PKCS#8 və ya PKCS#12 paketi içində yazıla bilər və alətlər onların arasında məmnuniyyətlə çevirir. Açıq açarların da oxşar hekayəsi var: ssh-keygen SSH açarının RFC 4716 formasını çıxara bilər, OpenSSH isə öz sertifikat formatını da başa düşür. Bütün bunlar təqdimatdır, təqdimat isə etimad deyil.

Çevirmənin edə bilmədiyi şey, açarınızı heç vaxt görməmiş sertifikat orqanından imza yaratmaqdır. Sertifikat verənin, müəyyən açıq açarın müəyyən subyektə müəyyən məqsəd üçün aid olduğu barədə təsdiqidir. Yenidən kodlaşdırma açarın baytlarını qoruyur və təsdiqi yox qoyur, ona görə şlüzün etimad anbarına qarşı yoxlayacağı bir şey qalmır.

Cəhdlərin çoxunun səssizcə uğursuz olduğu mərhələ budur: fayl artıq .crt ilə bitir, müştəri onu şikayətsiz oxuyur, əl sıxışması isə yenə də kəsilir, çünki qarşı tərəf etibarlı verənə qədər zəncir qura bilmir.

Sertifikat orqanının işə qoşulduğu yer

Həqiqi qeydiyyat sizin nəzarət etdiyiniz açar cütü və operatorun gözlədiyi subyekti daşıyan sertifikat imzalama sorğusu ilə başlayır. Operator hüququ yoxlayır, sorğunu CA açarı ilə imzalayır və verilmiş sertifikatı müştərinin təqdim etməli olduğu hər hansı ara zəncirlə birlikdə qaytarır. Sonra müştəriyə onu imzalamış CA sertifikatı lazımdır, çünki danışdığı serverin eyni yerləşdirməyə aid olduğunu təsdiqləməyə imkan verən məhz budur.

Bu son fayl unudulmağı asan, əvəz edilməsi isə qeyri-mümkündür. CA-nın imzalama açarının özü heç vaxt müştəri konfiqurasiyasına aid deyil və yerli çevirmənin heç bir miqdarı almağınız gözlənilən zənciri yaratmır.

SSH açarını təkrar istifadə etməyin sizə qiyməti

Tutaq ki, çevirmə həqiqətən məqbul bir şey yaratdı. Bir açar cütünün həm SSH girişi, həm də VPN autentifikasiyası üçün istifadəsi yenə də iki müstəqil təhlükəsizlik qərarını bağlayır. authorized_keys qeydinin silinməsi SSH girişlərini dayandırır və VPN CA-nın eyni açıq açar üçün artıq verdiyi sertifikata heç bir təsir etmir. VPN tərəfi öz mexanizmi ilə ləğv edilir, yəni sertifikat ləğvetmə siyahısı və ya operatorun qeydiyyat qeydi.

Beləliklə, yoxlama siyahısı hiylə ilə deyil, dayanma şərti ilə bitir. openssl faylı sertifikat kimi təhlil etmirsə, çevirməni dayandırın və əlinizdə olanı təsvir edin: SSH açarı, SSH sertifikatı, X.509 sertifikatı, şəxsi açar və ya paket. Profil müştəri sertifikatı istəmirsə, dayanın və serverin hansı autentifikasiya üsulunu gözlədiyini soruşun. Yalnız hər iki cavab X.509-a işarə edəndə qeydiyyat növbəti addım olur və bu söhbət ilk cümlədə düzgün isimlə daha sürətli gedir.