شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
این سند نحوه ایجاد، اصلاح و حذف keystoreها و truststoreها را برای Edge for the Cloud و Edge for the Private Cloud نسخههای ۴.۱۸.۰۱ و بالاتر شرح میدهد.
درباره فروشگاههای کلیدی/تراستها و میزبانهای مجازی برای Edge Cloud
فرآیند ایجاد keystores/truststores برای Edge Cloud مستلزم آن است که شما تمام قوانین مربوط به استفاده از میزبانهای مجازی را رعایت کنید. به عنوان مثال، با میزبانهای مجازی در Cloud:
- میزبانهای مجازی باید از TLS استفاده کنند.
- میزبانهای مجازی فقط میتوانند از پورت ۴۴۳ استفاده کنند.
- شما باید از یک گواهی TLS امضا شده استفاده کنید. گواهیهای امضا نشده برای استفاده با میزبانهای مجازی در فضای ابری مجاز نیستند.
- نام دامنه مشخص شده توسط گواهی TLS باید با نام مستعار میزبان مجازی مطابقت داشته باشد.
بیشتر بدانید:
- درباره TLS/SSL
- استفاده از TLS با Edge
- سوالات متداول پیکربندی میزبانهای مجازی
- درباره میزبانهای مجازی
پیادهسازی keystoreها و truststoreها در Edge
برای پیکربندی قابلیتهایی که به زیرساخت کلید عمومی، مانند TLS، متکی هستند، باید keystoreها و truststoreهایی ایجاد کنید که حاوی کلیدهای لازم و گواهیهای دیجیتال باشند.
در Edge، keystoreها و truststoreها هر دو توسط یک موجودیت keystore که شامل یک یا چند نام مستعار است، نمایش داده میشوند. یعنی، هیچ تفاوتی در پیادهسازی بین keystore و truststore در Edge وجود ندارد.
تفاوت بین keystoreها و truststoreها از انواع ورودیهایی که دارند و نحوه استفاده از آنها در TLS handshaking ناشی میشود:
- keystore - یک موجودیت keystore که شامل یک یا چند نام مستعار است، که در آن هر نام مستعار شامل یک جفت گواهی/کلید است.
- truststore - یک موجودیت keystore که شامل یک یا چند نام مستعار است، که در آن هر نام مستعار فقط شامل یک گواهی است.
هنگام پیکربندی TLS برای یک میزبان مجازی یا نقطه پایانی هدف، keystoreها و truststoreها نقشهای متفاوتی را در فرآیند handshaking TLS ارائه میدهند. هنگام پیکربندی یک میزبان مجازی یا نقطه پایانی هدف، keystoreها و truststoreها را بهطور جداگانه در برچسب <SSLInfo> مشخص میکنید، همانطور که در زیر برای یک میزبان مجازی نشان داده شده است:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>apiTLS.myCompany.com</HostAlias> </HostAliases> <Interfaces/> <Port>9006</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>false</ClientAuthEnabled> <KeyStore>ref://keystoreref</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> </SSLInfo> </VirtualHost>
در این مثال، شما نام keystore و نام مستعار مورد استفاده توسط میزبان مجازی برای keystore TLS خود را مشخص میکنید. شما از یک مرجع برای مشخص کردن نام keystore استفاده میکنید تا بتوانید بعداً وقتی گواهی منقضی شد، آن را تغییر دهید. نام مستعار شامل یک جفت cert/key است که برای شناسایی میزبان مجازی به یک کلاینت TLS که به میزبان مجازی دسترسی دارد، استفاده میشود. در این مثال، هیچ truststore مورد نیاز نیست.
اگر به یک محل نگهداری اعتماد نیاز باشد، مثلاً برای پیکربندی TLS دوطرفه، از برچسب <TrustStore> برای مشخص کردن محل نگهداری اعتماد استفاده کنید:
<VirtualHost name="myTLSVHost"> <HostAliases> <HostAlias>apiTLS.myCompany.com</HostAlias> </HostAliases> <Interfaces/> <Port>9006</Port> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://keystoreref</KeyStore> <KeyAlias>myKeyAlias</KeyAlias> <TrustStore>ref://truststoreref</TrustStore> </SSLInfo> </VirtualHost>
در این مثال، تگ <TrustStore> فقط به یک keystore اشاره میکند و نام مستعار خاصی را مشخص نمیکند. هر نام مستعار در keystore شامل یک cert یا یک زنجیره cert است که به عنوان بخشی از فرآیند handshaking TLS استفاده میشود.
قالبهای گواهی پشتیبانیشده
| قالب | آپلود API و UI پشتیبانی میشود | پشتیبانی از شمال | اعتبارسنجی شده |
|---|---|---|---|
| پی ای ام | بله | بله | بله |
| * PKCS12 | بله | بله | بله توجه: Apigee به صورت داخلی تبدیل میکند PKCS12 تا PEM. |
| * در | خیر | خیر | بله |
| * PKCS7 | خیر | خیر | خیر |
* توصیه میکنیم در صورت امکان از PEM استفاده کنید.
استفاده از حافظههای کلیدی PKCS12 با Edge برای Private Cloud 4.53.00 یا بالاتر
اگر از Edge for Private Cloud نسخه ۴.۵۳.۰۰ یا بالاتر استفاده میکنید، باید فقط از یک keystore PKCS12 برای آپلود کلیدها و گواهینامههای مرتبط در Apigee استفاده کنید. برای کمک به تبدیل کلیدها و گواهینامههای موجود خود به فرمت PKCS12/PFX، به تبدیل گواهینامهها به فرمت پشتیبانی شده مراجعه کنید.
درباره پیادهسازی یک نام مستعار
در Edge، یک keystore شامل یک یا چند نام مستعار است که هر نام مستعار شامل موارد زیر است:
- گواهی TLS به صورت فایل PEM یا PKCS12/PFX - یا گواهی امضا شده توسط یک مرجع صدور گواهی (CA)، یا فایلی حاوی زنجیرهای از گواهیها که آخرین گواهی توسط یک مرجع صدور گواهی (CA) امضا شده است، یا یک گواهی خودامضا.
- کلید خصوصی به صورت فایل PEM یا PKCS12/PFX. Edge از اندازه کلید تا 2048 بیت پشتیبانی میکند. عبارت عبور اختیاری است.
در Edge، یک truststore شامل یک یا چند نام مستعار است که هر نام مستعار شامل موارد زیر است:
- گواهی TLS به عنوان یک فایل PEM - یا گواهی امضا شده توسط یک مرجع صدور گواهی (CA)، زنجیرهای از گواهیها که در آن آخرین گواهی توسط یک مرجع صدور گواهی امضا شده است، یا یک گواهی خودامضا.
اج یک رابط کاربری و API ارائه میدهد که شما برای ایجاد keystoreها، ایجاد نامهای مستعار، آپلود جفتهای گواهی/کلید و بهروزرسانی گواهیها از آنها استفاده میکنید. رابط کاربری و API که برای ایجاد یک truststore استفاده میکنید، همان رابط کاربری و API است که برای ایجاد keystore استفاده میکنید. تفاوت این است که وقتی یک truststore ایجاد میکنید، نامهای مستعاری ایجاد میکنید که فقط شامل یک cert هستند.
درباره قالب فایلهای گواهی و کلید
شما میتوانید گواهیها و کلیدها را به صورت فایلهای PEM یا فایلهای PKCS12/PFX نمایش دهید. فایلهای PEM با فرمت X.509 مطابقت دارند. اگر گواهی یا کلید خصوصی شما توسط یک فایل PEM تعریف نشده است، میتوانید با استفاده از ابزارهایی مانند openssl آن را به یک فایل PEM تبدیل کنید.
با این حال، بسیاری از فایلهای .crt و .key از قبل در قالب PEM هستند. اگر این فایلها متنی باشند و در داخل ... قرار گیرند:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
یا:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
سپس فایلها با فرمت PEM سازگار میشوند و میتوانید بدون تبدیل آنها به فایل PEM، از آنها در یک keystore یا truststore استفاده کنید.
درباره زنجیرههای گواهی
اگر یک گواهی بخشی از یک زنجیره باشد، بسته به اینکه گواهی در یک فروشگاه کلید یا در یک فروشگاه اعتماد استفاده میشود، شما آن را به طور متفاوتی مدیریت میکنید:
- ذخیره کلید - اگر یک گواهی بخشی از یک زنجیره باشد، باید یک فایل واحد شامل تمام گواهیهای موجود در زنجیره ایجاد کنید. گواهیها باید به ترتیب باشند و آخرین گواهی باید یک گواهی ریشه یا یک گواهی میانی باشد که توسط یک گواهی ریشه امضا شده است.
- فروشگاه اعتماد - اگر یک گواهی بخشی از یک زنجیره باشد، باید یا یک فایل واحد شامل تمام گواهیها ایجاد کنید و آن فایل را در یک نام مستعار آپلود کنید، یا تمام گواهیهای موجود در زنجیره را جداگانه با استفاده از یک نام مستعار متفاوت برای هر گواهی در فروشگاه اعتماد آپلود کنید. اگر آنها را به عنوان یک گواهی واحد آپلود کنید، گواهیها باید به ترتیب باشند و آخرین گواهی باید یک گواهی ریشه یا یک گواهی میانی باشد که توسط یک گواهی ریشه امضا شده است.
- اگر یک فایل واحد ایجاد میکنید که حاوی چندین گواهی است، باید بین هر گواهی یک خط خالی قرار دهید.
برای مثال، میتوانید تمام گواهیها را در یک فایل PEM ترکیب کنید. گواهیها باید به ترتیب باشند و آخرین گواهی باید یک گواهی ریشه یا یک گواهی میانی باشد که توسط یک گواهی ریشه امضا شده است:
-----BEGIN CERTIFICATE----- (Your Primary TLS certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root certificate or intermediate certificate signed by a root certificate) -----END CERTIFICATE-----
اگر گواهینامههای شما به صورت فایلهای PKCS12/PFX نمایش داده میشوند، میتوانید از دستور openssl برای ایجاد یک فایل PKCS12/PFX از زنجیرهای از گواهینامهها، مطابق شکل زیر، استفاده کنید:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
هنگام کار با زنجیرههای گواهی در یک فروشگاه اعتماد، همیشه لازم نیست همه گواهیهای موجود در زنجیره را آپلود کنید. برای مثال، شما یک گواهی مشتری، client_cert_1 ، و گواهی صادرکننده گواهی مشتری، ca_cert آپلود میکنید.
در طول احراز هویت دوطرفه TLS، احراز هویت کلاینت زمانی با موفقیت انجام میشود که سرور client_cert_1 به عنوان بخشی از فرآیند TLS handshaking برای کلاینت ارسال کند.
روش دیگر این است که شما یک گواهی دوم، client_cert_2 ، دارید که توسط همان گواهی، ca_cert امضا شده است. با این حال، شما client_cert_2 در truststore آپلود نمیکنید. truststore هنوز فقط شامل client_cert_1 و ca_cert است.
وقتی سرور client_cert_2 به عنوان بخشی از فرآیند TLS handshaking ارسال میکند، درخواست با موفقیت انجام میشود. دلیل این امر آن است که Edge اجازه میدهد تأیید TLS زمانی که client_cert_2 در truststore وجود ندارد اما توسط گواهی موجود در truststore امضا شده است، با موفقیت انجام شود. اگر گواهی CA، ca_cert ، را از truststore حذف کنید، تأیید TLS با شکست مواجه میشود.
ملاحظات FIPS
اگر از Edge for Private Cloud نسخه ۴.۵۳.۰۰ یا بالاتر در سیستم عاملی با قابلیت FIPS استفاده میکنید، باید فقط از یک keystore PKCS12 برای آپلود کلیدها و گواهینامههای مرتبط در Apigee استفاده کنید.
صفحه TLS Keystores را بررسی کنید
طبق توضیحات زیر، به صفحه TLS Keystores دسترسی پیدا کنید.لبه
برای دسترسی به صفحه TLS Keystores با استفاده از رابط کاربری Edge:
- به عنوان مدیر سازمان وارد https://apigee.com/edge شوید.
- سازمان خود را انتخاب کنید.
- Admin > Environment > TLS Keystores را انتخاب کنید.
لبه کلاسیک (ابر خصوصی)
برای دسترسی به صفحه TLS Keystores با استفاده از رابط کاربری کلاسیک اج:
- به عنوان مدیر سازمان وارد آدرس
http:// ms-ip :9000شوید، که در آن ms-ip آدرس IP یا نام DNS گره سرور مدیریت است. - سازمان خود را انتخاب کنید.
- Admin > Environment Configuration > TLS Keystores را انتخاب کنید.
صفحه TLS Keystores نمایش داده میشود:
همانطور که در شکل قبلی مشخص شده است، صفحه TLS Keystores شما را قادر میسازد تا:
- یک محیط انتخاب کنید
- ایجاد یک keystore و نام مستعار
- تست و حذف فروشگاههای کلید
- مشاهده و حذف نامهای مستعار
مشاهده نام مستعار
برای مشاهده نام مستعار:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- محیط (معمولاً
prodیاtest) را انتخاب کنید. - روی ردیف مرتبط با نام مستعاری که میخواهید مشاهده کنید، کلیک کنید.
جزئیات مربوط به گواهی و کلید مستعار نمایش داده میشود.

شما میتوانید تمام اطلاعات مربوط به نام مستعار، از جمله تاریخ انقضا را مشاهده کنید. - با استفاده از دکمههای بالای صفحه، گواهی را مدیریت کنید تا:
- گواهی را به صورت فایل PEM دانلود کنید.
- ایجاد CSR. اگر گواهینامه شما منقضی شده است و میخواهید آن را تمدید کنید، میتوانید درخواست امضای گواهینامه (CSR) را دانلود کنید. سپس CSR را برای دریافت گواهینامه جدید به CA خود ارسال میکنید.
- بهروزرسانی گواهی. احتیاط : اگر گواهیای را بهروزرسانی میکنید که در حال حاضر توسط یک میزبان مجازی یا سرور/نقطه پایانی هدف استفاده میشود، باید برای راهاندازی مجدد روترها و پردازندههای پیام با پشتیبانی Apigee Edge تماس بگیرید. روش توصیهشده برای بهروزرسانی گواهی این است که:
- یک keystore یا truststore جدید ایجاد کنید.
- گواهی جدید را به keystore یا truststore جدید اضافه کنید.
- مرجع را در میزبان مجازی یا سرور/نقطه انتهایی هدف به فروشگاه کلید یا فروشگاه اعتماد بهروزرسانی کنید. برای اطلاعات بیشتر به بهروزرسانی گواهی TLS برای ابر مراجعه کنید.
- نام مستعار را حذف کنید. توجه : اگر یک نام مستعار را حذف کنید، و در حال حاضر توسط یک میزبان مجازی یا نقطه پایانی هدف در حال استفاده است، میزبان مجازی یا نقطه پایانی هدف از کار خواهد افتاد.
یک keystore/truststore و نام مستعار ایجاد کنید
شما میتوانید یک keystore برای استفاده به عنوان یک keystore TLS یا یک truststore TLS ایجاد کنید. یک keystore مختص یک محیط در سازمان شما است، به عنوان مثال محیط تست یا تولید. بنابراین، اگر میخواهید keystore را قبل از استقرار در محیط تولید خود، در یک محیط تست آزمایش کنید، باید آن را در هر دو محیط ایجاد کنید.
برای ایجاد یک keystore در یک محیط، فقط باید نام keystore را مشخص کنید. پس از ایجاد یک keystore با نام در یک محیط، میتوانید نامهای مستعار ایجاد کرده و یک جفت گواهی/کلید (keystore) آپلود کنید یا فقط یک گواهی (truststore) را در نامهای مستعار آپلود کنید.
برای ایجاد یک فروشگاه کلید:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- محیط (معمولاً
prodیاtest) را انتخاب کنید. - روی + فروشگاه کلید کلیک کنید.
- نام keystore را مشخص کنید. این نام فقط میتواند شامل کاراکترهای حرفی-عددی باشد.
- روی افزودن کلید اصلی (Add Keystore) کلیک کنید. کلید اصلی جدید در لیست ظاهر میشود.
- برای افزودن نام مستعار از یکی از رویههای زیر استفاده کنید. همچنین به بخش قالبهای فایل گواهی پشتیبانیشده مراجعه کنید.
ایجاد نام مستعار از یک گواهی (فقط فروشگاه اعتماد)
برای ایجاد یک نام مستعار از یک گواهی:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- مکاننما را روی کلید اصلی قرار دهید تا منوی عملیات نمایش داده شود و روی + کلیک کنید.
- نام مستعار (Alias Name) را مشخص کنید.
- در قسمت جزئیات گواهی (Certificate details)، از منوی کشویی نوع (Type)، گزینه فقط گواهی (Certificate Only) را انتخاب کنید.
- روی «انتخاب فایل» در کنار «فایل گواهی» کلیک کنید، به فایل PEM حاوی گواهی بروید و روی «باز کردن» کلیک کنید.
- به طور پیشفرض، API بررسی میکند که آیا گواهی منقضی نشده است یا خیر. در صورت تمایل، برای رد شدن از مرحله اعتبارسنجی، گزینه «اجازه دهید گواهی منقضی شود» را انتخاب کنید.
- برای آپلود گواهی و ایجاد نام مستعار، ذخیره را انتخاب کنید.
ایجاد نام مستعار از یک فایل JAR (فقط keystore)
برای ایجاد نام مستعار از یک فایل JAR:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- مکاننما را روی کلید اصلی قرار دهید تا منوی عملیات نمایش داده شود و روی + کلیک کنید.
- نام مستعار (Alias Name) را مشخص کنید.
- در قسمت جزئیات گواهی، از منوی کشویی نوع، فایل JAR را انتخاب کنید.
- روی «انتخاب فایل» در کنار JAR File کلیک کنید، به فایل JAR حاوی گواهی و کلید بروید و روی «باز کردن» کلیک کنید.
- اگر کلید رمز عبور دارد، رمز عبور را مشخص کنید. اگر کلید رمز عبور ندارد، این فیلد را خالی بگذارید.
- به طور پیشفرض، API بررسی میکند که آیا گواهی منقضی نشده است یا خیر. در صورت تمایل، برای رد شدن از مرحله اعتبارسنجی، گزینه «اجازه دهید گواهی منقضی شود» را انتخاب کنید.
- برای آپلود کلید و گواهی و ایجاد نام مستعار، ذخیره را انتخاب کنید.
ایجاد یک نام مستعار از یک گواهی و کلید (فقط فروشگاه کلید)
برای ایجاد یک نام مستعار از یک گواهی و کلید:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- مکاننما را روی کلید اصلی قرار دهید تا منوی عملیات نمایش داده شود و روی + کلیک کنید.
- نام مستعار (Alias Name) را مشخص کنید.
- در قسمت جزئیات گواهی، از منوی کشویی نوع، گواهی و کلید را انتخاب کنید.
- روی «انتخاب فایل» در کنار «فایل گواهی» کلیک کنید، به فایل PEM حاوی گواهی بروید و روی «باز کردن» کلیک کنید.
- اگر کلید رمز عبور دارد، رمز عبور کلید را مشخص کنید. اگر کلید رمز عبور ندارد، این فیلد را خالی بگذارید.
- روی «انتخاب فایل» در کنار «فایل کلید» کلیک کنید، به فایل PEM حاوی کلید بروید و روی «باز کردن» کلیک کنید.
- به طور پیشفرض، API بررسی میکند که آیا گواهی منقضی نشده است یا خیر. در صورت تمایل، برای رد شدن از مرحله اعتبارسنجی، گزینه «اجازه دهید گواهی منقضی شود» را انتخاب کنید.
- برای آپلود کلید و گواهی و ایجاد نام مستعار، ذخیره را انتخاب کنید.
ایجاد یک نام مستعار از فایل PKCS12/PFX (فقط keystore)
برای ایجاد یک نام مستعار از یک فایل PKCS12 حاوی گواهی و کلید:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- مکاننما را روی کلید اصلی قرار دهید تا منوی عملیات نمایش داده شود و روی + کلیک کنید.
- نام مستعار (Alias Name) را مشخص کنید.
- در قسمت جزئیات گواهی (Certificate details)، از منوی کشویی نوع (Type)، گزینه PKCS12/PFX را انتخاب کنید.
- روی «انتخاب فایل» در کنار PKCS12/PFX کلیک کنید، به فایل حاوی کلید و گواهی بروید و روی «باز کردن» کلیک کنید.
- اگر کلید رمز عبور دارد، رمز عبور فایل PKCS12/PFX را وارد کنید. اگر کلید رمز عبور ندارد، این فیلد را خالی بگذارید.
- به طور پیشفرض، API بررسی میکند که آیا گواهی منقضی نشده است یا خیر. در صورت تمایل، برای رد شدن از مرحله اعتبارسنجی، گزینه «اجازه دهید گواهی منقضی شود» را انتخاب کنید.
- برای آپلود فایل و ایجاد نام مستعار، گزینه ذخیره را انتخاب کنید.
ایجاد یک نام مستعار از یک گواهی خودامضا (فقط keystore)
برای ایجاد یک نام مستعار که از یک گواهی خودامضا استفاده میکند، فرمی را با اطلاعات لازم برای ایجاد گواهی پر میکنید. سپس Edge گواهی و یک جفت کلید خصوصی را ایجاد کرده و آنها را در نام مستعار بارگذاری میکند.
برای ایجاد یک نام مستعار از یک گواهی خودامضا:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- مکاننما را روی کلید اصلی قرار دهید تا منوی عملیات نمایش داده شود و روی + کلیک کنید.
- نام مستعار (Alias Name) را مشخص کنید.
- در قسمت جزئیات گواهی، از منوی کشویی نوع، گواهی خودامضا (Self-Signed Certificate) را انتخاب کنید.
- با استفاده از جدول زیر فرم را پر کنید.
- برای ایجاد جفت کلید گواهی و خصوصی و آپلود آنها در نام مستعار، ذخیره را انتخاب کنید.
در گواهی تولید شده، فیلدهای اضافی زیر را مشاهده خواهید کرد:
- صادرکننده
نهادی که گواهی را امضا و صادر کرده است. برای گواهی خودامضا، این همان CN است که هنگام ایجاد گواهی مشخص کردهاید. - اعتبار
دوره اعتبار گواهی به صورت دو تاریخ نمایش داده میشود: تاریخی که دوره اعتبار گواهی از آن شروع میشود و تاریخی که دوره اعتبار گواهی پایان مییابد. هر دو میتوانند به صورت مقادیر UTCTime یا GeneralizedTime کدگذاری شوند.
جدول زیر فیلدهای فرم را شرح میدهد:
| فیلد فرم | توضیحات | پیشفرض | مورد نیاز |
|---|---|---|---|
| نام مستعار | نام مستعار. حداکثر طول ۱۲۸ کاراکتر است. | ناموجود | بله |
| اندازه کلید | اندازه کلید، بر حسب بیت. مقدار پیشفرض و حداکثری آن ۲۰۴۸ بیت است. | ۲۰۴۸ | خیر |
| الگوریتم امضا | الگوریتم امضا برای تولید کلید خصوصی. مقادیر معتبر عبارتند از "SHA512withRSA"، "SHA384withRSA" و "SHA256withRSA" (پیشفرض). | SHA256 با RSA | خیر |
| اعتبار گواهی به روز | مدت اعتبار گواهی، بر حسب روز. مقدار مثبت غیر صفر را میپذیرد. | ۳۶۵ | خیر |
| نام مشترک | نام مشترک (CN) سازمان، نام دامنه (های) کاملاً واجد شرایط مرتبط با گواهی را مشخص میکند. این نام معمولاً از یک میزبان و یک نام دامنه تشکیل شده است. به عنوان مثال، api.enterprise.apigee.com، www.apigee.com و غیره. حداکثر طول ۶۴ کاراکتر است. بسته به نوع گواهی ، CN میتواند یک یا چند نام میزبان متعلق به یک دامنه (مثلاً example.com، www.example.com)، یک نام wildcard (مثلاً *.example.com) یا لیستی از دامنهها باشد. هیچ پروتکلی (http:// یا https://)، شماره پورت یا مسیر منبع را وارد نکنید. این گواهی تنها در صورتی معتبر است که نام میزبان درخواست حداقل با یکی از نامهای رایج گواهی مطابقت داشته باشد. | ناموجود | بله |
| ایمیل | آدرس ایمیل. حداکثر طول ۲۵۵ کاراکتر است. | ناموجود | خیر |
| نام واحد سازمانی | نام تیم سازمان. حداکثر طول ۶۴ کاراکتر است. | ناموجود | خیر |
| نام سازمان | نام سازمان. حداکثر طول ۶۴ کاراکتر است. | ناموجود | خیر |
| محل | نام شهر/شهرستان. حداکثر طول ۱۲۸ کاراکتر است. | ناموجود | خیر |
| ایالت/استان | نام ایالت/استان. حداکثر طول ۱۲۸ کاراکتر است. | ناموجود | خیر |
| کشور | کد کشور دو حرفی. مثال، IN برای هند، US برای ایالات متحده آمریکا. | ناموجود | خیر |
| نامهای جایگزین | فهرست نامهای میزبان جایگزین. امکان اتصال هویتهای اضافی به موضوع گواهی را فراهم میکند. گزینههای تعریفشده شامل یک آدرس ایمیل اینترنتی، یک نام DNS، یک آدرس IP و یک شناسه منبع یکپارچه (URI) است. حداکثر ۲۵۵ کاراکتر برای هر مقدار. میتوانید نامها را با کاما یا با فشار دادن کلید Enter بعد از هر نام از هم جدا کنید. | ناموجود | خیر |
یک فروشگاه کلید یا فروشگاه اعتماد را آزمایش کنید
شما میتوانید truststore و keystore خود را در رابط کاربری Edge آزمایش کنید تا مطمئن شوید که به درستی پیکربندی شدهاند. رابط کاربری آزمایشی، درخواست TLS از Edge به یک سرویس backend را تأیید میکند. سرویس backend را میتوان طوری پیکربندی کرد که از TLS یک طرفه یا دو طرفه پشتیبانی کند.
برای آزمایش TLS یک طرفه:
- به صفحه TLS Keystores دسترسی پیدا کنید .
- محیط (معمولاً
prodیاtest) را انتخاب کنید. - مکاننمای خود را روی کلید TLS مورد نظر برای آزمایش قرار دهید تا منوی اقدامات نمایش داده شود و روی تست کلیک کنید. کادر محاورهای زیر ظاهر میشود که نام فروشگاه اعتماد را نشان میدهد:

- نام میزبان سرویس backend را وارد کنید.
- شماره پورت TLS (معمولاً ۴۴۳) را وارد کنید.
- به صورت اختیاری هر پروتکل یا رمزی را مشخص کنید.
- آزمون را انتخاب کنید.
برای آزمایش TLS دوطرفه:
- برای فروشگاه مورد نظر، دکمه تست را انتخاب کنید.
- در کادر محاورهای، برای نوع تست SSL ، گزینهی Two Way (دو طرفه) را انتخاب کنید. کادر محاورهای زیر ظاهر میشود:

- نام مخزن کلید مورد استفاده در TLS دوطرفه را مشخص کنید.
- نام مستعار را در keystore حاوی گواهی و کلید مشخص کنید.
- نام میزبان سرویس backend را وارد کنید.
- شماره پورت TLS (معمولاً ۴۴۳) را وارد کنید.
- به صورت اختیاری هر پروتکل یا رمزی را مشخص کنید.
- آزمون را انتخاب کنید.
برای TLS دو طرفه، یک گواهی به یک فروشگاه اعتماد اضافه کنید
هنگام استفاده از TLS دوطرفه برای اتصالات ورودی ، به معنای درخواست API به Edge، فروشگاه اعتماد شامل یک زنجیره گواهی یا CA برای هر کلاینت مجاز به ارسال درخواست به Edge است.
وقتی در ابتدا truststore را پیکربندی میکنید، میتوانید تمام گواهینامههای مربوط به کلاینتهای شناختهشده را اضافه کنید. با این حال، با گذشت زمان، ممکن است بخواهید با اضافه کردن کلاینتهای جدید، گواهینامههای اضافی را به truststore اضافه کنید.
برای افزودن گواهیهای جدید به یک فروشگاه اعتماد که برای TLS دوطرفه استفاده میشود:
- مطمئن شوید که از ارجاع به truststore در میزبان مجازی استفاده میکنید.
- همانطور که در بالا در بخش «ایجاد نام مستعار از یک گواهی (فقط فروشگاه اعتماد)» توضیح داده شد، یک گواهی جدید در فروشگاه اعتماد آپلود کنید.
مرجع truststore را بهروزرسانی کنید تا روی همان مقدار تنظیم شود. این بهروزرسانی باعث میشود Edge، truststore و گواهی جدید را مجدداً بارگذاری کند.
برای اطلاعات بیشتر به بخش اصلاح مرجع مراجعه کنید.
حذف یک keystore/truststore یا نام مستعار
هنگام حذف یک keystore/truststore یا نام مستعار باید احتیاط کنید. اگر یک keystore، truststore یا نام مستعار را که توسط یک میزبان مجازی، نقطه پایانی هدف یا سرور هدف استفاده میشود حذف کنید، تمام فراخوانیهای API از طریق میزبان مجازی یا نقطه پایانی هدف/سرور هدف با شکست مواجه میشوند.
معمولاً فرآیندی که برای حذف یک keystore/truststore یا نام مستعار استفاده میکنید به شرح زیر است:
- همانطور که در بالا توضیح داده شد، یک keystore/truststore یا نام مستعار جدید ایجاد کنید.
- برای اتصالات ورودی ، یعنی درخواست API به Edge، پیکربندی میزبان مجازی را بهروزرسانی کنید تا به کلید اصلی و نام مستعار کلید جدید ارجاع داده شود.
- برای اتصالات خروجی ، یعنی از Apigee به یک سرور backend:
- پیکربندی TargetEndpoint را برای هر پروکسی API که به کلید اصلی و نام مستعار کلید قدیمی ارجاع داده است، بهروزرسانی کنید تا به کلید اصلی و نام مستعار کلید جدید ارجاع داده شود. اگر TargetEndpoint شما به یک TargetServer ارجاع میدهد، تعریف TargetServer را بهروزرسانی کنید تا به کلید اصلی و نام مستعار کلید جدید ارجاع دهد.
- اگر keystore و truststore مستقیماً از تعریف TargetEndpoint ارجاع داده شوند، باید پروکسی را مجدداً مستقر کنید. اگر TargetEndpoint به تعریف TargetServer ارجاع دهد و تعریف TargetServer به keystore و truststore ارجاع دهد، نیازی به استقرار مجدد پروکسی نیست.
- تأیید کنید که پروکسیهای API شما به درستی کار میکنند.
- keystore/truststore یا نام مستعار را حذف کنید.
حذف یک فروشگاه کلید
شما میتوانید با قرار دادن مکاننما روی کلید یا تراستِور در لیست، منوی اقدامات را نمایش داده و کلیک کنید تا یک کلید یا تراستِور حذف شود.
اگر یک keystore یا truststore را که توسط یک میزبان مجازی یا نقطه پایانی/سرور هدف استفاده میشود، حذف کنید، تمام فراخوانیهای API از طریق میزبان مجازی یا نقطه پایانی/سرور هدف با شکست مواجه میشوند.
احتیاط : تا زمانی که میزبانهای مجازی و نقاط انتهایی/سرورهای هدف خود را برای استفاده از یک فروشگاه کلید جدید تغییر ندادهاید، نباید یک فروشگاه کلید را حذف کنید.
حذف نام مستعار
شما میتوانید با قرار دادن مکاننما روی نام مستعار در لیست و کلیک کردن روی آن، آن را حذف کنید.
اگر یک نام مستعار را که توسط یک میزبان مجازی یا نقطه پایانی/سرور هدف استفاده میشود، حذف کنید، تمام فراخوانیهای API از طریق میزبان مجازی یا نقطه پایانی/سرور هدف با شکست مواجه میشوند.
احتیاط : تا زمانی که میزبانهای مجازی و نقاط انتهایی/سرورهای هدف خود را برای استفاده از یک کلید اصلی و نام مستعار جدید تبدیل نکردهاید، نباید یک نام مستعار را حذف کنید.