سوالات متداول مهاجرت CA ریشه پلتفرم نقشه های گوگل

این سند شامل بخش های زیر است:

برای بررسی دقیق تر، ببینید این در مورد چیست؟ .

اصطلاحات

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

گواهی TLS/SSL
یک گواهی یک کلید رمزنگاری را به یک هویت متصل می کند.
گواهینامه های TLS/SSL برای احراز هویت و ایجاد اتصالات امن به وب سایت ها استفاده می شود. گواهینامه ها توسط نهادهایی موسوم به مقامات صدور گواهی صادر و امضا می شوند.
مرورگرها برای اطلاع از اینکه اطلاعات ارسال شده به سرور مناسب ارسال می شود و در حین انتقال رمزگذاری می شوند، به گواهی های صادر شده توسط مقامات گواهی معتبر متکی هستند.
لایه سوکت ایمن (SSL)
لایه سوکت‌های امن پرکاربردترین پروتکلی بود که برای رمزگذاری ارتباطات اینترنتی استفاده می‌شد. پروتکل SSL دیگر امن تلقی نمی شود و دیگر در سرویس های Google پشتیبانی نمی شود.
امنیت لایه حمل و نقل (TLS)
امنیت لایه حمل و نقل جانشین SSL است.
مرجع صدور گواهی (CA)
یک مرجع صدور گواهی مانند یک دفتر گذرنامه دیجیتال برای دستگاه ها و افراد است. اسناد (گواهینامه) محافظت شده از نظر رمزنگاری را برای تأیید اینکه یک نهاد (مثلاً وب سایت) همان چیزی است که ادعا می کند است صادر می کند.
قبل از صدور گواهی، CA مسئول بررسی این است که نام های موجود در گواهی به شخص یا نهاد درخواست کننده مرتبط باشد.
عبارت Certificate Authority می‌تواند هم به سازمان‌هایی مانند Google Trust Services و هم به سیستم‌هایی اشاره کند که گواهی‌ها را صادر می‌کنند.
زیرساخت کلید عمومی (PKI)
زیرساخت کلید عمومی مجموعه‌ای از فناوری‌ها، خط‌مشی‌ها و رویه‌هایی است که این امکان را برای یک مرجع صدور گواهی می‌دهد تا هویت درخواست‌کننده گواهی را تأیید کند، گواهی تأییدکننده آن تأیید را تولید کند و کاربران اینترنت به گواهی اعتماد کنند.
رمزنگاری کلید عمومی فناوری است که این امکان را فراهم می کند
PKI همچنین در شبکه های داخلی استفاده می شود اما رایج ترین مورد استفاده آن فعال کردن ارتباطات رمزگذاری شده در وب است. مرورگرهای وب به گواهی‌های صادر شده توسط CA که در فروشگاه گواهی‌های ریشه آنها موجود است اعتماد دارند.
رمزنگاری کلید عمومی
رمزنگاری کلید عمومی شکلی از رمزنگاری با استفاده از جفت کلید است. یکی از کلیدها عمومی در نظر گرفته می شود و می تواند به طور گسترده توزیع شود، دیگری خصوصی در نظر گرفته می شود و باید مخفی بماند.
داده های رمزگذاری شده با یک کلید عمومی را می توان با کلید خصوصی مربوطه رمزگشایی کرد و بالعکس.
این امکان مفاهیم امضای دیجیتال و رمزگذاری کلید عمومی را فراهم می کند که بلوک های اصلی پروتکل هایی مانند TLS هستند که در آن دو طرف می توانند یکدیگر را احراز هویت کنند و داده های رمزگذاری شده را بدون تبادل قبلی اطلاعات سری به اشتراک بگذارند.
فروشگاه گواهی های ریشه (یا فروشگاه اعتماد)
یک فروشگاه گواهی‌های ریشه شامل مجموعه‌ای از مقامات گواهی است که توسط یک تامین‌کننده نرم‌افزار کاربردی مورد اعتماد است. اکثر مرورگرهای وب و سیستم عامل ها دارای فروشگاه گواهی ریشه مخصوص به خود هستند.
برای گنجاندن در فروشگاه گواهی‌های ریشه، مرجع صدور گواهی باید الزامات سخت‌گیرانه‌ای را که توسط تامین‌کننده نرم‌افزار کاربردی تعیین شده است، برآورده کند.
معمولاً این موارد شامل انطباق با استانداردهای صنعتی مانند الزامات CA/Browser Forum است.
مرجع صدور گواهینامه ریشه
یک مرجع صدور گواهی ریشه (یا به عبارت صحیح تر، گواهی آن) بالاترین گواهی در زنجیره گواهی است.
گواهینامه های CA ریشه معمولاً خود امضا می شوند. کلیدهای خصوصی مرتبط با آنها در امکانات بسیار امن ذخیره می شوند و در حالت آفلاین نگهداری می شوند تا از آنها در برابر دسترسی غیرمجاز محافظت شود.
مرجع صدور گواهی میانی
یک مرجع صدور گواهی میانی (یا به عبارت صحیح تر، گواهی آن) گواهی است که برای امضای گواهی های دیگر در زنجیره گواهی استفاده می شود.
CAهای میانی عمدتاً برای فعال کردن صدور گواهی آنلاین وجود دارند و در عین حال اجازه می‌دهند گواهی CA ریشه آفلاین بماند.
CAهای متوسط ​​به عنوان CAهای تابعه نیز شناخته می شوند.
مرجع صدور گواهی
یک مرجع صدور گواهی، یا به عبارت صحیح تر، گواهی آن، گواهی است که برای امضای پایین ترین گواهی در زنجیره گواهی استفاده می شود.
این گواهی که دارای پایین ترین سطح است معمولاً گواهی مشترک، گواهی نهاد نهایی یا گواهی برگ نامیده می شود. در این سند از عبارت گواهی سرور نیز استفاده خواهیم کرد.
زنجیره گواهی
گواهی‌ها به صادرکننده خود (به صورت رمزنگاری امضا شده) مرتبط می‌شوند. یک زنجیره گواهی از یک برگ گواهی، تمام گواهی های صادر کننده آن و یک گواهی ریشه تشکیل شده است.
امضای متقاطع
مشتریان تأمین‌کنندگان نرم‌افزار کاربردی باید فروشگاه گواهی‌های ریشه خود را به‌روزرسانی کنند تا گواهی‌های CA جدید را درج کنند تا محصولاتشان به آنها اعتماد کند. مدتی طول می کشد تا محصولات حاوی گواهینامه های جدید CA به طور گسترده مورد استفاده قرار گیرند.
برای افزایش سازگاری با مشتریان قدیمی‌تر، گواهی‌های CA را می‌توان توسط یک CA قدیمی‌تر «امضای متقاطع» کرد. این به طور موثر یک گواهی CA دوم برای همان هویت (نام و جفت کلید) ایجاد می کند.
بسته به CA های موجود در فروشگاه گواهی های ریشه خود، مشتریان زنجیره گواهی متفاوتی را تا ریشه ای که به آن اعتماد دارند ایجاد می کنند.

اطلاعات عمومی

این در مورد چیست؟

خلاصه: اگر دستورالعمل‌های موجود در https://pki.goog/faq/#connecting-to-google را دنبال نکنید، به احتمال زیاد در آینده با قطعی‌های مربوط به گواهی مواجه خواهید شد.

تصویر بزرگ

در سال 2017، گوگل یک پروژه چند ساله را برای صدور و استفاده از گواهینامه های ریشه خود، امضاهای رمزنگاری که اساس امنیت اینترنت TLS است که توسط HTTPS استفاده می شود، آغاز کرد.

پس از مرحله اول، امنیت TLS سرویس‌های پلتفرم Google Maps توسط GS Root R2، یک مرجع معتبر گواهی ریشه (CA) بسیار شناخته شده و قابل اعتماد ارائه شده است، که Google آن را از GMO GlobalSign خریداری کرد تا انتقال به CAهای اصلی Google Trust Services (GTS) خود را تسهیل کند.

عملاً تمام سرویس گیرندگان TLS (مانند مرورگرهای وب، تلفن های هوشمند و سرورهای برنامه) به این گواهی ریشه اعتماد کرده اند و بنابراین توانسته اند در مرحله اول مهاجرت یک اتصال امن به سرورهای پلتفرم Google Maps برقرار کنند.

با این حال، یک CA بنا به طراحی باید گواهینامه هایی صادر نکند که بیش از زمان انقضای گواهینامه خود معتبر هستند. از آنجایی که GS Root R2 در 15 دسامبر 2021 منقضی شد، Google خدمات خود را با استفاده از گواهی صادر شده توسط روت CA GTS Root R1 خود گوگل به یک CA جدید، GTS Root R1 Cross منتقل کرد.

در حالی که اکثریت قریب به اتفاق سیستم‌عامل‌های مدرن و کتابخانه‌های کلاینت TLS از قبل به CAهای ریشه GTS اعتماد دارند، برای اطمینان از انتقال روان برای اکثر سیستم‌های قدیمی، Google یک علامت متقاطع از GMO GlobalSign با استفاده از GlobalSign Root CA - R1 ، یکی از قدیمی‌ترین و قابل اعتمادترین CAهای ریشه موجود، به دست آورده است.

بنابراین، اکثر مشتریان پلتفرم Google Maps مشتریان باید قبلاً یکی از این CAهای ریشه معتبر (یا هر دو) را بشناسند و باید کاملاً تحت تأثیر مرحله دوم مهاجرت قرار نگرفته باشند.

این همچنین در مورد مشتریانی که در مرحله اول انتقال در سال 2018 اقدام کردند، با این تصور که در آن زمان از دستورالعمل‌های ما پیروی کردند، همه گواهی‌ها را از بسته CA ریشه Google مورد اعتماد ما نصب کردند، اعمال می‌شود و باید حداقل هر 6 ماه یک‌بار به‌روزرسانی‌های آن فایل را بررسی کنند و فروشگاه اعتماد خود را به‌روزرسانی کنند.

اگر در اتصال به سرویس‌های پلتفرم Google Maps مشکل دارید، باید سیستم‌های خود را تأیید کنید، در صورتی که موارد زیر صدق کند:

  • خدمات شما پلتفرم‌های غیر استاندارد یا قدیمی را اجرا می‌کنند یا فروشگاه گواهی‌های ریشه خود را حفظ می‌کنید
  • در 2017-2018، در مرحله اول انتقال CA ریشه Google اقدامی انجام نداده‌اید، یا مجموعه کامل گواهی‌ها را از بسته مطمئن Google root CA نصب نکرده‌اید.

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

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

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

خلاصه فنی

همانطور که در 15 مارس 2021 در وبلاگ امنیتی Google ، GS Root R2 اعلام شد، پلتفرم نقشه‌های اصلی CA که از اوایل سال 2018 استفاده می‌شد، در 15 دسامبر 2021 منقضی شد. بنابراین Google به نسخه جدید CA GTS Root R1 Cross منتقل می‌شود.

تقریباً تمام کلاینت‌ها و سیستم‌های مدرن TLS از قبل با گواهینامه GTS Root R1 پیکربندی شده‌اند یا باید آن را از به‌روزرسانی‌های نرم‌افزار معمولی دریافت کنند، و GlobalSign Root CA - R1 حتی باید در سیستم‌های قدیمی‌تر موجود باشد.

با این حال، باید حداقل در صورتی که هر دو مورد زیر اعمال می شود، سیستم خود را تأیید کنید:

  • خدمات شما بر روی پلتفرم‌های غیر استاندارد یا قدیمی اجرا می‌شود یا فروشگاه گواهی‌های ریشه خود را حفظ می‌کنید
  • در 2017-2018، در مرحله اول انتقال CA ریشه Google اقدامی انجام نداده‌اید، یا مجموعه کامل گواهی‌ها را از بسته مطمئن Google root CA نصب نکرده‌اید.

نحوه بررسی اینکه آیا فروشگاه گواهی‌های ریشه من به به‌روزرسانی نیاز دارد یا نه، راهنمایی‌هایی را برای آزمایش اینکه آیا سیستم شما تحت تأثیر قرار می‌گیرد ارائه می‌دهد.

به سؤال مراجعه کنید چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟ برای جزئیات کامل

چگونه می توانم به روزرسانی های این مرحله مهاجرت را دریافت کنم؟

ستاره شماره عمومی 186840968 برای به روز رسانی. این سؤالات متداول همچنین در طول فرآیند مهاجرت، هر زمان که با موضوعاتی مواجه می شویم که ممکن است مورد علاقه عمومی باشد، به روز می شود.

چگونه می توانم اعلان قبلی مهاجرت های آینده را دریافت کنم؟

گواهی‌های ریشه جدید در https://pki.goog/updates/ اعلام می‌شوند و یک فید RSS وجود دارد که می‌توانید برای دریافت اعلان‌های به‌روزرسانی‌ها در آن مشترک شوید. ما فقط ریشه های جدید را اعلام می کنیم. تغییرات زنجیره گواهی که بین ریشه های دارای حق تغییر می کند، اعلام نشده است و ممکن است در هر زمانی اتفاق بیفتد. اگر می‌خواهید از اتصالات قابل اعتماد به Google اطمینان حاصل کنید، نباید به یک ریشه یا واسطه پین ​​کنید و باید به مجموعه کامل روت‌های Google که در https://pki.goog/faq/#connecting-to-google پوشش داده شده است اعتماد کنید.

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

همچنین در اعلان‌های پلتفرم نقشه‌های Google مشترک شوید، زیرا ما مرتباً به‌روزرسانی‌هایی را در تالار گفتمان درباره تغییراتی که احتمالاً بر تعداد بیشتری از مشتریان تأثیر می‌گذارد پست می‌کنیم.

ما از چندین سرویس Google استفاده می کنیم. آیا مهاجرت CA ریشه روی همه آنها تأثیر می گذارد؟

بله، انتقال CA ریشه در همه سرویس‌های Google و APIها اتفاق می‌افتد، اما جدول زمانی ممکن است در هر سرویس متفاوت باشد. با این حال، هنگامی که تأیید کردید که فروشگاه‌های گواهی‌های ریشه که توسط برنامه‌های سرویس گیرنده پلتفرم Google Maps شما استفاده می‌شوند، حاوی همه CA فهرست‌شده در بسته مطمئن Google root CA هستند، سرویس‌های شما نباید تحت تأثیر انتقال مداوم قرار گیرند، و همگام نگه داشتن آنها (حداقل هر 6 ماه یکبار) همچنین از شما در برابر تغییرات CA ریشه آینده محافظت می‌کند.

به سؤالات مراجعه کنید چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟ و کدام نوع از برنامه ها در معرض خطر شکستن هستند؟ برای بینش بیشتر

نحوه تأیید اینکه آیا فروشگاه گواهی‌های ریشه من به به‌روزرسانی نیاز دارد یا خیر، در زیر دستورالعمل‌های کلی برای آزمایش سیستم شما ارائه می‌دهد.

چگونه بررسی کنم که آیا فروشگاه گواهینامه های ریشه من به به روز رسانی نیاز دارد یا خیر

محیط برنامه خود را در برابر همه ریشه‌های موجود در بخش Root CAs در https://pki.goog/repository/ تست کنید.

سیستم شما به طور کلی با تغییرات ریشه CA سازگار خواهد بود اگر:

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

مشتریان احتمالاً تحت تأثیر باید فوراً گواهی‌ها را از بسته Google root CA مورد اعتماد نصب کنند تا از وقفه‌های خدمات بعدی جلوگیری شود.

به سؤال مراجعه کنید چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟ برای جزئیات کامل

آیا ابزاری وجود دارد که بتوانم از آن برای تأیید ذخیره گواهی های ریشه خود استفاده کنم؟

ممکن است دو ابزار خط فرمان curl و openssl در تحقیقات خود مفید بیابید. هر دو در اکثر پلتفرم ها در دسترس هستند و گزینه های گسترده ای را برای آزمایش تنظیمات شما ارائه می دهند.

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

دستورات openssl نشان داده شده در زیر برای نسخه 1.1.1 یا بالاتر هستند. نسخه های قبل از 1.1.1 پشتیبانی نمی شوند. اگر از نسخه قبلی استفاده می کنید، این دستورات را در صورت لزوم برای نسخه خود ارتقا یا تغییر دهید. برای دستورالعمل‌های دریافت openssl ، بخش دریافت OpenSSL را در زیر ببینید.

همچنین ابزارهای مفید دیگری را در بخش از کجا می توانم ابزارهای مورد نیاز خود را تهیه کنم پیدا خواهید کرد؟ زیر

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

در حال تست فروشگاه گواهی های ریشه پیش فرض شما

این مثال برای GTS R1 است، آزمایش باید در برابر همه ریشه های GTS انجام شود.

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

بسته مطمئن Google root CA را تأیید کنید

بسته مطمئن Google root CA را دانلود کنید، سپس این مراحل را دنبال کنید:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \

مهاجرت CA ریشه گوگل در سال 2017 چگونه و چه زمانی ادامه خواهد یافت؟

  1. فاز اول (مهاجرت به GS Root R2)، که در ژانویه 2017 اعلام شد ، در اواخر سال 2017 آغاز شد و در نیمه اول سال 2018 به پایان رسید.
  2. فاز دوم (مهاجرت به GTS Root R1 Cross) در مارس 2021 اعلام شد و در ماه‌های قبل از انقضای GS Root R2 در 15 دسامبر 2021 عرضه شد.

برنامه‌های ریشه‌های جدید خیلی قبل از انقضای گواهینامه آینده اعلام می‌شود، اما انتقال بین ریشه‌های موجود اعلام نخواهد شد.

با همگام نگه داشتن فروشگاه گواهی ریشه خود با لیست سرپرستی شده CA های ریشه در بسته مطمئن Google root CA ، برنامه های خود را در آینده اثبات کنید.

همچنین به این سوال مراجعه کنید چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟ برای پیشینه بیشتر

طرح عمومی عرضه برای هر سرویس Google

  1. عرضه مرحله‌ای در یک مرکز داده واحد شروع می‌شود.
  2. عرضه به تدریج به مراکز داده بیشتری گسترش می یابد تا زمانی که پوشش جهانی وجود داشته باشد.
  3. اگر مشکلات جدی در هر مرحله شناسایی شود، آزمایش‌ها می‌توانند به طور موقت در حین رسیدگی به مشکلات به عقب برگردند.
  4. بر اساس ورودی‌های تکرارهای قبلی، خدمات بیشتر Google در عرضه گنجانده شده است تا زمانی که به تدریج همه سرویس‌های Google به گواهی‌های جدید منتقل شوند.

چه کسی، چه زمانی و کجا تحت تأثیر قرار می گیرد؟

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

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

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

به چه چیزی توجه کنیم

کلاینت هایی که با گواهی ریشه لازم پیکربندی نشده اند، نمی توانند اتصال TLS خود را به پلتفرم نقشه های Google تأیید کنند. در این شرایط، کلاینت‌ها معمولاً هشداری مبنی بر عدم موفقیت اعتبار گواهی صادر می‌کنند.

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

حداقل الزامات یک کلاینت TLS برای برقراری ارتباط با پلتفرم Google Maps چیست؟

گواهی‌های پلتفرم نقشه‌های Google از نام‌های جایگزین موضوع DNS (SAN) استفاده می‌کنند، بنابراین مدیریت گواهی مشتری باید بتواند SAN‌هایی را پشتیبانی کند که ممکن است شامل یک علامت عام به عنوان سمت چپ ترین برچسب در نام باشد، مانند *.googleapis.com .

در حالی که نسخه های قدیمی TLS 1.0 و 1.1 هنوز پشتیبانی می شوند، توصیه می کنیم از آنها استفاده نکنید و در صورت امکان استفاده از TLS 1.3 را توصیه می کنیم.

برای سایر الزامات و توصیه‌ها، به بخش‌ها مراجعه کنید . الزامات توصیه‌شده برای ارتباط مشتری TLS با Google چیست؟ و چرا بسیاری از سرویس‌های Google هنوز اتصالات با استفاده از TLS 1.0 و TLS 1.1 را مجاز می‌کنند؟ در پرسش و پاسخ GTS .

کدام نوع از برنامه ها در خطر شکستن هستند؟

این برنامه از فروشگاه گواهینامه های ریشه سیستم بدون هیچ گونه محدودیتی برای توسعه دهنده استفاده می کند

برنامه های خدمات وب پلتفرم نقشه های گوگل

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

اگر از یک نسخه سیستم عامل قدیمی استفاده می کنید که دیگر به روز رسانی دریافت نمی کند، ممکن است گواهینامه های GTS Root را داشته باشید یا نداشته باشید. با این حال، فروشگاه گواهی ریشه شما به احتمال زیاد حاوی GlobalSign Root CA - R1 است، یکی از قدیمی ترین و قابل اعتمادترین CAهای ریشه که در صورت نیاز برای علامت گذاری متقابل ریشه های GTS استفاده می شود.

برای برنامه‌های تلفن همراه که مستقیماً از دستگاه کاربر نهایی با سرویس‌های وب پلتفرم نقشه‌های Google تماس می‌گیرند، دستورالعمل‌هایی از سؤال آیا برنامه‌های تلفن همراه در خطر شکستن هستند؟ اعمال شود.

برنامه های پلتفرم Google Maps سمت مشتری

برنامه‌های Maps JavaScript API معمولاً به گواهی‌های ریشه مرورگر وب در حال اجرا برنامه متکی هستند. به بخش مراجعه کنید آیا برنامه های جاوا اسکریپت در معرض خطر شکستن هستند؟ برای جزئیات بیشتر

برای برنامه‌های تلفن همراه که از هر یک از Maps SDK برای Android، Maps SDK برای iOS، Places SDK برای Android یا Places SDK برای iOS استفاده می‌کنند، قوانین مشابهی اعمال می‌شود که برای برنامه‌هایی که سرویس‌های وب پلتفرم Google Maps را فراخوانی می‌کنند.

ببینید آیا برنامه های تلفن همراه در معرض خطر شکستن هستند؟ برای جزئیات بیشتر

این برنامه از بسته گواهی خود استفاده می کند یا از ویژگی های امنیتی پیشرفته مانند پین کردن گواهی استفاده می کند

شما باید مطمئن شوید که بسته گواهینامه خود را خودتان به روز کنید. همانطور که در زیر سوال بحث شد چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟ ، توصیه می کنیم تمام گواهینامه ها را از بسته مطمئن Google root CA به فروشگاه گواهینامه های ریشه خود وارد کنید و به طور مرتب فروشگاه گواهی خود را به روز کنید.

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

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

چرا باید فروشگاه گواهینامه های ریشه خود را با بسته مطمئن Google root CA همگام نگه دارم؟

لیست سرپرستی شده از CAهای ریشه در بسته معتبر Google root CA شامل همه CAهایی است که ممکن است در آینده قابل پیش بینی توسط سرویس های Google استفاده شود.

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

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

به سوال مراجعه کنید چگونه می توانم از مهاجرت های آینده اعلان قبلی دریافت کنم؟ برای پیدا کردن نحوه دریافت به‌روزرسانی‌ها در مورد مهاجرت‌های CA ریشه در آینده. همگام نگه داشتن فروشگاه گواهی های ریشه خود با لیست انتخاب شده، از خدمات شما در برابر وقفه های خدمات بعدی، به دلیل تغییرات CA محافظت می کند و خدمات شما را پس از انقضای GTS Root R1 Cross و GlobalSign Root CA - R1 اجرا می کند.

همچنین، به سؤال من در حال ساخت محصولی که به سرویس‌های Google متصل می‌شود، مراجعه کنید. به چه گواهی های CA باید اعتماد کنم؟ در GTS برای توصیه های بیشتر.

چرا نباید گواهینامه CA برگ یا میانی نصب کنم؟

انجام این کار خطر شکستن درخواست شما را در هر زمانی که گواهینامه جدیدی را ثبت کنیم یا CAهای میانی را تغییر دهیم، به همراه خواهد داشت. هر یک از اینها ممکن است در هر زمان و بدون اطلاع قبلی اتفاق بیفتد، و به طور یکسان در مورد گواهی‌های سرور منفرد، مانند گواهی‌هایی که توسط maps.googleapis.com ارائه می‌شوند، و همچنین هر یک از CA میانی ما، مانند GTS Root R1 Cross ، اعمال می‌شود.

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

هر پیاده‌سازی مدرن کتابخانه TLS باید بتواند به طور خودکار چنین زنجیره‌های اعتمادی را تأیید کند، تا زمانی که مرجع گواهی ریشه مورد اعتماد باشد.

آیا برنامه های جاوا اسکریپت در معرض خطر شکستن هستند؟

گواهی‌های ریشه GTS در حال حاضر توسط اکثر مرورگرهای مدرن به خوبی تعبیه شده و مورد اعتماد هستند، و علامت متقاطع از GlobalSign باید مهاجرت روان را حتی برای اکثر کاربران نهایی در مرورگرهای قدیمی تضمین کند. این شامل همه مرورگرهای رسمی پشتیبانی شده برای Maps JavaScript API می شود.

هر مرورگر مدرن باید به کاربران نهایی اجازه دهد تا تأیید کنند و معمولاً ویرایش کنند که مرورگر به کدام گواهینامه اعتماد دارد. اگرچه مکان دقیق در هر مرورگر متفاوت است، لیست گواهی‌ها معمولاً در جایی زیر تنظیمات یافت می‌شود.

آیا اپلیکیشن های موبایل در خطر شکستن هستند؟

دستگاه‌های Android و Apple iOS که هنوز به‌روزرسانی‌های منظم را از سازنده دستگاه دریافت می‌کنند نیز انتظار می‌رود در آینده اثبات شوند. اکثر مدل‌های قدیمی‌تر تلفن اندرویدی حداقل دارای گواهینامه GlobalSign Root CA - R1 هستند، اگرچه فهرست گواهی‌های قابل اعتماد ممکن است بر اساس سازنده گوشی، مدل دستگاه و نسخه اندروید متفاوت باشد.

با این حال، پشتیبانی از CA های ریشه GTS، از جمله GTS Root R1 ممکن است همچنان در نسخه های اندروید قبل از 10 محدود باشد.

برای دستگاه‌های iOS، اپل فهرستی از CAهای ریشه قابل اعتماد را برای هر نسخه iOS اخیر در صفحات پشتیبانی خود نگه می‌دارد. با این حال، همه نسخه‌های iOS 5 و بالاتر از GlobalSign Root CA - R1 پشتیبانی می‌کنند.

CAهای ریشه GTS، از جمله GTS Root R1 از نسخه iOS 12.1.3 پشتیبانی می‌شوند.

به سوال مراجعه کنید چگونه می توانم گواهی های ریشه قابل اعتماد تلفن همراه خود را بررسی کنم؟ برای جزئیات بیشتر

چه زمانی مرورگر یا سیستم عامل من شامل گواهینامه های اصلی Google Trust Services می شود؟

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

بنابراین بسیار محتمل است که هر سیستمی که به طور فعال نگهداری می شود قبلاً از Root CAهای GTS پشتیبانی می کند و حتی سیستم های قدیمی نیز به احتمال زیاد از GlobalSign Root CA - R1 پشتیبانی می کنند که برای امضای متقابل بسیاری از گواهینامه های صادر شده توسط Google در سال های آینده استفاده می شود.

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

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

عیب یابی

از کجا می توانم ابزار مورد نیاز خود را تهیه کنم؟

گرفتن فر

اگر توزیع سیستم عامل شما curl ارائه نمی کند، می توانید آن را از https://curl.haxx.se/ دانلود کنید. می‌توانید منبع را دانلود کنید و خودتان ابزار را کامپایل کنید یا یک باینری از پیش کامپایل‌شده را دانلود کنید، اگر یکی برای پلتفرم شما موجود است.

دریافت OpenSSL

اگر توزیع سیستم عامل شما openssl ارائه نمی دهد، می توانید منبع را از https://www.openssl.org/ دانلود کرده و ابزار را کامپایل کنید. با استفاده از https://www.openssl.org/community/binaries.html می‌توانید فهرستی از باینری‌های ساخته شده توسط اشخاص ثالث را پیدا کنید. با این حال، هیچ یک از این بیلدها توسط تیم OpenSSL پشتیبانی نمی‌شوند یا به روش خاصی تأیید نشده‌اند.

دریافت Wireshark، Tshark یا Tcpdump

در حالی که اکثر توزیع‌های لینوکس wireshark ارائه می‌کنند، ابزار خط فرمان آن tshark و tcpdump ، نسخه‌های از پیش کامپایل‌شده دو نسخه اول برای سایر سیستم‌عامل‌ها را می‌توانید در https://www.wireshark.org پیدا کنید.

کد منبع Tcpdump و LibPCAP را می توان در https://www.tcpdump.org یافت.

اسناد مربوط به این ابزارهای مفید را می توان به ترتیب در راهنمای کاربر Wireshark ، در صفحه مرد Tshark و در صفحه مرد Tcpdump یافت.

دریافت ابزار کلید جاوا

ابزار خط فرمان keytool باید همراه با هر کیت توسعه جاوا (JDK) یا Java Runtime Environment (JRE) ارسال شود. اینها را نصب کنید تا keytool. با این حال، استفاده از keytool برای تأیید گواهی ریشه بعید است، مگر اینکه برنامه شما با استفاده از جاوا ساخته شده باشد.

در قطع تولید چه باید کرد

اولین اقدام برای شما این است که گواهی‌های ریشه مورد نیاز را از بسته مطمئن Google root CA در محل ذخیره گواهی‌های ریشه که برنامه شما استفاده می‌کند، نصب کنید.

  1. برای ارتقای فروشگاه گواهینامه ریشه محلی خود با مدیران سیستم خود همکاری کنید.
  2. این سؤالات متداول را برای نشانگرهای قابل اجرا در سیستم خود بررسی کنید.
  3. اگر به کمک بیشتر برای پلتفرم یا سیستم نیاز دارید، با کانال های پشتیبانی فنی ارائه شده توسط ارائه دهنده سیستم خود تماس بگیرید.
  4. برای راهنمایی کلی، همانطور که در بخش تماس با پشتیبانی پلتفرم Google Maps توضیح داده شده است، با تیم پشتیبانی ما تماس بگیرید. توجه: برای مسائل خاص پلت فرم، راهنمایی فقط بر اساس بهترین تلاش ارائه می شود.
  5. ستاره شماره 186840968 عمومی برای به‌روزرسانی‌های مربوط به مهاجرت.

    تماس با پشتیبانی پلتفرم Google Maps

عیب یابی اولیه

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

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

اگر مشکل حل نشد و تصمیم گرفتید با پشتیبانی پلتفرم Google Maps تماس بگیرید، آماده باشید اطلاعات زیر را نیز ارائه دهید:

  1. سرورهای آسیب دیده شما در کجا قرار دارند؟
  2. سرویس شما با کدام آدرس های IP Google تماس می گیرد؟
  3. کدام API(های) تحت تأثیر این مشکل قرار می گیرند؟
  4. موضوع دقیقا از کی شروع شد؟
  5. خروجی دستورات زیر:

    curl -vvI https://maps.googleapis.com; \
    openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr1.demosite.pki.goog/; \
    openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
    openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;
    curl -vvI https://good.gtsr2.demosite.pki.goog/; \
    openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr3.demosite.pki.goog/; \
    openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
    curl -vvI https://good.gtsr4.demosite.pki.goog/; \
    openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

برای دستورالعمل های مربوط به دریافت ابزارهای مورد نیاز، به سوال از کجا می توانم ابزارهای مورد نیاز خود را دریافت کنم؟ .

تشکیل پرونده پشتیبانی

دستورالعمل‌های ایجاد یک مورد پشتیبانی را در بخش پشتیبانی و منابع پلتفرم Google Maps دنبال کنید.

هنگام تشکیل پرونده پشتیبانی، علاوه بر داده های ذکر شده در بخش عیب یابی اولیه ، موارد زیر را نیز ارائه دهید:

  • آدرس های IP عمومی شما چیست؟
  • آدرس IP عمومی سرور DNS شما چیست؟
  • در صورت امکان ، ضبط بسته TCPDump یا Wireshark از مذاکره TLS شکست خورده علیه https://maps.googleapis.com/ در قالب PCAP ، با استفاده از یک عکس فوری به اندازه کافی بزرگ برای گرفتن کل بسته بدون کوتاه کردن آن (به عنوان مثال استفاده از -s0 در نسخه های قبلی tcpdump ).
  • در صورت امکان ، گزیده هایی از سرویس شما را نشان می دهد که دلیل دقیق خرابی اتصال TLS را نشان می دهد ، ترجیحاً با اطلاعات زنجیره ای گواهی سرور کامل.

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

ارسال در شماره عمومی 186840968

هنگام ارسال نظر در مورد شماره عمومی 186840968 ، اطلاعات ذکر شده در بخش عیب یابی اولیه را درج کنید.

چگونه می توانم آدرس عمومی DNS خود را تعیین کنم؟

در لینوکس ، می توانید دستور زیر را اجرا کنید:

dig -t txt o-o.myaddr.l.google.com

در ویندوز می توانید از NSLOOKUP در حالت تعاملی استفاده کنید:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

نحوه تفسیر خروجی فرفری

در حال curl با پرچم های -vvI اطلاعات بسیار مفیدی را ارائه می دهد. در اینجا چند دستورالعمل برای تفسیر خروجی آورده شده است:

  • خطوط شروع شده از خروجی " * " از مذاکره TLS و همچنین اطلاعات خاتمه اتصال.
  • خطوط شروع شده با ' > ' درخواست HTTP خروجی را که curl ارسال می کند ، نمایش می دهند.
  • خطوط شروع شده با ' < ' پاسخ http را که از سرور دریافت می کند ، نمایش می دهند.
  • اگر پروتکل https بود ، حضور خطوط ' > ' یا ' < ' حاکی از یک دست زدن به TLS موفق است.

بسته نرم افزاری از کتابخانه TLS و Root Certificate

در حال curl با پرچم های -vvI همچنین فروشگاه گواهینامه های ریشه مورد استفاده را چاپ می کند ، اما خروجی دقیق ممکن است در هر سیستم همانطور که در اینجا نشان داده شده است متفاوت باشد.

خروجی از دستگاه Red Hat Linux با curl مرتبط با NSS ممکن است حاوی این خطوط باشد:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

خروجی از دستگاه اوبونتو یا دبیان لینوکس ممکن است حاوی این خطوط باشد:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

خروجی از یک دستگاه Ubuntu یا Debian Linux با استفاده از پرونده Google Root PEM که با استفاده از پرچم --cacert داده شده است ممکن است حاوی این خطوط باشد:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

عامل کاربر

درخواست های خروجی حاوی عنوان کاربر-عامل است که ممکن است اطلاعات مفیدی در مورد curl و سیستم شما ارائه دهد.

نمونه ای از دستگاه Red Hat Linux:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

دست زدن به TLS ناموفق

خطوط ، مانند موارد موجود در این نمونه کد ، نشان می دهد که اتصال به دلیل داشتن گواهی سرور غیر قابل اعتماد ، اتصال Mid-TLS-Handshake خاتمه یافته است. فقدان خروجی اشکال زدایی از > یا < همچنین شاخص های قوی تلاش برای اتصال ناموفق هستند:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

دستکاری موفقیت آمیز TLS

دستکاری موفقیت آمیز TLS با وجود خطوط مشابه به نظر می رسد که در این نمونه کد وجود دارد. مجموعه Cipher مورد استفاده برای اتصال رمزگذاری شده باید ذکر شود ، همانطور که باید جزئیات گواهی سرور پذیرفته شده باشد. علاوه بر این ، وجود خطوط شروع شده از > یا < نشان می دهد که ترافیک HTTP بار با موفقیت از طریق اتصال رمزگذاری شده TLS منتقل می شود:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

نحوه چاپ گواهینامه های سرور دریافت شده به صورت قابل خواندن انسان

با فرض اینکه خروجی فرمت شده است ، به عنوان مثال خروجی از openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null ، شما می توانید پس از این مراحل ، گواهی خدمت را چاپ کنید:

  • کل گواهی رمزگذاری شده پایه 64 ، از جمله هدر و پاورقی را کپی کنید:

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • سپس انجام دهید:

    openssl x509 -inform pem -noout -text
    ````
  • سپس محتویات بافر کپی خود را در ترمینال بچسبانید.

  • کلید بازگشت را بزنید.

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

گواهینامه های Google با امضاء متقابل در OpenSSL چگونه به نظر می رسند؟

{# غیرفعال کردن (line_over_80)}

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

مدیریت گواهینامه های قابل اعتماد خود

چگونه می توانم گواهینامه های ریشه مورد اعتماد را در تلفن همراه خود بررسی کنم؟

گواهینامه های معتبر Android

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

نسخه اندروید مسیر منو
1.x ، 2.x ، 3.x N/A
4.x ، 5.x ، 6.x ، 7.x تنظیمات> امنیت> اعتبار معتبر
8.x ، 9 تنظیمات> امنیت و مکان> رمزگذاری و اعتبارنامه> اعتبارنامه قابل اعتماد
10+ تنظیمات> امنیت> پیشرفته> رمزگذاری و اعتبارنامه> اعتبار معتبر

این جدول در دسترس بودن احتمالی مهمترین گواهینامه های ریشه ای در هر نسخه Android ، بر اساس تأیید دستی با استفاده از تصاویر سیستم مجازی Android (AVD) موجود ، بازگشت به AOSP CA Certificates History Git History ، جایی که تصاویر سیستم دیگر در دسترس نبود ، نشان می دهد.

نسخه اندروید GTS ROOT R1 ROOT GLOBALSIGN ROOT CA - R1 Globalsign Root R2 (معتبر تا 15 دسامبر 2021)
2.3 ، 3.2 ، 4.x ، 5.x ، 6.x ، 7.x ، 8.x ، 9
10+

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

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

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

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

فروشگاه اعتماد iOS

اپل به طور مستقیم مجموعه پیش فرض خود را از گواهینامه های ریشه مورد اعتماد به کاربر گوشی نشان نمی دهد ، این شرکت پیوندهایی به مجموعه های Root Root برای نسخه های iOS 5 و بالاتر از مقالات پشتیبانی اپل دارد:

با این حال ، هر گواهی اضافی نصب شده بر روی دستگاه iOS باید تحت تنظیمات> عمومی> مشخصات قابل مشاهده باشد. در صورت نصب گواهی اضافی ، ممکن است مورد منوی پروفایل نمایش داده نشود.

این جدول در دسترس بودن مهمترین گواهینامه های ریشه در هر نسخه iOS ، بر اساس منابع فوق را نشان می دهد:

نسخه iOS GTS ROOT R1 ROOT GLOBALSIGN ROOT CA - R1 Globalsign Root R2 (معتبر تا 15 دسامبر 2021)
5 ، 6 ، 7 ، 8 ، 9 ، 10 ، 11 ، 12.0
12.1.3+

گواهینامه های ریشه سیستم من کجاست و چگونه می توانم آن را به روز کنم؟

محل فروشگاه گواهینامه های ریشه پیش فرض با سیستم عامل متفاوت است و از کتابخانه SSL/TLS استفاده شده است. با این حال ، در بیشتر توزیع های لینوکس ، گواهینامه های ریشه پیش فرض را می توان در یکی از مسیرهای زیر یافت:

  • /usr/local/share/ca-certificates
  • /etc/pki/ca-trust/source/anchors و /usr/share/pki/ca-trust-source : فدورا ، نسخه های جدیدتر RHEL و CENTOS
  • /var/lib/ca-certificates : openuse

سایر مسیرهای گواهینامه ممکن است عبارتند از:

  • /etc/ssl/certs : دبیان ، اوبونتو
  • /etc/pki/tls/certs : RHEL ، Centos

برخی از گواهینامه های موجود در این دایرکتوری ها احتمالاً پیوندهای نمادین با پرونده ها در دایرکتوری های دیگر هستند.

فروشگاه گواهینامه های ریشه OpenSSL

برای برنامه های کاربردی با استفاده از OpenSSL ، می توانید مکان پیکربندی شده اجزای نصب شده آن ، از جمله فروشگاه گواهینامه های پیش فرض ریشه را با استفاده از دستور زیر بررسی کنید:

openssl version -d

این فرمان از OPENSSLDIR چاپ می کند ، که مربوط به فهرست سطح بالایی است که کتابخانه و تنظیمات آن را می توان در زیر یافت:

OPENSSLDIR: "/usr/lib/ssl"

فروشگاه گواهینامه های ریشه در زیر مجموعه certs قرار دارد.

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21 2020 /usr/lib/ssl/certs -> /etc/ssl/certs
ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01 ca-certificates.crt
…
lrwxrwxrwx 1 root root 50 Apr 15 16:57 GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

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

برای دستورالعمل دریافت openssl ، به بخش دریافت OpenSSL مراجعه کنید.

فروشگاه گواهینامه های ریشه جاوا

برنامه های جاوا ممکن است از فروشگاه گواهینامه های ریشه خود استفاده کنند ، که در سیستم های لینوکس به طور معمول در /etc/pki/java/cacerts یا /usr/share/ca-certificates-java قرار دارد که می تواند با استفاده از ابزار خط فرمان java keytool مدیریت شود.

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

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

فقط کافی است cert.pem با پرونده گواهینامه مربوط به هر گواهی ریشه توصیه شده ، alias با یک گواهینامه منحصر به فرد اما معنی دار نام مستعار و certs.jks با پرونده پایگاه داده گواهی استفاده شده در محیط شما جایگزین کنید.

برای اطلاعات بیشتر ، به مقالات Oracle و Stack Overflow زیر مراجعه کنید:

فروشگاه گواهینامه های ریشه Mozilla NSS

برنامه های کاربردی با استفاده از Mozilla NSS ممکن است به طور پیش فرض نیز از یک پایگاه داده گواهینامه در سطح سیستم استفاده کنند که به طور معمول در زیر /etc/pki/nssdb قرار دارد ، یا یک فروشگاه پیش فرض خاص کاربر تحت ${HOME}/.pki/nssdb .

برای به روزرسانی پایگاه داده NSS خود ، از ابزار certutil استفاده کنید.

برای وارد کردن یک پرونده گواهینامه فردی به پایگاه داده NSS خود ، دستور زیر را صادر کنید:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

فقط کافی است cert.pem با پرونده گواهینامه مربوط به هر گواهی ریشه توصیه شده ، cert-name با نام مستعار گواهی معنی دار و certdir با مسیر پایگاه داده گواهی استفاده شده در محیط خود جایگزین کنید.

برای کسب اطلاعات بیشتر ، به دفترچه راهنمای رسمی NSS Tools Centutil و همچنین مستندات سیستم عامل خود مراجعه کنید.

فروشگاه گواهینامه های ریشه Microsoft .NET

توسعه دهندگان ویندوز .NET ممکن است حداقل مقالات زیر مایکروسافت را برای به روزرسانی فروشگاه گواهینامه های ریشه خود پیدا کنند:

فرمت های پرونده گواهی

پرونده PEM چیست؟

Mail با افزایش حریم خصوصی (PEM) یک فرمت فایل متنی استاندارد برای ذخیره و ارسال گواهینامه های رمزنگاری ، کلیدها و غیره است که به عنوان یک استاندارد De-Jure در RFC 7468 رسمی شده است.

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

از ابزارهایی مانند openssl نیز می توان برای رمزگشایی کل گواهی به فرم قابل خواندن انسان استفاده کرد. برای اطلاعات بیشتر به بخش نحوه چاپ گواهینامه های PEM در فرم قابل خواندن انسان مراجعه کنید.

پرونده ".crt" چیست؟

ابزارهایی که اجازه صادر کردن گواهینامه ها را با فرمت PEM می دهند ، معمولاً از پسوند پرونده ".crt" استفاده می کنند تا فایل از یک رمزگذاری متنی استفاده کند.

پرونده der چیست؟

قوانین رمزگذاری متمایز (DER) یک قالب باینری استاندارد برای گواهینامه های رمزگذاری است. گواهینامه های موجود در پرونده های PEM به طور معمول گواهینامه های DER رمزگذاری شده BASE64 هستند.

پرونده ".cer" چیست؟

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

سیستم من از وارد کردن تمام گواهینامه ها از Roots.pem امتناع می ورزد

برخی از سیستم ها ، به عنوان مثال ، Java keytool ، فقط ممکن است یک گواهی واحد را از یک پرونده PEM وارد کنند ، حتی اگر حاوی چندین مورد باشد. به سوال مراجعه کنید چگونه می توانم گواهینامه های فردی را از Roots.pem استخراج کنم؟ برای دیدن چگونگی تقسیم پرونده در ابتدا.

چگونه می توانم گواهینامه های فردی را از Roots.pem استخراج کنم؟

شما می توانید با استفاده از اسکریپت Bash زیر ، roots.pem را در گواهینامه های مؤلفه آن تقسیم کنید:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

این باید تعدادی از پرونده های PEM شخصی مشابه موارد ذکر شده در اینجا ایجاد کند:

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

پرونده های PEM شخصی ، مانند 02265526.pem می توانند به طور جداگانه وارد شوند ، یا بیشتر به یک قالب پرونده تبدیل می شوند که فروشگاه گواهی شما را می پذیرد.

نحوه تبدیل بین یک فایل PEM و یک فرمی که توسط سیستم من پشتیبانی می شود

از ابزار خط فرمان OpenSSL Toolkit openssl می توان برای تبدیل پرونده ها بین تمام قالب های پرونده گواهینامه معمول استفاده کرد. دستورالعمل های تبدیل از یک پرونده PEM به قالب های متداول پرونده های گواهینامه در زیر ذکر شده است.

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

برای دستورالعمل دریافت openssl ، به بخش دریافت OpenSSL مراجعه کنید.

چگونه می توانم یک فایل PEM را به قالب der تبدیل کنم؟

با استفاده از openssl می توانید دستور زیر را برای تبدیل پرونده ای از PEM به DER صادر کنید:

openssl x509 -in roots.pem -outform der -out roots.der
چگونه می توانم یک فایل PEM را به PKCS #7 تبدیل کنم؟

با استفاده از openssl می توانید دستور زیر را برای تبدیل پرونده ای از PEM به PKCS #7 صادر کنید:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
چگونه می توانم یک فایل PEM را به PKCS #12 (PFX) تبدیل کنم؟

با استفاده از openssl می توانید دستور زیر را برای تبدیل پرونده ای از PEM به PKCS #12 صادر کنید:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

هنگام ایجاد بایگانی PKCS #12 باید یک رمز عبور فایل ارائه دهید. اگر بلافاصله پرونده PKCS #12 را در سیستم خود وارد نکنید ، حتماً رمز عبور را در جایی ایمن ذخیره کنید.

گواهینامه های لیست ، چاپ و صادرات از فروشگاه گواهینامه های ریشه خود

چگونه می توانم گواهی را از فروشگاه Key Java به عنوان یک فایل PEM صادر کنم؟

با استفاده از keytool می توانید دستور زیر را برای لیست کلیه گواهینامه ها در فروشگاه گواهینامه خود صادر کنید ، به همراه نام مستعار که می توانید برای صادرات هر یک از آنها استفاده کنید:

keytool -v -list -keystore certs.jks

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

برای صادر کردن گواهینامه فردی با فرمت PEM ، دستور زیر را صادر کنید:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

فقط کافی است certs.jks با پرونده پایگاه داده گواهی استفاده شده در محیط خود جایگزین کنید و یک alias و alias.pem مربوط به گواهی مورد نظر برای صادرات را تهیه کنید.

برای اطلاعات بیشتر ، به Platform Java ، Reference Tools Edition Reference مراجعه کنید: KeyTool {: .External}.

چگونه می توان گواهینامه ها را از فروشگاه گواهینامه های ریشه NSS به عنوان یک فایل PEM صادر کرد؟

با استفاده از certutil می توانید دستور زیر را برای لیست کلیه گواهینامه ها در فروشگاه گواهینامه خود صادر کنید ، به همراه نام مستعار می توانید برای صادرات هر یک از آنها استفاده کنید:

certutil -L -d certdir

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

برای صادر کردن گواهینامه فردی با فرمت PEM ، دستور زیر را صادر کنید:

certutil -L -n cert-name -a -d certdir > cert.pem

فقط کافی است certdir با مسیر پایگاه داده Certificate که در محیط خود استفاده می شود جایگزین کنید و یک cert-name و cert.pem را ارائه دهید.

برای کسب اطلاعات بیشتر ، به دفترچه راهنمای رسمی NSS Tools Centutil و همچنین مستندات سیستم عامل خود مراجعه کنید.

نحوه چاپ گواهینامه های PEM به شکل قابل خواندن انسان

در مثالهای زیر تصور می کنیم پرونده GTS_Root_R1.pem را با محتویات زیر دارید:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
چاپ پرونده های گواهینامه با استفاده از OpenSSL

صدور دستور

openssl x509 -in GTS_Root_R1.pem -text

باید چیزی شبیه به:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

برای دستورالعمل دریافت openssl ، به بخش دریافت OpenSSL مراجعه کنید.

گواهینامه های چاپ با استفاده از keytool جاوا

صدور دستور زیر

keytool -printcert -file GTS_Root_R1.pem

باید چیزی شبیه به:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

برای دستورالعمل دریافت keytool ، به بخش دریافت java keytool مراجعه کنید.

چگونه می توانم ببینم چه گواهینامه هایی در فروشگاه گواهینامه های من نصب شده است؟

این در هر سیستم عامل و کتابخانه SSL/TLS متفاوت است. با این حال ، ابزارهایی که اجازه می دهد گواهی های واردات و صادرات به فروشگاه گواهینامه های ریشه را به طور معمول و همچنین گزینه ای برای لیست گواهینامه های نصب شده ارائه دهند.

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

پرونده PEM ممکن است به درستی برچسب گذاری شود ، و اطلاعات قابل خواندن انسان از مرجع گواهینامه مرتبط (نمونه ای از بسته معتبر Google Root CA ) را ارائه می دهد:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

پرونده همچنین ممکن است فقط قسمت گواهینامه را داشته باشد. در چنین مواردی ، نام پرونده مانند GTS_Root_R1.pem ممکن است توصیف کند که CA گواهی متعلق به آن است. رشته گواهی بین -----BEGIN CERTIFICATE----- و -----END CERTIFICATE----- توکن ها نیز برای هر CA بی نظیر است.

با این حال ، حتی اگر شما از ابزارهای فوق برخوردار نیستید ، زیرا هر گواهی موجود در بسته معتبر Google Root CA به درستی برچسب گذاری شده است ، می توانید با اطمینان با Root CA را از Aganist Bundle مطابقت دهید و آنهایی را که از گواهینامه های ریشه شما استفاده می کنند یا با Issuer ، یا با مقایسه رشته های گواهی نامه PEM.

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

برای دستورالعمل های خاص تلفن همراه ، به این سؤال جداگانه مراجعه کنید که چگونه می توانم گواهینامه های ریشه مورد اعتماد را در تلفن همراه خود بررسی کنم؟ .

ضمیمه

به اطلاعات بیشتری نیاز دارید؟

همیشه در درجه اول به مستندات سیستم عامل خود ، مستندات زبان (های) برنامه نویسی برنامه خود و همچنین مستندات مربوط به هر کتابخانه خارجی که برنامه شما استفاده می کند ، اعتماد کنید.

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

همچنین سؤالات متداول خدمات Google Trust را بررسی کنید.

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

برای اطلاعات بیشتر در مورد مباحث پیشرفته ، مانند Pinning Certificate ، ممکن است گواهی پروژه امنیتی برنامه وب باز (OWASP) و مقاله کلیدی عمومی را پیدا کنید و ورق های تقلب را آموزنده کنید. برای دستورالعمل های خاص Android ، با سند آموزش HTTPS و SSL به بهترین روشهای رسمی Android برای امنیت و امنیت حریم خصوصی مراجعه کنید. برای بحث در مورد گواهینامه در مقابل پین کردن کلید عمومی در Android ، ممکن است پست وبلاگ Matthew Dolan Security Android Security: SSL Pinning مفید باشد.

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

برای یک لیست جامع از ریشه های ریشه مورد اعتماد AOSP ، به مخزن CA CATIFICITATES GIT مراجعه کنید. برای هر نسخه بر اساس چنگال های غیر رسمی اندرویدی ، به عنوان مثال Lineageos ، به مخازن مناسب ارائه شده توسط فروشنده سیستم عامل مراجعه کنید.