برای نسخه 4.17.09 Private Cloud و پیش از آن، کلیدها و ذخیره‌های اعتماد ایجاد کنید.

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید .
اطلاعات

این سند نحوه ایجاد، تغییر و حذف کلیدهای ذخیره‌سازی و ذخیره‌سازی اعتماد برای Edge برای Private Cloud نسخه 4.17.09 و نسخه‌های قبلی را شرح می‌دهد.

درباره فروشگاه‌های کلید و Truststores

فروشگاه‌های کلید و Truststores مخازن گواهی‌های امنیتی مورد استفاده برای رمزگذاری TLS را تعریف می‌کنند. تفاوت اصلی بین این دو در جایی است که در فرآیند دست دادن TLS استفاده می شود:

  • یک فروشگاه کلید حاوی یک گواهی TLS و کلید خصوصی است که برای شناسایی موجودیت در هنگام دست دادن TLS استفاده می شود.

    در TLS یک طرفه، هنگامی که یک کلاینت به نقطه پایانی TLS در سرور متصل می شود، فروشگاه کلید سرور گواهی سرور (گواهی عمومی) را به مشتری ارائه می دهد. سپس مشتری آن گواهی را با یک مرجع صدور گواهی (CA)، مانند Symantec یا VeriSign تأیید می کند.

    در TLS دو طرفه، هم مشتری و هم سرور یک فروشگاه کلید با گواهی و کلید خصوصی خود که برای احراز هویت متقابل استفاده می‌شود، نگهداری می‌کنند.
  • یک Truststore حاوی گواهی هایی است که برای تأیید گواهی های دریافت شده به عنوان بخشی از دست دادن TLS استفاده می شود.

    در TLS یک طرفه، اگر گواهی توسط یک CA معتبر امضا شده باشد، به یک Truststore نیازی نیست. اگر گواهی دریافت شده توسط یک سرویس گیرنده TLS توسط یک CA معتبر امضا شده باشد، آنگاه مشتری درخواستی را برای تأیید اعتبار گواهی از CA ارائه می کند. یک کلاینت TLS معمولاً از یک Truststore برای تأیید اعتبار گواهینامه های خودامضا دریافت شده از سرور TLS یا گواهی هایی که توسط یک CA مطمئن امضا نشده اند استفاده می کند. در این سناریو، مشتری فروشگاه اعتماد خود را با گواهی هایی که به آنها اعتماد دارد پر می کند. سپس، هنگامی که مشتری یک گواهی سرور دریافت می‌کند، گواهی دریافتی در برابر گواهی‌های موجود در فروشگاه اعتماد آن تأیید می‌شود.

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

    برای TLS دو طرفه، هم کلاینت TLS و هم سرور TLS می توانند از Truststore استفاده کنند. هنگامی که Edge به عنوان سرور TLS عمل می کند، هنگام اجرای TLS دو طرفه، یک Truststore لازم است.

گواهی ها را می توان توسط یک مرجع صدور گواهی (CA) صادر کرد، یا می تواند توسط کلید خصوصی که تولید می کنید، خود امضا شود. اگر به یک CA دسترسی دارید، دستورالعمل های ارائه شده توسط CA خود را برای تولید کلید و صدور گواهی ها دنبال کنید. اگر به یک CA دسترسی ندارید، می توانید با استفاده از یکی از بسیاری از ابزارهای رایگان در دسترس عموم، مانند openssl، یک گواهی خودامضا ایجاد کنید.

پیاده سازی keystore و truststore در Edge

در Edge، یک keystore حاوی یک یا چند فایل JAR است که در آن فایل JAR شامل موارد زیر است:

  • گواهی TLS به عنوان یک فایل PEM - یا گواهی امضا شده توسط یک مرجع گواهی (CA)، زنجیره ای از گواهی ها که در آن آخرین گواهی توسط یک CA امضا شده است، یا یک گواهی خودامضا.
  • کلید خصوصی به عنوان فایل PEM. Edge از اندازه های کلید تا 2048 بیت پشتیبانی می کند. عبارت عبور اختیاری است.

Truststore شبیه به Keystore است با این تفاوت که فقط شامل گواهی ها به عنوان فایل PEM است، اما کلید خصوصی ندارد.

اگر گواهی بخشی از یک زنجیره باشد، ذخیره کلید/اعتماد باید همه گواهی‌های موجود در زنجیره را شامل شود، چه به صورت فایل‌های PEM منفرد و چه به صورت یک فایل. اگر از یک فایل استفاده می‌کنید، گواهی‌ها باید به ترتیب باشند، جایی که اولین گواهی در فایل، گواهی استفاده شده برای TLS است و به‌ترتیب زنجیره گواهی‌ها به گواهی CA می‌رسد. شما باید یک خط خالی بین هر گواهی در فایل وارد کنید.

Edge یک API ارائه می دهد که شما از آن برای ایجاد keystore و truststores استفاده می کنید. APIهای واقعی یکسان هستند. تفاوت این است که وقتی یک فروشگاه کلید ایجاد می کنید، یک فایل JAR را ارسال می کنید که حاوی گواهی و کلید خصوصی است. هنگامی که یک Truststore ایجاد می کنید، فقط گواهی را به عنوان یک فایل PEM ارسال می کنید.

درباره فرمت فایل های گواهی و کلید

نمونه‌های موجود در این سند گواهی و کلید TLS را نشان می‌دهند که به عنوان فایل‌های PEM تعریف شده‌اند که با فرمت X.509 مطابقت دارند. اگر گواهی یا کلید خصوصی شما توسط یک فایل PEM تعریف نشده است، می توانید با استفاده از ابزارهایی مانند openssl آن را به یک فایل PEM تبدیل کنید.

با این حال، بسیاری از فایل‌های crt. و فایل‌های کلیدی از قبل در قالب PEM هستند. اگر این فایل ها فایل های متنی هستند و در موارد زیر قرار می گیرند:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

یا:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

سپس فایل‌ها با فرمت PEM سازگار هستند و می‌توانید بدون تبدیل آنها به فایل PEM از آنها در فروشگاه کلید یا Truststore استفاده کنید.

اگر یک زنجیره گواهی دارید و می‌خواهید از آن زنجیره در فروشگاه کلید یا 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-----

جزئیات مربوط به یک فروشگاه کلید موجود را دریافت کنید

با استفاده از List Keystores و Truststores API، محیط خود را برای هر گونه ذخیره کلید موجود بررسی کنید:

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

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

[ "freetrial" ]

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

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

با استفاده از Get a Keystore یا Truststore API محتویات keystore را بررسی کنید. برای یک مشتری ابری، باید یک گواهی TLS سرور واحد را ببینید - گواهی پیش‌فرض که Apigee Edge برای حساب‌های آزمایشی رایگان ارائه می‌کند.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

پاسخ باید به صورت زیر ظاهر شود:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

همچنین می توانید این اطلاعات را در رابط کاربری Edge management مشاهده کنید:

  1. وارد رابط کاربری Edge management در https://enterprise.apigee.com (ابر) یا http://<ms-ip>:9000 (در محل) شوید، جایی که <ms-ip> آدرس IP مدیریت است. گره سرور.
  2. در منوی Edge management UI، Admin > TLS Certificates را انتخاب کنید.

جزئیات گواهی TLS را دریافت کنید

می‌توانید از دریافت جزئیات گواهی از Keystore یا Truststore API برای مشاهده جزئیات مربوط به گواهی‌های TLS در فروشگاه کلید، مانند تاریخ انقضا و صادرکننده استفاده کنید. ابتدا نام گواهی مورد نظر خود را دریافت کنید. این مثال اطلاعاتی را برای فروشگاه کلید به نام "freetrial" واکشی می کند.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

نمونه پاسخ:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

سپس، از مقدار ویژگی certs برای دریافت جزئیات گواهی استفاده کنید:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

نمونه پاسخ:

{
 "certInfo" : [ {
   "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
   "isValid" : "Yes",
   "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O=&quot;GoDaddy.com, Inc.&quot;, L=Scottsdale, ST=Arizona, C=US",
   "subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
   "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
   "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
   "version" : 3
 } ],
 "name" : "example.apigee.net.crt"
}

همچنین می توانید این اطلاعات را در رابط کاربری Edge management مشاهده کنید:

  1. وارد رابط کاربری Edge management در https://enterprise.apigee.com (ابر) یا http://<ms-ip>:9000 (در محل) شوید، جایی که <ms-ip> آدرس IP مدیریت است. گره سرور.
  2. در منوی Edge management UI، Admin > TLS Certificates را انتخاب کنید.

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

یک فروشگاه کلید ایجاد کنید

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

ایجاد یک فروشگاه کلید یک فرآیند دو مرحله ای است:

  1. یک فایل JAR حاوی گواهی و کلید خصوصی خود ایجاد کنید.
  2. فروشگاه کلید را ایجاد کنید و فایل JAR را آپلود کنید.

یک فایل JAR حاوی گواهی و کلید خصوصی خود ایجاد کنید

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

/META-INF/descriptor.properties
myCert.pem
myKey.pem

در دایرکتوری حاوی جفت کلید و گواهی، دایرکتوری به نام /META-INF ایجاد کنید. سپس فایلی به نام descriptor.properties در /META-INF با محتوای زیر ایجاد کنید:

certFile={myCertificate}.pem
keyFile={myKey}.pem

فایل JAR حاوی جفت کلید و گواهی خود را ایجاد کنید:

jar -cf myKeystore.jar myCert.pem myKey.pem

descriptor.properties را به فایل JAR خود اضافه کنید:

jar -uf myKeystore.jar META-INF/descriptor.properties

Keystore را ایجاد کنید و فایل JAR را آپلود کنید

برای ایجاد keystore در یک محیط، فقط باید نام keystore را برای Create a Keystore یا Truststore API مشخص کنید. نام فقط می تواند شامل نویسه های الفبایی باشد:

curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password

نمونه پاسخ:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

پس از ایجاد یک keystore نام‌گذاری شده در یک محیط، می‌توانید فایل‌های JAR خود را که حاوی یک گواهی و کلید خصوصی هستند با استفاده از آپلود یک فایل JAR در یک API Keystore آپلود کنید:

curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password

که در آن گزینه -F مسیر فایل JAR را مشخص می کند.

در این فراخوانی دو پارامتر پرس و جو را مشخص می کنید:

  • alias - گواهی و کلید را در فروشگاه کلید شناسایی می کند. هنگامی که یک میزبان مجازی ایجاد می کنید، گواهی و کلید را با نام مستعار آن ارجاع می دهید.
  • password - رمز عبور برای کلید خصوصی. اگر کلید خصوصی رمز عبور ندارد، این پارامتر را حذف کنید.

بررسی کنید که فروشگاه کلید شما به درستی آپلود شده است:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

نمونه پاسخ:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

یک فروشگاه اعتماد ایجاد کنید

API هایی که برای ایجاد یک Truststore استفاده می کنید، همان API هایی هستند که برای ایجاد یک keystore استفاده می شوند. تنها تفاوت این است که شما فایل گواهی را به جای فایل JAR به عنوان یک فایل PEM ارسال می کنید.

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

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

از طرف دیگر، شما یک گواهی دوم دارید، client_cert_2 ، که توسط همان گواهی امضا شده است، ca_cert . با این حال، شما client_cert_2 را در Truststore آپلود نمی کنید. Truststore همچنان شامل client_cert_1 و ca_cert است.

وقتی سرور client_cert_2 به عنوان بخشی از دست دادن TLS ارسال می کند، درخواست با موفقیت انجام می شود. این به این دلیل است که Edge به تأیید TLS اجازه می دهد زمانی که client_cert_2 در Truststore وجود نداشته باشد اما توسط گواهی موجود در truststore امضا شده باشد. اگر گواهی CA، ca_cert را از فروشگاه اعتماد حذف کنید، تأیید TLS ناموفق است.

یک Truststore خالی در محیط با استفاده از Create a Keystore یا Truststore ایجاد کنید، همان API که برای ایجاد یک keystore استفاده می کنید:

curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

با استفاده از Upload a Certificate to Truststore API گواهی را به عنوان یک فایل PEM در Truststore آپلود کنید:

curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password

که در آن گزینه -F مسیر فایل PEM را مشخص می کند.

یک فروشگاه کلید یا فروشگاه اعتماد را حذف کنید

با استفاده از Delete a Keystore یا Truststore API می‌توانید یک فروشگاه کلید یا Truststore را حذف کنید:

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

نمونه پاسخ:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

اگر یک keystore یا truststore را که توسط میزبان مجازی یا نقطه پایانی/هدف/سرور هدف استفاده می‌شود حذف کنید، همه تماس‌های API از طریق میزبان مجازی یا نقطه پایانی/سرور هدف هدف با شکست مواجه می‌شوند.