دو گواهی مشتری با شماره‌های سریال متفاوت، کلیدهای متفاوت و حتی موضوع‌های کامل متفاوت باز هم می‌توانند به یک فایل خط‌مشی واحد برسند، چون سرور به هیچ‌یک از این‌ها نگاه نمی‌کند. سرور نامی را از گواهی می‌خواند و فایل پیکربندی مشتری متناظر را باز می‌کند. اگر هر دو گواهی نام یکسانی داشته باشند، دومی به همان لحظه‌ای که متصل می‌شود خط‌مشی اولی را به ارث می‌برد.

این تصادم در زمان ثبت ایجاد می‌شود و تنها در زمان اتصال کشف می‌شود، معمولاً وقتی دستگاهی نشانی یا مجموعه مسیرهایی را دریافت می‌کند که به ماشین دیگری تعلق دارد. برای پیشگیری باید روی این توافق کنید که سرور کدام فیلد را نگاشت می‌کند و سپس آن مقدار را پیش از امضای هر چیزی رزرو کنید.

ابزارهای گواهی شما هشدار نمی‌دهند، چون یکتایی درون X.509 و یکتایی نام خط‌مشی OpenVPN دو نیاز متفاوت هستند که سیستم‌های متفاوت آن‌ها را اعمال می‌کنند.

سرور نام را جست‌وجو می‌کند، نه اثر انگشت را

در نگاشت متداول مبتنی بر گواهی، سرور نام مشترک را از گواهی ارائه‌شده برمی‌دارد و فایلی با آن نام را در پوشه پیکربندی مشتری خود جست‌وجو می‌کند. آن فایل می‌تواند یک نشانی ثابت را تثبیت کند، مسیرها را هل دهد یا نشانه‌های دیوار آتش را برای هر مشتری اعمال کند. جست‌وجو یک تطبیق رشته‌ای با نام فایل است، بنابراین بزرگی و کوچکی حروف، فاصله‌ها و نشانه‌گذاری همه مهم‌اند.

برخی استقرارها نگاشت را عمداً جابه‌جا می‌کنند تا نام کاربری احراز هویت‌شده جای نام مشترک را بگیرد، و آن‌گاه نام کاربری است که باید یکتا باشد. در هر حال، مقداری که خط‌مشی را انتخاب می‌کند همان مقداری است که رزرو می‌کنید. پیش از صدور هر چیزی تصمیم بگیرید کدام است؛ حدس زدن پس از تصادم بیش از پرسیدن هزینه دارد.

جایی که دو مرجع بر یک نام می‌رسند

سازمانی که گواهی‌ها را از بیش از یک مرجع صادرکننده می‌پذیرد دو فرآیند ثبت مستقل را اجرا می‌کند که در یک فضای نام می‌نویسند. قواعد یکتایی هر مرجع درون خودش اعمال می‌شود، پس هر دو می‌توانند به‌طور مشروع برای همان نام مشترک صادر کنند بی‌آنکه هیچ‌یک چیزی اشتباه متوجه شود.

شماره‌های سریال کمکی نمی‌کنند. X.509 می‌خواهد شماره سریال در محدوده صادرکننده‌اش یکتا باشد، که ویژگی دفترداری همان مرجع است نه هویت جهانی دستگاه. بررسی موضوع نیز آزمونی متفاوت از بررسی نام مشترک است: دو گواهی می‌توانند یک CN مشترک داشته باشند اما در واحد سازمانی متفاوت باشند و بنابراین موضوع‌های متمایز حمل کنند. هر یک از این ویژگی‌ها می‌تواند برقرار باشد در حالی که سرور هنوز هر دو گواهی را به یک نام فایل نگاشت می‌کند.

مستندات OpenSSL CA تنظیم unique_subject را پوشش می‌دهد که نظر پایگاه داده خودش را اداره می‌کند، و نقطه شروع صادقانه خواندن پیکربندی صدور شماست، نه فرض اینکه پیش‌فرض خاصی از EasyRSA یا OpenSSL اعمال می‌شود.

نام مؤثر را پیش از امضا رزرو کنید

ثبت و نگهداری‌ای داشته باشید که یک دستگاه را به رکورد تأییدشده‌اش و از آنجا به نام دقیق فایل خط‌مشی نگاشت کند، تا یک نام یک بار تخصیص یابد و تخصیص‌یافته بماند. رزرو باید اتمی باشد، که در عمل یعنی یک محدودیت پایگاه داده یا قفلی پیرامون مرحله تخصیص-سپس-امضا، نه صفحه‌گسترده‌ای که دو نفر ویرایش می‌کنند.

سپس بررسی را بخشی از صدور کنید: وقتی نام درخواستی از قبل وجود دارد از امضا خودداری کنید، و هر مرجعی را که سرور به آن اعتماد دارد در آن بررسی بگنجانید، چون نامی که مرجع دیگر رزرو کرده نیز به همان اندازه اشغال است. درخواست ردشده با دلیل روشن ارزان‌تر از تیکتی درباره دستگاهی است که پیوسته نشانی ثابت دیگری را می‌گیرد.

تمدید نام را عمداً دوباره به کار می‌برد

صدور دوباره برای دستگاهی موجود باید شماره سریال جدیدی زیر همان نام خط‌مشی تولید کند، و این بازاستفاده مشروع است نه تصادم. آنچه باید از پیش تصمیم گرفته شود همپوشانی است: اینکه گواهی قدیمی و جدید بتوانند همزمان معتبر باشند، و چگونه اعتبارنامه قدیمی بازنشسته می‌شود.

برای حل این مشکل به سراغ duplicate-cn نروید. آن گزینه سرور اتصال‌های همزمانی را که نام یکسان ارائه می‌دهند اداره می‌کند؛ ثبت را قفل نمی‌کند، و فعال کردنش یک نشانی ثابت مشترک را برای دو ماشین همزمان ایمن نمی‌کند. ابطال معمولاً گواهی را با صادرکننده و شماره سریال شناسایی می‌کند، پس بازنشسته کردن اعتبارنامه قدیمی لازم نیست جایگزین آن را باطل کند، تا زمانی که سرور داده‌های ابطال درست را دریافت و اعمال کند.

نگاشت را با ابزارهای روی ماشین تأیید کنید

پیش از تحویل اعتبارنامه جدید به یک دستگاه، نام را از گواهی همان‌گونه که سرور خواهد خواند بخوانید، سپس آن را با فایل خط‌مشی که انتظار دارید انتخاب شود مقایسه کنید.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

فرمان اول فیلدهای موضوع را جداگانه چاپ می‌کند، که واحد سازمانی سرگردان یا فاصله دوتایی را فوراً نمایان می‌کند. دومی تأیید می‌کند که فایلی با همان نام دقیق وجود دارد، و سومی نشان می‌دهد آیا سرور برای اجازه چند نشست روی یک نام پیکربندی شده است. هر سه را روی یک گواهی تازه پیش از آنکه از مرحله ثبت خارج شود اجرا کنید، وقتی خطا هنوز هزینه‌اش یک امضاست نه یک حادثه. خروجی را همراه تیکت نگه دارید تا نفر بعد ببیند سرور در واقع چه نامی گرفته است.

با یک اتصال واقعی تمام کنید و نشانی تخصیص‌یافته و مسیرهای هل‌داده‌شده را با فایل خط‌مشی مقایسه کنید، نه با آنچه قصد نوشتنش را داشتید. اگر دو دستگاه نشانی ثابت یکسانی گزارش کنند، ثبت تصادمی دارد که هیچ بازرسی گواهی هرگز آشکار نخواهد کرد.

مقالات مرتبط