چرا cryptoapicert در OpenVPN 3 و Connect در ویندوز شکست می‌خورد
این دستور متعلق به یک کلاینت ویندوز است، نه به پروتکل. کتابخانه هسته فراخوان‌های امضای بیرونی را ارائه می‌دهد و رابط کاربری جریان درون‌ریزی خودش را دارد.
یک پروفایل OpenVPN 2 کارکردی را به یک کلاینت ویندوزی جدیدتر کپی می‌کنید، و گواهی‌ای که کلاینت قدیمی خودش پیدا می‌کرد دیگر ارائه نمی‌شود. خطی که این کار را ممکن می‌کرد یک انتخابگر ویژه ویندوز است که به کلاینت Community 2 تعلق دارد، و برنامه جدیدتر برنامه دیگری با مسیر اعتبارنامه‌ای دیگر است. پروفایل جز همان یک خط تغییری نکرده است، و همین است که دیدن تفاوت را دشوار می‌کند.
در آن گزارش سه لایه در هم آمیخته می‌شود: کلاینت Community، کتابخانه هسته و رابط کاربری‌ای که کسی نصب کرده است. تنها یکی از آن‌ها هرگز این دستور را فهمید.
این گزینه در جایی که وجود دارد چه معنایی دارد
در کلاینت Community OpenVPN 2 روی ویندوز، cryptoapicert گواهی‌ای را نام می‌برد که کلاینت باید آن را در مخزن گواهی ویندوز پیدا کند، نه در یک فایل. این یک آسایش مخصوص ویندوز است و کار می‌کند چون آن کلاینت می‌داند چگونه مخزن را فهرست کند و کلید حاصل را به پشته TLS خودش بسپارد. بنابراین این دستور بخشی از زبان پیکربندی همان کلاینت است، نه ویژگی پروتکل OpenVPN. هیچ چیز در قالب انتقال آن را حمل نمی‌کند.
همان خط را در برنامه دیگری کپی کنید و واژه‌ای را کپی کرده‌اید که برنامه جدید ممکن است آن را تجزیه، نادیده بگیرد یا رد کند. یک دستور ویژگی پروتکل نیست، و این یکی حتی ویژگی همه کلاینت‌هایی که OpenVPN صحبت می‌کنند هم نیست.
کتابخانه هسته در عوض چه ارائه می‌دهد
کتابخانه OpenVPN 3 Core کتابخانه‌ای است که برنامه‌های دیگر آن را جاسازی می‌کنند و اعتبارنامه‌های بیرونی را از طریق یک API مدیریت می‌کند، نه با جست‌وجو در مخزن. برنامه جاسازی‌کننده زنجیره گواهی را تأمین می‌کند و بعداً از کتابخانه می‌خواهد با کلید بیرونی امضا کند، و کتابخانه برای این کار به برنامه فراخوانی متقابل می‌کند. این طراحی عمومی‌تری است و یعنی رابط کاربری تعیین می‌کند چه فراهم‌کنندگانی وجود دارند. در پردازش گزینه‌های خود کتابخانه، cryptoapicert در میان دستورهایی ظاهر می‌شود که پیاده‌سازی نشده‌اند، و این با همان تقسیم مسئولیت سازگار است.
وجود این فراخوانی‌ها به این معنا نیست که یک برنامه بسته‌بندی‌شده مشخص مخزن شخصی کاربر جاری را فهرست می‌کند، از فراهم‌کننده کلید خاصی پشتیبانی می‌کند یا می‌تواند درخواست کارت هوشمند را کامل کند. این‌ها ویژگی‌های رابط کاربری است و هر یک باید توسط رابط کاربری مستند شود.
رابط کاربری ویندوز در عوض چه می‌کند
OpenVPN Connect مسیر دیگری می‌رود: اپراتور فایل PKCS#12 را درون‌ریزی می‌کند که گواهی و کلید خصوصی آن را در بر دارد، به یک OpenVPN Certificate Store که برای همین منظور ساخته شده است منتقل می‌کند و سپس گواهی بیرونی را به پروفایل اختصاص می‌دهد. این یک گام درون‌ریزی عامدانه است، نه کشف خودکار هر چیزی که تصادفاً در مخزن شخصی قرار دارد. این تمایز وقتی مهم می‌شود که کسی فرض کند گواهی‌ای که برای هدفی دیگر نصب شده به‌سادگی در فهرست کلاینت ظاهر می‌شود.
درون‌ریزی پیامدی برای سیاست کلید هم دارد، زیرا صادر کردن کلید به فایل P12 دقیقاً همان چیزی است که کلید غیرقابل‌صدور برای جلوگیری از آن طراحی شده است. این پرسشی از جنس سیاست است نه پیکربندی، و پیش از آن‌که کسی درون‌ریزی را بیازماید سزاوار پاسخ است.
مسیری را انتخاب کنید که با سیاست کلید هم‌خوان باشد
اگر اعتبارنامه قابل صدور است و سیاست درون‌ریزی مستند را مجاز می‌داند، از فرایند ثبت‌نام محافظت‌شده سازمان استفاده کنید و P12 موقت و گذرواژه آن را بیرون از گزارش‌ها و اسکریپت‌ها نگه دارید. اگر کلید هرگز نباید کارت هوشمند یا فراهم‌کننده محافظت‌شده را ترک کند، ترکیبی از کلاینت و فراهم‌کننده را انتخاب کنید که آن الزام را صریحاً پشتیبانی می‌کند، یا برای نسخه‌ای که نصب کرده‌اید تأیید فروشنده را بگیرید. هیچ‌یک از دو شاخه جایگزین دیگری نیست.
افزودن دوباره دستور به پروفایل نمی‌تواند یکپارچه‌سازی‌ای را که برنامه ندارد فراهم کند. نسخه جدیدتر کلاینت هم لزوماً آن را اضافه نمی‌کند، زیرا این توانایی به طراحی خود رابط کاربری تعلق دارد.
وقتی کلید محلی کار کند، سرور همچنان هویت گواهی، زنجیره و مجوزدهی را بررسی می‌کند. کلید محلی قابل استفاده و هویت VPN پذیرفته‌شده دو نتیجه جداگانه‌اند و جدا نگه داشتن آن‌ها همان چیزی است که نمی‌گذارد محدودیت رابط کاربری به سیاست گواهی تضعیف‌شده تبدیل شود.