گواهی دیجیتال یک اتصال ssl ایمن. راه اندازی سیستم های پرداخت ارتباط دو طرفه ssl با سیستم پرداخت

شما می توانید یک تجارت کوچک راه اندازی کنید. به عنوان مثال، فروش مجدد دامنه ها و گواهینامه های SSL را سازماندهی کنید. شما برای فروشندگان موجود مشتری پیدا می کنید و به صورت تخفیف و حاشیه پاداش دریافت می کنید - به عبارت دیگر، تبدیل به یک فروشنده می شوید. با استفاده از نرم افزار ISPsystem می توانید به سرعت دامنه های فروش مجدد و گواهینامه های SSL را راه اندازی کنید.

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

آنچه برای شروع نیاز دارید

برای تبدیل شدن به یک فروشنده دامنه و گواهینامه های SSL، به موارد زیر نیاز دارید:

1. سرور مجازی (VPS/VDS)
2. توافق با فروشندگان دامنه ها و گواهینامه های SSL،
3. توافق با سیستم پرداخت،
4. پلت فرم صورتحساب برای دریافت پرداخت ها،
5. سایت فروش خدمات

نصب و پیکربندی نرم افزار

برای فروش مجدد دامنه ها و گواهینامه های SSL، باید BILLmanager را روی سرور مجازی اجاره ای نصب کنید.

ادغام با فروشندگان دامنه و SSL

برای تنظیم یکپارچه سازی، از داده های دامنه و فروشندگان SSL که با آنها توافق دارید استفاده کنید. به طور معمول، ادغام به یک URL دسترسی API، یک کد فروشنده و یک کلید مجوز API نیاز دارد. داده ها ممکن است بسته به شرکت متفاوت باشد.

پس از آن، در BILLmanager در منو ادغام - پردازنده های خدماتشما می توانید یک فروش مجدد راه اندازی کنید.

همچنین می توانید فروش مجدد گواهینامه های SSL را از طریق سیستم ISP شروع کنید. شما نیازی به مذاکره مستقیم با ثبت کننده نخواهید داشت. برای انجام این کار، در بخش «پردازنده‌های خدمات»، BILLmanager 5 را انتخاب کنید و مشخصات حساب شخصی خود را وارد کنید. my.ispsystem.com.

اتصال سیستم های پرداخت

برای اینکه مشتریان بتوانند هزینه خدمات را پرداخت کنند، روش‌های پرداخت را تنظیم کنید. BILLmanager شامل بیش از 30 ماژولپرداخت: Yandex.Money، WebMoney، PayMaster، Qiwi، PayPal، انتقال بانکی و دیگران.

برای کار با یک سیستم پرداخت خاص، شما و مشتریانتان باید یک حساب یا حساب کاربری در این سیستم داشته باشید. پس بیشترین را انتخاب کنید محبوبخدمات. برای راه اندازی یکپارچه سازی، به داده هایی از سیستم پرداخت نیاز دارید: شماره کیف پول و کلید مخفی.

مشتریان وجوه را از حساب خود به حساب شما منتقل می کنند. دریافت وجه در حساب و حساب مشتری شما در BILLmanager منعکس می شود.

برای پذیرش پرداخت‌های افراد، می‌توانید به سیستم‌های الکترونیکی ساده مانند Yandex.Checkout یا WebMoney متصل شوید. اشخاص حقوقی طبق فاکتور هزینه خدمات را با انتقال بانکی پرداخت می کنند، بنابراین برای کار با آنها، روش پرداخت را به انتقال بانکی (بانک روسی) متصل کنید. اطلاعات بانکی سازمان خود را وارد کنید. اتصال به سیستم های پرداخت

تنظیم الگوهای اسناد

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

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

تنظیم الگوهای نامه و پیام

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

راه اندازی یکپارچه سازی با سایت

یکپارچه سازی وب سایت

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

کارت های کالا و خدمات

با استفاده از ابزار ویترین می توانید به سرعت تعرفه ها را در سایت قرار دهید. این ابزار به شما امکان می دهد کارتی از یک یا چند سرویس را به سایت اضافه کنید تا کاربر بتواند یکی را انتخاب کرده و سفارش دهد. قیمت ها در کارت ها به طور خودکار به روز می شوند.

برای افزودن یک کارت، باید یک اسکریپت مخصوص را در محلی که می خواهید نمایش دهید قرار دهید. می توانید اسکریپت را در مستندات بیابید: ادغام ویترین فروشگاه در یک سایت موجود.

نام تجاری

با رفتن از سایت شما به حساب شخصی خود در BILLmanager، مشتریان ممکن است مغایرتی را احساس کنند: سایت و صورتحساب متفاوت طراحی شده اند، آدرس صورتحساب حاوی آدرس IP سرور است و با آدرس سایت متفاوت است.

برای "تراز کردن" سبک ها، تنظیمات برند را تکمیل کنید: لوگوی خود را به صورت حساب اضافه کنید، رنگ رابط را تغییر دهید، پیوندهای سایت را منتشر کنید. برای اطمینان از اینکه URL صورتحساب با وب سایت متفاوت نیست، آدرس را برای BILLmanager پیکربندی کنید. به عنوان مثال، CloudLite یک آدرس وب سایت دارد cloudlite.ru، آدرس قبض - myvdc.cloudlite.ru.

گواهی دیجیتالی اتصال امن SSL

برای انتقال امن اطلاعات بین مرورگر و وب سرور، از پروتکل انتقال داده https استفاده می شود که مبتنی بر اتصال امن SSL است.

این مقاله مروری بر رمزگذاری کلید عمومی، گواهی‌های دیجیتال، زیرساخت کلید عمومی (PKI - زیرساخت کلید عمومی)، ایجاد یک مرجع گواهی، پیکربندی کانتینرهای سرولت آپاچی تامکت و JBoss برای برقراری ارتباط امن یک طرفه و دو طرفه، ایجاد یک ذخیره گواهی و نحوه ایجاد گواهی SSL با استفاده از ابزار keytool. همچنین با روش‌های بررسی گواهی‌های باطل شده در جاوا (لیست‌های CRL، پروتکل OCSP) و پیکربندی مرورگر برای کار با گواهی‌ها آشنا خواهید شد.

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

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

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

یک پیام رمزگذاری شده با کلید خصوصی می تواند توسط هر کسی که کلید عمومی را داشته باشد رمزگشایی کند.

بر اساس این الگوریتم رمزگذاری، یک اتصال SSL امن ایجاد می شود.

گواهی دیجیتال

گواهی دیجیتال یک سند الکترونیکی است که مالک را شناسایی می کند. این شامل اطلاعات اولیه در مورد مالک، کلید عمومی مالک، تاریخ انقضا، امضای دیجیتال صادرکننده (ناشر) و سایر اطلاعات ضروری است. گواهی دیجیتال دارای یک بخش پسوند (اختیاری) است که حاوی نقاط توزیع لیست ابطال، اطلاعات ناشر و موارد دیگر است. گواهی دیجیتال به شما امکان می دهد یک اتصال SSL ایمن را راه اندازی کنید. نحوه ایجاد گواهینامه SSL در ادامه این مقاله توضیح داده شده است.

ویژگی های اصلی گواهینامه های فوق عبارتند از:

گواهینامه SSL مرجع گواهی باید حاوی فیلد CA باشد که روی TRUE تنظیم شده است، که اجازه می‌دهد گواهی‌های دیگر صادر شود. این گواهی در زنجیره نهایی نیست.

گواهینامه های SSL سرور در قسمت CN (نام مشترک) باید حاوی نام دامنه یا آدرس IP باشد که در آن سرور به آن دسترسی دارد، در غیر این صورت گواهی باطل می شود.

گواهینامه های SSL مشتری شامل آدرس ایمیل، نام و نام خانوادگی مشتری است. برخلاف گواهی سرور، فیلد CN برای محتوا مهم نیست و می‌تواند شامل نام و نام خانوادگی و همچنین آدرس ایمیل باشد.

یک گواهی دیجیتال SSL در مدت اعتبار مشخص شده در فیلدهای آن معتبر تلقی می شود. بنابراین، گواهی را نمی توان قبل از تاریخ شروع، و بعد از تاریخ انقضا استفاده کرد، زیرا. سیستم هایی که با او در تماس هستند، بی اعتمادی به او را گزارش می دهند.

شرایطی وجود دارد که کاربر یا صادرکننده گواهی نیاز به تعلیق یا توقف کامل آن دارد. بیایید بگوییم که کلید خصوصی، که باید به طور ایمن ذخیره شود، گم شد یا مزاحمان به آن دسترسی پیدا کردند. در چنین شرایطی، کاربر باید با صادرکننده (ناشر) گواهی تماس بگیرد تا اعتبار آن لغو شود. همچنین ناشر می تواند در صورت اطلاع از ارائه اطلاعات جعلی از سوی مشتری، گواهی را باطل کند. برای این منظور، یک لیست خاص به نام لیست ابطال گواهی (CRL) ایجاد می شود. این لیست شامل شماره سریال گواهی، تاریخ انقضای آن و دلیل ابطال می باشد. از لحظه ای که گواهی وارد CRL می شود، نامعتبر تلقی می شود و ناشر مسئولیتی در قبال محتوای چنین گواهینامه ای ندارد. یکی از روش های بررسی لیست CRL، پروتکل OCSP است، اما برای این کار نیاز به حضور یک پاسخ دهنده OCSP با مرجع صدور گواهینامه است.

زیرساخت کلید عمومی (PKI)

وظیفه اصلی زیرساخت کلید عمومی (PKI) تعیین خط مشی برای صدور گواهینامه های دیجیتال است.

برای صدور و لغو گواهینامه های SSL، تولید لیست های ابطال (CRL)، به نرم افزار (نرم افزار) خاصی نیاز دارید. نمونه ای از این نرم افزارها Microsoft CA (بخشی از MS Windows Server 2000/2003/2008)، OpenSSL (توزیع شده در سیستم عامل های مشابه یونیکس) است. این نرم افزار بر روی تجهیزات مرکز صدور گواهینامه میزبانی می شود.

مرجع صدور گواهینامه (CA) سازمانی است که گواهینامه های دیجیتال SSL را بر اساس داده های ارائه شده توسط مشتری صادر می کند. مرجع صدور گواهینامه تنها مسئول صحت داده های ارائه شده در گواهی SSL است، به این معنی که صاحب گواهی دقیقاً همان کسی است که ادعا می کند.

رایج ترین CA در جهان Verisign و Comodo هستند. 99% مرورگرها و اکثر نرم افزارهای سرور به این گواهینامه های CA اعتماد دارند. ایجاد یک مرجع صدور گواهینامه در زیر توضیح داده شده است.

اتصال امن SSL با احراز هویت دو طرفه

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

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

شکل یک نمودار است که مراحل ایجاد یک اتصال SSL امن را نشان می دهد.

شکل 1 - طرحی برای ایجاد یک اتصال SSL امن با احراز هویت دو طرفه

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

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

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

ایجاد یک مرجع صدور گواهینامه

برای اهداف آزمایشی یا زمانی که خرید گواهی دیجیتال عملی نیست، باید CA خود را ایجاد کنید.

CA ریشه یک CA است که همه به آن اعتماد دارند. دارای گواهینامه SSL است که با کلید خصوصی خود امضا شده است. چنین گواهینامه های SSL را خود امضا می گویند.

کلید خصوصی CA ریشه باید بسیار امن نگه داشته شود، زیرا اگر گم یا دزدیده شود، اعتماد به تمام گواهی‌های SSL زیرمجموعه از بین می‌رود.

CA تابع یک CA است که گواهینامه های SSL را برای مشتریان صادر می کند. گواهی مرجع صدور گواهینامه تابعه با کلید خصوصی مرجع برتر صدور گواهینامه امضا می شود. مراکز صدور گواهینامه، سرورهای وب، مرورگرهای وب، سرویس گیرندگان پست الکترونیکی که برای آنها گواهینامه هایی از نوع مورد نیاز تولید می شود، می توانند به عنوان مشتریان یک مرکز صدور گواهینامه تابع عمل کنند. انواع گواهی ها توسط خط مشی مرجع صدور گواهینامه تعیین می شود.

از موارد فوق چنین استنباط می شود که زنجیره ای از گواهی ها از CA ریشه تا گواهی مشتری نهایی ایجاد می شود.

شکل 2 - زنجیره گواهی

برای ایجاد یک مرجع صدور گواهینامه، از یک طرح دو سطحی که در شکل 3 نشان داده شده است استفاده خواهیم کرد. CA ریشه گواهی SSL خود و گواهینامه های SSL CAهای تابعه را امضا می کند. لازم به ذکر است که هر چه سطوح بیشتری استفاده شود، طرح از امنیت بیشتری برخوردار است.

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

شکل 3 - طرح دو سطحی مرکز صدور گواهینامه

نمونه ای از سازماندهی یک مرجع صدور گواهینامه بر اساس Microsoft CA را می توان در مقاله استقرار زنجیره ای از مقامات صدور گواهینامه مبتنی بر Microsoft CA یافت.

دریافت گواهی SSL سرور از CA و پیکربندی یک کانتینر Servlet

گواهی دیجیتال سرور SSL به شما امکان می دهد یک اتصال SSL امن ایجاد کنید که به شما امکان می دهد داده ها را به صورت رمزگذاری شده انتقال دهید.

برای به دست آوردن گواهی که توسط کانتینر servlet استفاده می شود، باید یک درخواست امضای گواهی (CSR) برای CA ایجاد کنید. درخواست حاوی اطلاعات اولیه درباره سازمان و کلید عمومی است.

فیلد اصلی که باید به درستی پر شود Common Name (CN) نامیده می شود. در این قسمت باید نام دامنه یا آدرس IP میزبانی که کانتینر servlet در آن قرار دارد را مشخص کنید.

برای تولید یک کلید خصوصی و عمومی و درخواست گواهی SSL، می‌توانید از ابزار keytool موجود در JDK (کیت توسعه جاوا) استفاده کنید.

در خط فرمان، دستور زیر را وارد کنید:

$JAVA_HOME\bin> keytool -genkey -alias -keyalg -keystore

شکل 4 - ایجاد یک فروشگاه گواهی SSL با ابزار keytool

این دستور keytool یک فروشگاه گواهی به نام ایجاد می کند ، که کلید خصوصی و گواهی SSL خود امضا شده را با استفاده از الگوریتم RSA رمزگذاری شده ذخیره می کند. می توانید با نام به گواهی SSL دسترسی داشته باشید .

در طول ایجاد مخزن، ابزار keytool از شما می خواهد که یک رمز عبور برای دسترسی به مخزن، اطلاعات مربوط به سازمان و یک رمز عبور برای کلید مخفی (خصوصی) وارد کنید. هنگام پاسخ دادن به سوال keytool "نام و نام خانوادگی شما چیست؟" شما باید نام دامنه یا آدرس IP میزبان را وارد کنید، زیرا مقدار پاسخ به عنوان فیلد CN گواهی SSL استفاده خواهد شد.

پس از اینکه keystore توسط ابزار keytool تولید شد، باید درخواستی از مرجع صدور گواهینامه برای امضای گواهی SSL ارسال شود. این کار با دستور زیر انجام می شود:

$JAVA_HOME\bin> keytool -certreq -keyalg RSA -نام مستعار -فایل -فروشگاه کلید

در پرونده درخواست گواهی ذخیره می شود. پس از آن فرم مخصوصی در سایت مرکز صدور گواهینامه پر می شود و محتویات این فایل در یکی از فیلدها کپی می شود.

برای صدور گواهینامه SSL به یک سازمان، مرکز صدور گواهینامه ممکن است به اسناد تشکیل دهنده، گواهی ثبت و غیره نیاز داشته باشد. پس از دریافت درخواست گواهی SSL، مرکز صدور گواهینامه با مقایسه داده های درخواست گواهی و مدارک ارسال شده، تأیید را انجام می دهد. ، و سپس درخواست را امضا می کند. درخواست امضا شده گواهی است.

شکل 5 - طرحی برای دریافت گواهی سرور

پس از دریافت گواهی از یک مرجع صدور گواهینامه، پس از افزودن گواهینامه های SSL مقامات صدور گواهینامه ریشه و میانی، باید آن را در فروشگاه قرار دهید. برای افزودن گواهینامه های SSL به حافظه، از دستورات زیر ابزار keytool استفاده کنید:

1) افزودن گواهی CA ریشه با ابزار keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias rootca -file -فروشگاه کلید

2) افزودن یک گواهی CA میانی با ابزار keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias subca -file -فروشگاه کلید

3) جایگزینی گواهی خودامضا شده با گواهی امضا شده در مرجع صدور گواهینامه (مقدار پارامتر نام مستعار مشخص شده است که هنگام ایجاد مخزن استفاده شده است): $JAVA_HOME\bin> keytool -import -trustcacerts -alias -فایل -فروشگاه کلید

برای اینکه برنامه‌ها از اتصال SSL ایمن استفاده کنند، ظرف سرولت باید پیکربندی شود. برای Apache Tomcat و JBoss، محتوای زیر را به فایل server.xml اضافه کنید:

clientAuth="false" sslProtocol="TLS"

keystoreFile=" "

keystorePass=" "

keystoreType = "JKS"

keyAlias=" "

این ورودی به کانتینر servlet اجازه می دهد تا با استفاده از یک گواهی دیجیتال SSL، که در فروشگاه قرار دارد، یک اتصال امن برقرار کند با رمز عبور توسط نام مستعار .

پیکربندی فوق از احراز هویت یک طرفه استفاده می کند، یعنی. ارائه گواهی دیجیتال SSL فقط از سرور مورد نیاز است. برای ایجاد یک احراز هویت دو طرفه، به عنوان مثال. هنگامی که مشتری یک گواهی دیجیتال SSL نیز ارائه می دهد، باید پیکربندی کانتینر servlet را به صورت زیر تغییر دهید:

maxThreads="150" scheme="https" safe="true"

clientAuth="true" sslProtocol="TLS"

keystoreFile="

keystorePass=" "

keystoreType = "JKS"

keyAlias=" "

truststoreFile="

truststorePass=" "trussttoreType="JKS"

در این پیکربندی، پارامتر clientAuth=”true” تنظیم می شود و ذخیره اعتماد متصل می شود. ایجاد یک فروشگاه از گواهینامه های SSL قابل اعتماد توسط ابزار keytool به همان روش یک فروشگاه معمولی انجام می شود. شما باید گواهی‌های مقامات صدور گواهینامه را که گواهی‌های دیجیتال صادر می‌کنند، که ظرف سرولت باید به آن اعتماد کند، به آن اضافه کنید. در غیر این صورت، گواهی‌های ارائه‌شده توسط SSL در حین احراز هویت توسط کانتینر servlet رد می‌شوند. آنها قابل اعتماد نخواهند بود

بررسی گواهی های باطل شده در سرور

3 روش برای تأیید اعتبار یک گواهی برای ابطال وجود دارد: تأیید اعتبار CRL ایستا، تأیید اعتبار CRL پویا و تأیید اعتبار OCSP. بیایید این روش ها را با جزئیات بیشتری در نظر بگیریم.

1) بررسی استاتیک CRL

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

برای اتصال CRL در کانتینرهای سرور Apache Tomcat و Jboss، ویژگی زیر را به کانکتور ssl اضافه کنید:

crlFile=”

نقطه ضعف این روش نیاز به نظارت مداوم مدیر بر روی به روز رسانی فایل CRL است.

2) بررسی CRL پویا

این روش به شما اجازه می دهد تا بررسی CRL را به صورت خودکار انجام دهید. این امر مستلزم آن است که ویژگی CRLDistributionPoint در بخش پسوند گواهی SSL ارائه شده توسط مشتری مشخص شود، که نشانی اینترنتی را که لیست ابطال گواهی (CRL) در آن قرار دارد، مشخص می کند.

برای اینکه گواهی SSL کلاینت در CRL تایید شود، باید دو پارامتر برای ماشین مجازی جاوا پیکربندی شود. این گزینه ها را می توان در اسکریپت راه اندازی کانتینر servlet مشخص کرد. برای Apache Tomcat و Jboss در ویندوز به این صورت است:

تنظیم JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation=true

Dcom.sun.security.enableCRLDP=true -Djava.security.debug=certpath

گزینه java.security.debug=certpath به شما امکان می دهد تا احراز هویت گواهی را در کنسول کانتینر در حال اجرا مشاهده کنید.

از معایب این روش می توان به تاخیر در دسترسی به یک منبع محافظت شده مرتبط با دانلود یک فایل CRL بزرگ اشاره کرد.

3) اعتبارسنجی با استفاده از پروتکل OCSP

OCSP (پروتکل وضعیت گواهی آنلاین) به عنوان جایگزینی برای CRL توسعه یافته است. این بررسی از زمان JDK 5 توسط فناوری JSSE (جاوا Secure Socket Extension) پشتیبانی می شود. OCSP در ارتباط با CRL کار می کند. CRL زمانی قابل دسترسی است که در حین ارتباط OCSP خطایی رخ دهد. اگر OCSP وضعیت گواهی SSL را تعیین کرده باشد، بررسی CRL انجام نمی شود. یک گواهی می تواند یکی از سه وضعیت را داشته باشد: لغو، عادی، ناشناخته.

برای اعتبارسنجی OCSP، گواهی باید دارای یک ویژگی AuthorityInfoAccess در بخش پسوند با مقدار URL پاسخگوی OCSP باشد.

OCSP Responder نرم افزاری است که در منبع شبکه یک مرجع صدور گواهی قرار دارد که درخواست ها را برای تعیین وضعیت گواهی پردازش می کند و نتایج تأیید را صادر می کند.

برای اینکه ماشین مجازی جاوا بتواند OCSP را بررسی کند، باید ویژگی ocsp.enable=true را تنظیم کنید. این ویژگی در فایل JAVA_HOME\jre\lib\security\java.security پیکربندی شده است. در این فایل می توانید آدرس پاسخ دهنده OCSP را در ویژگی ocsp.responderURL مشخص کنید. اگر URL پاسخگو در گواهی SSL وجود نداشته باشد از این ویژگی استفاده خواهد شد.

دریافت گواهی SSL مشتری از یک مرجع صدور گواهینامه و پیکربندی یک مرورگر وب

موقعیت هایی وجود دارد که نه تنها سرور باید ثابت کند که همان چیزی است که ادعا می کند، بلکه زمانی که سرور از مشتری می خواهد هویت خود را با یک گواهی دیجیتال اثبات کند.

با انجام این کار با استفاده از یک مرجع صدور گواهی، می توانید گواهی SSL مشتری را بدون ایجاد درخواست خودتان دریافت کنید. برای انجام این کار، در وب سایت CA، شما باید فرمی را پر کنید که نام، نام خانوادگی، آدرس ایمیل و غیره را مشخص کنید. بر اساس این داده ها، یک درخواست ایجاد می شود. در این شرایط، تولید یک کلید مخفی به مرجع صدور گواهینامه اختصاص داده می شود. پس از تایید داده ها و امضای درخواست، فایلی حاوی کلید مخفی و گواهینامه و همچنین فایل های مراجع صدور گواهینامه ریشه و میانی برای مشتری ارسال می شود.

پس از دریافت فایل های گواهی، باید نرم افزاری را پیکربندی کنید که اتصالات ایمن را ایجاد کند.

شکل 6 - طرحی برای دریافت گواهی مشتری SSL

به عنوان مثال، اجازه دهید گواهی SSL مشتری را در مرورگر وب Microsoft Internet Explorer نصب کنیم. برای انجام این کار، ابزارها > گزینه های اینترنت را از منو انتخاب کنید. در برگه "محتوا" "گواهی ها ..." را انتخاب کنید.

شکل 7 - مدیریت گواهینامه های SSL در MS Internet Explorer

با کلیک بر روی دکمه "Import..." Certificate Import Wizard را اجرا کنید. در این ویزارد مسیر گواهی CA ریشه را مشخص کنید. سپس، فروشگاه Trusted Root Certification Authorities را انتخاب کنید تا گواهی را به آن اضافه کنید.

به همین ترتیب، گواهی‌های CA میانی به فروشگاه "CAs میانی" و گواهی مشتری به فروشگاه "شخصی" اضافه می‌شوند.

شکل 8 - زنجیره گواهی

برای مشاهده محتویات گواهی، گواهی SSL مورد نظر را انتخاب کرده و روی دکمه «مشاهده» کلیک کنید.

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

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

بررسی گواهی های باطل شده در مشتری

اگر مشتری از مرورگر وب MS Internet Explorer استفاده می کند، می توان آن را برای بررسی گواهی های ارسال شده در CRL پیکربندی کرد. برای این کار به تب «پیشرفته» در «گزینه‌های اینترنت» بروید و دو ویژگی «بررسی ابطال گواهی‌های ناشر» و «بررسی ابطال گواهی‌های سرور» را علامت بزنید.

تنظیمات سرور دسترسی به وب اضافی

راه اندازی یک اتصال امن (بر اساس لایه های سوکت امن، SSL)

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

1. تغییراتی در فایل پیکربندی سرور دسترسی به وب ایجاد کنید:

· مرحله 1: برنامه Web Access Server Configuration Utility را اجرا کنید C:\Program Files\DIRECTUM Company\WebAccessConfig\DirWebConfigurator.exe.

· مرحله 2. پنجره "انتخاب وب سایت سرور دسترسی به وب".مستقیم":

آ) در لیست کشویی، وب سایت سرور دسترسی به وب را انتخاب کنیدمستقیم . به‌طور پیش‌فرض، «سرور دسترسی به وب» نام دارد.مستقیم"؛

ب) روی دکمه کلیک کنید خوب ;

· مرحله 3. پنجره "تنظیمات سرور دسترسی به وب".مستقیم "، برگه "عمومی":

آ) در لیست کشویی «اتصال ایمن»، مقدار «برای از راه دور» را انتخاب کنید. اگر لازم است یک اتصال امن برای کاربران شبکه محلی ایجاد کنید، سپس مقدار "برای راه دور و محلی" را انتخاب کنید.

ب) روی دکمه کلیک کنید خوب .

2. IIS را برای کار با SSL پیکربندی کنید -اتصالات با نصب گواهی احراز هویت سرور. برای انجام این کار، یک گواهی با هدف "دستیابی به شناسایی از یک کامپیوتر راه دور" با قابلیت صادرات به سرویس گواهی شرکت تولید می شود که در نتیجه باید * را دریافت کنید. pfx -فایل کلید خصوصی

3. اگر از Certificate Web Service استفاده می کنیدپنجره ها سپس موارد زیر را انجام دهید:

آ) هنگام تولید گواهی، گزینه صادرات احتمالی گواهی را مشخص کنید. پس از نصب گواهی بر روی سیستم محلی، می توان آن را با استفاده از آن مشاهده کرداینترنت اکسپلورر – آیتم منوی «گزینه‌های اینترنت»، برگه «محتوا»، دکمه گواهینامه ها . برای صادرات، از دکمه استفاده کنید صادرات ، مشخص كردن بله، کلید خصوصی صادر شودو رمز عبور را وارد کنید.

ب) گواهی را وارد کنید برای انجام این کار، در تب "Directory Security" کارت ویژگی های وب سایت، روی دکمه کلیک کنید گواهینامه ها و دستورالعمل های روی صفحه را دنبال کنید تا گواهی را با استفاده از رمز عبوری که در مرحله قبل تنظیم شده بود وارد کنید. پس از دریافت گواهی، پورت اتصال امن 443 ایجاد و کار خواهد شد SSL ممکن خواهد شد.

4. برای پشتیبانی از اتصالات باز (غیر ایمن)، باید این گزینه را تنظیم کنید پشتیبانی از اتصالات HTTP باز مجاز استدر برگه وب سایت از ویژگی های وب سایت.

5. برای اینکه بتوانید گواهی مرجع صدور گواهینامه را با استفاده از پیوند از صفحه ورود به سیستم نصب کنید، به کاربری نیاز دارید که گروه برنامه را اجرا می کند.مستقیم "، "خواندن" و "درخواست گواهی" را در "مرجع صدور گواهی" در ویژگی های مرجع صدور گواهینامه مورد نظر در برگه "امنیت" مجاز کنید.

همچنین ببینید:

SSL نسخه 3.0 اساس پروتکل امنیت لایه حمل و نقل (TLS) بود که در جزئیات جزئی با SSL متفاوت است. در ادامه، اصطلاح SSL به هر دو پروتکل اشاره خواهد کرد.

10.1. تبادل داده در SSL

فرآیند تبادل داده با استفاده از پروتکل SSL در شکل نشان داده شده است. 10.1.

هر زمان که یک کلاینت به یک سرور متصل می شود، یک جلسه SSL شروع می شود. اتصالات متعدد در هر جلسه امکان پذیر است. اگر مشتری به سرور دیگری متصل شود، یک جلسه جدید بدون شکستن جلسه فعلی شروع می شود. هنگام بازگشت به سرور اول، کاربر می تواند اتصال را با استفاده از پارامترهای تنظیم شده قبلی از سر بگیرد یا یک اتصال جدید ایجاد کند. برای جلوگیری از حملات، SSL شامل یک محدودیت زمانی جلسه است (معمولاً 24 ساعت)، پس از آن جلسه خاتمه می یابد و برای ادامه ارتباط با سرور باید یک جلسه جدید ایجاد شود.

یک جلسه SSL با مقادیر زیر مشخص می شود.

• شناسه جلسه (Session_ID) - یک عدد تصادفی تولید شده در سمت مشتری که به شما امکان می دهد به یک جلسه از قبل ایجاد شده بازگردید.
• گواهی های میزبان (Client_Certificate و Server_Certificate) - گواهی شرکت کننده در تبادل اطلاعات مطابق با استاندارد ISO/IEC 9594-8.
• روش فشرده سازی - الگوریتمی برای فشرده سازی داده های ارسال شده. الگوریتم های پشتیبانی شده در RFC 3749 مشخص شده اند.
• مشخصات رمز - پارامترهای الگوریتم های رمزنگاری را تعریف می کند:
  • برای تبادل کلید و احراز هویت: سیستم رمزگذاری کلید عمومی RSA، پروتکل تولید کلید مخفی مشترک Diffie-Hellman، DSA (الگوریتم امضای دیجیتال)، Fortezza.
  • برای رمزگذاری متقارن: RC2، RC4، DES، 3DES، IDEA، AES؛
  • برای هش کردن: SHA، MD5.
• کلید مخفی جلسه (Master_Secret) کلید مخفی مشترک بین مشتری و سرور است.
• پرچم Resume - پارامتری که تعیین می کند آیا پارامترهای انتخاب شده می توانند برای اتصال جدید در جلسه جاری ذخیره شوند یا خیر.
• یک اتصال SSL با مقادیر زیر مشخص می شود.
• اعداد تصادفی (Client_Random و Server_Random) برای تولید راز مشترک استفاده می شود.
• کلیدهایی برای رمزگذاری/رمزگشایی اطلاعات (Client_Write_Secret = Server_Read_Secret و Server_Write_Secret = Client_Read_Secret).
• کلیدهای امضای پیام ها (Server_MAC_Write_Secret و Client_MAC_Write_Secret).
• بردارهای اولیه سازی (Server_IV و Client_IV) - پیام ها را برای الگوریتم های رمزگذاری بلوک همگام سازی می کنند.
• دو عدد متوالی برای سرور و کلاینت برای جلوگیری از حملات رهگیری و پخش مجدد.

10.2. پروتکل های SSL

SSL شامل چهار پروتکل است که در شکل 1 نشان داده شده است. 10.2:

• دست دادن؛
• رکورد؛
• هشدار؛
• CCS (تغییر مشخصات رمز).

برنج. 10.2.

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

تنظیمات جلسه که به صورت شماتیک در شکل نشان داده شده است. 10.3 معمولاً توسط مشتری با یک پیام ClientHello راه اندازی می شود (گاهی اوقات سرور با ارسال یک پیام HelloRequest که نشان می دهد سرور برای یک Handshake آماده است شروع می شود) که در آن مشتری پارامترهای زیر را ارسال می کند:

• نسخه SSL پشتیبانی شده توسط مشتری؛
• شناسه جلسه - مقداری که با آن می توان جلسه را بعداً از سر گرفت.
• شماره تصادفی Client_Random;
• لیستی از الگوریتم‌های فشرده‌سازی، رمزگذاری و هش کردن اطلاعات پشتیبانی شده توسط مشتری.

در پاسخ به این پیام، سرور یک پیام ServerHello حاوی پارامترهای زیر ارسال می کند:

• نسخه SSL پشتیبانی شده توسط سرور؛
• اعداد تصادفی Server_Random;
• فهرستی از الگوریتم‌ها برای فشرده‌سازی، رمزگذاری و هش کردن اطلاعات که هنگام اجرای یک جلسه یا اتصالات استفاده می‌شوند.

علاوه بر این پیام، سرور گواهینامه خود را ارسال می کند. در صورتی که الگوریتم های مورد استفاده نیاز به گواهی مشتری داشته باشند، سرور یک درخواست گواهی را به مشتری ارسال می کند - CertificateRequest. سپس سرور یک پیام ServerHelloDone را برای مشتری ارسال می کند که نشان دهنده پایان پیام ServerHello است.

اگر کلاینت از الگوریتم های پیشنهادی سرور پشتیبانی نکند، یا گواهی خود را در پاسخ به درخواست مناسب ارسال نکرده باشد، ایجاد جلسه لغو می شود. در غیر این صورت، کلاینت گواهی سرور را تأیید می کند، یک Pre_Master_Secret ایجاد می کند، آن را با کلید عمومی سرور که از گواهی سرور مشتق شده است، رمزگذاری می کند و مقدار حاصل را در یک پیام ClientKeyExchange ارسال می کند. سرور پیام دریافتی را با کلید خصوصی خود رمزگشایی می کند و Pre_Master_Secret را استخراج می کند. بنابراین، هر دو طرف (کلینت و سرور) دارای سه مقدار هستند - Server_Random، Client_Random و Pre_Master_Secret و می توانند Master_Secret را طبق طرح نشان داده شده در شکل انجام دهند. 10.4.

پس از آن، هر دو طرف یک پیام Finished ارسال می کنند که پارامترهای جلسه رمزگذاری شده روی کلید مخفی Master_Secret است و نمادی از تکمیل فرآیند ایجاد یک جلسه جدید است.

اتصال با ارسال پیام‌های ChangeCipherSpec به کلاینت و سرور تکمیل می‌شود که تأیید پذیرش دو طرف الگوریتم‌های فشرده‌سازی، رمزگذاری و هش کردن اطلاعات و پیام‌های Finished است که نمادی از تکمیل فرآیند ایجاد یک اتصال جدید است.

رکورد.این پروتکل برای تبدیل داده های ارسال شده توسط لایه نشست به لایه انتقال و بالعکس طراحی شده است. تبدیل داده هامطابق با طرح نشان داده شده در شکل رخ می دهد. 10.7.

اطلاعات ارسال شده توسط فرستنده به بلوک هایی تقسیم می شود که بزرگتر از 2^14 + 2048 بایت نیست. سپس هر بلوک با استفاده از الگوریتم فشرده سازی انتخاب شده فشرده می شود. پس از آن، MAC هر بلوک محاسبه شده و به آخرین بلوک متصل می شود. قطعات دریافتی برای جلوگیری از حملات به ترتیب شماره گذاری می شوند، با استفاده از الگوریتم انتخاب شده رمزگذاری شده و به لایه حمل و نقل. گیرنده قطعات دریافتی را رمزگشایی می کند، ترتیب شماره آنها و یکپارچگی پیام ها را بررسی می کند. سپس قطعات باز شده و در یک پیام واحد ترکیب می شوند.

CSS.پروتکل CSS از یک پیام واحد تشکیل شده است که به پروتکل ضبط اجازه می دهد تا کار کند تبدیل داده هابا استفاده از الگوریتم های انتخاب شده

هشدار.این پروتکل پیام های خطایی ایجاد می کند که در حین انتقال داده ها یا برقراری یک جلسه یا اتصال رخ می دهد. بسته به ماهیت خطاها، اخطار صادر می شود یا اتصال/جلسه قطع می شود. نمونه هایی از خطاها در جدول آورده شده است. 10.2.

10.3. استفاده از SSL در سیستم های پرداخت

اکثر سیستم های پرداخت الکترونیکی، به ویژه فروشگاه های آنلاین، از مرورگرهای وب در کار خود استفاده می کنند. با توجه به اینکه SSL تقریباً در تمام مرورگرهای وب شناخته شده تعبیه شده است، امنیت داده های ارسالی در 99٪ موارد [3GPP TR 21.905: Vocabulary for 3GPP Specifications.] بر اساس آن است. با این حال، باید به جنبه‌های منفی SSL اشاره کرد که هنگام تصمیم‌گیری برای استفاده از این پروتکل هنگام سازماندهی یک کانال امن برای تعامل بین شرکت‌کنندگان در تراکنش‌های پرداخت الکترونیکی، باید در نظر گرفته شود.

• عدم احراز هویت خریدار علیرغم اینکه پروتکل SSL توانایی درخواست گواهی خریدار را دارد، احراز هویت خریدار اختیاری است و به عنوان یک قاعده انجام نمی شود، که استفاده از SSL را در هنگام تراکنش با حساب بانکی غیرممکن می کند.
• احراز هویت فروشنده با URL. گواهی ارائه شده توسط فروشنده فقط نشان دهنده ارتباط دومی با URL مشخص شده است، در حالی که هیچ اطلاعاتی در مورد تعامل بین فروشنده و بانک ارائه دهنده سیستم پرداخت مشخص وجود ندارد.
• باز بودن مشخصات خریدار. علیرغم این واقعیت که تمام اطلاعات ارسال شده تحت SSL رمزگذاری شده است، جزئیات بانکی خریدار به صورت شفاف برای فروشنده ارسال می شود.
• محدودیت های صادراتی پروتکل علیرغم این واقعیت که در سال 1999 وزارت امور خارجه ایالات متحده تصمیم به حذف محدودیت های صادراتی گرفت، برخی از مرورگرها از پروتکل SSL با محدودیت های صادراتی در طول کلیدها برای الگوریتم های رمزگذاری اطلاعات پشتیبانی می کنند که به طور قابل توجهی امنیت داده های ارسال شده را کاهش می دهد.

کتاب جدیدی با عنوان «بازاریابی محتوای رسانه‌های اجتماعی: چگونه وارد ذهن مشترکان شویم و آنها را عاشق برند خود کنیم» منتشر کرده‌ایم.

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

HTTPS چیست

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

چرا به گواهی SSL نیاز دارید

این یک امضای دیجیتال منحصر به فرد سایت را تشکیل می دهد که به ایمن شدن اتصال کمک می کند. بدون گواهی SSL، مهم نیست که چقدر تلاش می کنید، نمی توانید پروتکل HTTPS را دریافت کنید. آن شامل:

• دامنه سایت؛
• نام قانونی کامل شرکت مالک؛
• آدرس فیزیکی شرکت؛
• مدت اعتبار گواهی؛
• جزئیات توسعه دهنده SSL

همچنین برای اتصال به هر سیستم پرداختی مانند Yandex.Money به گواهی نیاز دارید. منطق ساده است - هیچ کس به شما اجازه نمی دهد پول دیگران را به خطر بیندازید.

نحوه انتخاب گواهینامه SSL

آنها بسته به درجه حفاظت و.

SSL اعتبار سنجی دامنه

ساده ترین گزینه. پس از تأیید مالکیت دامنه کار خواهد کرد. شما می توانید این کار را به سه روش انجام دهید:

• از طریق ایمیل. ایمیلی حاوی دستورالعمل‌های تأیید دریافت خواهید کرد. ایمیل از دامنه Whois یا صندوق‌های پستی مدیر یا مدیر وب‌سایت به عنوان آدرس ارسال انتخاب می‌شوند.

• از طریق ورودی DNS. اگر یک سرور ایمیل راه اندازی کرده اید، یک ورودی DNS سفارشی ایجاد کنید. طبق آن، سیستم تأیید می کند که شما واقعاً مالک سایت هستید. این روش خودکار و مناسب برای کسانی است که ایمیل Whois را در تنظیمات پنهان کرده اند.

• از طریق فایل هش. یک فایل txt ویژه را روی سرور خود قرار دهید تا مرجع صدور گواهینامه بتواند وجود آن را تعیین کند.

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

اعتبار سنجی کسب و کار

این نوع گواهینامه SSL از امنیت بیشتری برخوردار است زیرا تأیید می کنید که شرکت به سایت متصل است. برای انجام این کار، باید چندین سند را به مرکز تأیید ارسال کنید و با شماره شرکت تماس بگیرید. گواهینامه های اعتبار سنجی تجاری به 3 نوع تقسیم می شوند:

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

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

• SAN SSL. مزیت اصلی این نوع گواهی پشتیبانی از نام های دامنه جایگزین است: خارجی و داخلی.

• SSL امضای کد. کد و محصولات نرم افزاری سایت را تایید می کند. مناسب برای توسعه دهندگان هر برنامه ای.

آیا می توانم یک گواهینامه SSL رایگان در وب سایت خود نصب کنم؟

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

نصب گواهی SSL

ابتدا باید یک درخواست CSR برای گواهی ایجاد کنید. این شامل تمام اطلاعات در مورد مالک دامنه و کلید عمومی است. اکثر ارائه دهندگان SSL به شما این امکان را به عنوان بخشی از فرآیند سفارش گواهی می دهند، اما می توانید درخواستی را در سمت سرور وب نیز ایجاد کنید.

هنگام ایجاد یک کلید CSR، باید مشخص کنید:

• نام سرور: "site.com" یا "*.site.com" اگر گواهی نامه Wildcard دریافت می کنید. ستاره به معنای هر تعداد کاراکتر قبل از نقطه است.
• کد کشور: RU، UA، KZ و غیره.
• منطقه، به عنوان مثال، منطقه ساراتوف.
• شهر.
• نام کامل سازمان یا نام مالک سایت.

درخواست CSR به مرکز تأیید ارسال می شود. در نتیجه، یک گواهی SSL و یک فایل با یک کلید خصوصی دریافت می کنید که نمی توان آن را گم کرد و در دامنه عمومی پست کرد.

پس از آن، باید گواهی را روی وب سرور نصب کنید. موارد مربوط به آپاچی و nginx را در نظر بگیرید.

آپاچی

برای انجام این کار، باید همه گواهینامه ها را در سرور آپلود کنید: هم اولیه و هم متوسط. اول از همه، شما به دومی در پوشه /usr/local/ssl/crt نیاز دارید (به طور پیش فرض استفاده می شود، در مورد شما ممکن است متفاوت باشد). تمام گواهی ها در آن ذخیره می شود.

پس از آن، گواهی اصلی را دانلود کنید، آن را در هر ویرایشگر متنی باز کنید و کل مطالب را به همراه خطوط "BEGIN" و "END" کپی کنید.

در پوشه /ssl/crt/ فایلی به نام vashsite.crt ایجاد کنید و محتوای گواهی را در آن قرار دهید.

فایل کلید خصوصی را به پوشه /usr/local/ssl/private/ منتقل کنید

در فایل VirtualHost، خطوط را اضافه کنید:

موتور SSL روشن است

SSLCertificateKeyFile /usr/local/ssl/private/private.key

SSLCertificateFile /usr/local/ssl/crt/yoursite.crt

SSLCertificateChainFile /usr/local/ssl/crt/intermediate.crt

باید مسیرهای معتبر برای فایل ها را مشخص کنید. تغییرات خود را ذخیره کنید و سرور را مجددا راه اندازی کنید.

nginx

در اینجا، روند نصب گواهی SSL کمی متفاوت است. ابتدا باید گواهینامه های root، intermediate و SSL را در یکی ترکیب کنید. برای این کار فایلی به نام vashsite.crt ایجاد کنید و محتویات گواهی ها را به همراه خطوط «BEGIN» و «END» (ترتیب: SSL، متوسط، ریشه) در آنجا قرار دهید. نباید خطوط خالی باشد.

تقریباً همین کار باید با کلید خصوصی انجام شود - یک فایل vashsite.key ایجاد کنید و محتویات کلید دانلود شده از وب سایت ارائه دهنده را انتقال دهید.

هر دو فایل (yoursite.crt و yoursite.key) را در فهرست /etc/ssl/ قرار دهید (این پیش فرض است اما ممکن است متفاوت باشد).

در فایل پیکربندی، VirtualHost را ویرایش کنید. اضافه کردن:

سرور(
گوش کن 443;
ssl در

ssl_certificate /etc/ssl/yoursite.crt
ssl_certificate_key /etc/ssl/yoursite.key;
server_name yoursite.com;

اگر دایرکتوری دارای گواهی و کلید با فهرست پیش فرض متفاوت است، آن را تغییر دهید.

اکنون تغییرات خود را ذخیره کرده و nginx را مجددا راه اندازی کنید.

چگونه یک اتصال HTTPS فعال به دست آوریم

پس از نصب گواهینامه های SSL، سایت در دو آدرس http://yoursite.com و https://yoursite.com در دسترس خواهد بود. شما فقط باید آخرین مورد را نگه دارید. برای انجام این کار، یک فایل robots.txt راه اندازی کنید و یک تغییر مسیر 301 از سایت قدیمی ایجاد کنید.

در "ربات ها" باید هاست را به روز کنید. مثال: میزبان: https://yoursite.com. برای تنظیم یک تغییر مسیر، باید خطوط را به فایل .htacsess اضافه کنید:

RewriteCond %(SERVER_PORT) !^443$

RewriteRule ^(.*)$ https://yoursite.com/$1.

حال باقی مانده است که موتورهای جستجو را از تغییرات مطلع کنیم. در "Webmaster" "Yandex"، یک صفحه با https اضافه کنید و آن را به عنوان صفحه اصلی برای سایت قدیمی مشخص کنید.

نتایج

ما متوجه شدیم که https چیست، چگونه آن را در سایت خود نصب کنیم و چگونه همه چیز را به درستی تنظیم کنیم. این پروتکل قبلاً به استاندارد اتصال تبدیل شده است و به مرور زمان همه سایت های زنده به آن تغییر می کنند. این فرآیند توسط موتورهای جستجو تشویق می شود - وجود یک پروتکل اتصال امن HTTPS به یکی از عوامل رتبه بندی تبدیل شده است. بنابراین، اگر می خواهید به بالا بروید، باید آن را نصب کنید.