Google মানচিত্র প্ল্যাটফর্ম রুট CA মাইগ্রেশন FAQ

এই নথিতে নিম্নলিখিত বিভাগগুলি রয়েছে:

চলমান Google রুট CA মাইগ্রেশনের আরও বিশদ বিবরণের জন্য, দেখুন কী ঘটছে? .

পরিভাষা

নীচে, আমরা এই নথির জন্য আপনার পরিচিত হতে হবে এমন সবচেয়ে গুরুত্বপূর্ণ পদগুলির একটি তালিকা সংগ্রহ করেছি৷ সম্পর্কিত পরিভাষাগুলির আরও ব্যাপক ওভারভিউয়ের জন্য, অনুগ্রহ করে Google Trust Services FAQ- এ যান৷

SSL/TLS সার্টিফিকেট
একটি শংসাপত্র একটি পরিচয়ের সাথে একটি ক্রিপ্টোগ্রাফিক কীকে আবদ্ধ করে।
SSL/TLS শংসাপত্রগুলি প্রমাণীকরণ এবং ওয়েবসাইটগুলিতে সুরক্ষিত সংযোগ স্থাপন করতে ব্যবহৃত হয়। শংসাপত্রগুলি জারি করা হয় এবং ক্রিপ্টোগ্রাফিকভাবে শংসাপত্র কর্তৃপক্ষ হিসাবে পরিচিত সত্তা দ্বারা স্বাক্ষরিত হয়।
ব্রাউজারগুলি বিশ্বস্ত শংসাপত্র কর্তৃপক্ষের দ্বারা জারি করা শংসাপত্রের উপর নির্ভর করে যে প্রেরিত তথ্য সঠিক সার্ভারে পাঠানো হয়েছে এবং ট্রানজিটের সময় এটি এনক্রিপ্ট করা হয়েছে।
সিকিউর সকেট লেয়ার (SSL)
সিকিউর সকেট লেয়ার ইন্টারনেট যোগাযোগ এনক্রিপ্ট করতে ব্যবহৃত সবচেয়ে ব্যাপকভাবে মোতায়েন করা প্রোটোকল ছিল। SSL প্রোটোকলকে আর নিরাপদ বলে মনে করা হয় না এবং ব্যবহার করা উচিত নয়।
ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS)
ট্রান্সপোর্ট লেয়ার সিকিউরিটি হল SSL এর উত্তরসূরী।
শংসাপত্র কর্তৃপক্ষ (CA)
একটি শংসাপত্র কর্তৃপক্ষ ডিভাইস এবং লোকেদের জন্য একটি ডিজিটাল পাসপোর্ট অফিসের মতো। এটি প্রমাণ করার জন্য ক্রিপ্টোগ্রাফিকভাবে সুরক্ষিত নথি (শংসাপত্র) জারি করে যে একটি সত্তা (যেমন ওয়েবসাইট) যাকে দাবি করে।
একটি শংসাপত্র ইস্যু করার আগে, সার্টিফিকেটের নামগুলি যে ব্যক্তি বা সত্তা এটির জন্য অনুরোধ করছেন তার সাথে লিঙ্ক করা আছে কিনা তা যাচাই করার জন্য CAগুলি দায়ী৷
সার্টিফিকেট অথরিটি শব্দটি গুগল ট্রাস্ট সার্ভিসের মতো উভয় সংস্থাকে এবং সার্টিফিকেট ইস্যু করা সিস্টেমকে নির্দেশ করতে পারে।
রুট সার্টিফিকেটের দোকান
একটি রুট শংসাপত্রের দোকানে একটি অ্যাপ্লিকেশন সফ্টওয়্যার সরবরাহকারী দ্বারা বিশ্বস্ত শংসাপত্র কর্তৃপক্ষের একটি সেট থাকে৷ বেশিরভাগ ওয়েব ব্রাউজার এবং অপারেটিং সিস্টেমের নিজস্ব রুট সার্টিফিকেট স্টোর রয়েছে।
একটি রুট শংসাপত্রের দোকানে অন্তর্ভুক্ত হতে, শংসাপত্র কর্তৃপক্ষকে অবশ্যই অ্যাপ্লিকেশন সফ্টওয়্যার সরবরাহকারী দ্বারা নির্ধারিত কঠোর প্রয়োজনীয়তা পূরণ করতে হবে।
সাধারণত এর মধ্যে CA/ব্রাউজার ফোরামের প্রয়োজনীয়তার মতো শিল্পের মানগুলির সাথে সম্মতি অন্তর্ভুক্ত থাকে।
রুট সার্টিফিকেট কর্তৃপক্ষ
একটি রুট সার্টিফিকেট অথরিটি (বা আরও সঠিকভাবে, এর শংসাপত্র) একটি শংসাপত্র শৃঙ্খলে শীর্ষ শংসাপত্র।
রুট CA সার্টিফিকেট সাধারণত স্ব-স্বাক্ষরিত হয়। তাদের সাথে সম্পর্কিত ব্যক্তিগত কীগুলি অত্যন্ত সুরক্ষিত সুবিধাগুলিতে সংরক্ষণ করা হয় এবং অননুমোদিত অ্যাক্সেস থেকে রক্ষা করার জন্য অফলাইন অবস্থায় রক্ষণাবেক্ষণ করা হয়।
ইন্টারমিডিয়েট সার্টিফিকেট কর্তৃপক্ষ
একটি মধ্যবর্তী শংসাপত্র কর্তৃপক্ষ (বা আরও সঠিকভাবে, এর শংসাপত্র) হল একটি শংসাপত্র যা একটি শংসাপত্র চেইনে অন্যান্য শংসাপত্রে স্বাক্ষর করতে ব্যবহৃত হয়।
রুট CA শংসাপত্র অফলাইনে থাকার অনুমতি দেওয়ার সময় ইন্টারমিডিয়েট CAগুলি প্রাথমিকভাবে অনলাইন শংসাপত্র ইস্যু সক্ষম করার জন্য বিদ্যমান।
ইন্টারমিডিয়েট CAগুলি অধস্তন CA হিসাবেও পরিচিত।
সার্টিফিকেট প্রদানকারী কর্তৃপক্ষ
একটি ইস্যুকারী শংসাপত্র কর্তৃপক্ষ, বা আরও সঠিকভাবে, এর শংসাপত্র হল সেই শংসাপত্র যা একটি শংসাপত্রের চেইনে সবচেয়ে নীচের শংসাপত্রে স্বাক্ষর করতে ব্যবহৃত হয়।
এই নীচের-সর্বাধিক শংসাপত্রটিকে সাধারণত একটি গ্রাহক শংসাপত্র, শেষ-সত্তা শংসাপত্র বা পাতার শংসাপত্র বলা হয়। এই নথিতে আমরা সার্ভার সার্টিফিকেট শব্দটিও ব্যবহার করব৷
সার্টিফিকেট চেইন
শংসাপত্রগুলি তাদের ইস্যুকারীর সাথে সংযুক্ত (ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত)। একটি শংসাপত্রের চেইন একটি পাতা-শংসাপত্র, এর সমস্ত ইস্যুকারী শংসাপত্র এবং একটি মূল শংসাপত্র দিয়ে তৈরি।
ক্রস সাইনিং
অ্যাপ্লিকেশন সফ্টওয়্যার সরবরাহকারীর ক্লায়েন্টদের তাদের পণ্যগুলির দ্বারা বিশ্বস্ত হওয়ার জন্য নতুন CA শংসাপত্রগুলি অন্তর্ভুক্ত করতে তাদের রুট সার্টিফিকেট স্টোর আপডেট করতে হবে৷ নতুন CA শংসাপত্র সম্বলিত পণ্যগুলি ব্যাপকভাবে ব্যবহৃত হওয়া পর্যন্ত কিছু সময় লাগে৷
পুরানো ক্লায়েন্টদের সাথে সামঞ্জস্য বাড়াতে, CA শংসাপত্রগুলি অন্য পুরানো প্রতিষ্ঠিত CA দ্বারা "ক্রস স্বাক্ষরিত" হতে পারে। এটি কার্যকরভাবে একই পরিচয়ের জন্য একটি দ্বিতীয় CA শংসাপত্র তৈরি করে (নাম এবং কী জোড়া)।
তাদের রুট সার্টিফিকেট স্টোরে অন্তর্ভুক্ত CA-এর উপর নির্ভর করে, ক্লায়েন্টরা তাদের বিশ্বাসযোগ্য একটি রুট পর্যন্ত একটি ভিন্ন সার্টিফিকেট চেইন তৈরি করবে।

সাধারণ জ্ঞাতব্য

কি হচ্ছে?

বড় ছবি

2017 সালে, Google তার নিজস্ব রুট সার্টিফিকেট ইস্যু এবং ব্যবহার করার জন্য একটি বহু-বছরের প্রকল্প শুরু করে, ক্রিপ্টোগ্রাফিক স্বাক্ষর যা HTTPS দ্বারা ব্যবহৃত TLS ইন্টারনেট নিরাপত্তার ভিত্তি।

প্রথম পর্যায়ের পরে, Google মানচিত্র প্ল্যাটফর্ম পরিষেবাগুলির TLS নিরাপত্তা GS Root R2 দ্বারা নিশ্চিত করা হয়েছে, একটি অত্যন্ত সুপরিচিত এবং ব্যাপকভাবে বিশ্বস্ত রুট সার্টিফিকেট অথরিটি (CA), যা Google আমাদের নিজস্ব স্ব-পরিবর্তন সহজ করার জন্য GMO GlobalSign থেকে অধিগ্রহণ করেছে। জারি করা Google Trust Services (GTS) রুট CA.

কার্যত সমস্ত TLS ক্লায়েন্ট (যেমন ওয়েব ব্রাউজার, স্মার্টফোন এবং অ্যাপ্লিকেশন সার্ভার) এই রুট সার্টিফিকেটে বিশ্বাস করেছে, এবং তাই মাইগ্রেশনের প্রথম পর্যায়ে Google মানচিত্র প্ল্যাটফর্ম সার্ভারের সাথে একটি নিরাপদ সংযোগ স্থাপন করতে সক্ষম হয়েছে।

যাইহোক, একটি CA ডিজাইন দ্বারা শংসাপত্র জারি করতে পারে না যা তার নিজের শংসাপত্রের মেয়াদ শেষ হওয়ার পরে বৈধ। যেহেতু GS Root R2 এর মেয়াদ 15 ডিসেম্বর, 2021-এ শেষ হচ্ছে, Google এর নিজস্ব রুট CA GTS Root R1 দ্বারা জারি করা একটি শংসাপত্র ব্যবহার করে Google তার নিজস্ব পরিষেবাগুলিকে একটি নতুন CA, GTS Root R1 Cross- এ স্থানান্তর করবে।

যদিও বেশিরভাগ আধুনিক অপারেটিং সিস্টেম এবং TLS ক্লায়েন্ট লাইব্রেরিগুলি ইতিমধ্যেই GTS রুট CA-কে বিশ্বাস করে, এছাড়াও বেশিরভাগ উত্তরাধিকারী সিস্টেমের জন্য একটি মসৃণ রূপান্তর নিশ্চিত করতে, Google GlobalSign Root CA - R1 ব্যবহার করে GMO GlobalSign থেকে একটি ক্রস-সাইন অর্জন করেছে, যার মধ্যে একটি। প্রাচীনতম, সবচেয়ে বিশ্বস্ত রুট CA বর্তমানে উপলব্ধ।

তাই, বেশিরভাগ গ্রাহকের Google Maps প্ল্যাটফর্ম ক্লায়েন্টরা ইতিমধ্যেই এই ভাল-বিশ্বস্ত রুট CA-গুলির মধ্যে একটিকে (বা উভয়কেই) চিনতে পারবে, এবং মাইগ্রেশনের দ্বিতীয় পর্যায়ের দ্বারা সম্পূর্ণরূপে প্রভাবিত হবে না৷

এটি সেইসব গ্রাহকদের ক্ষেত্রেও প্রযোজ্য যারা 2018 সালে মাইগ্রেশনের প্রথম পর্যায়ে পদক্ষেপ নিয়েছিলেন, অনুমান করে যে তারা সেই সময়ে আমাদের নির্দেশাবলী অনুসরণ করেছিল, আমাদের বিশ্বস্ত Google রুট CA বান্ডেল থেকে সমস্ত শংসাপত্র ইনস্টল করে।

আপনার সিস্টেমগুলি যাচাই করা উচিত, যদি নিম্নলিখিতগুলি প্রযোজ্য হয়:

  • আপনার পরিষেবাগুলি অ-মানক বা লিগ্যাসি প্ল্যাটফর্ম চালায় এবং/অথবা আপনি আপনার নিজস্ব রুট সার্টিফিকেট স্টোর বজায় রাখেন
  • আপনি 2017-2018 সালে Google-এর রুট CA মাইগ্রেশনের প্রথম পর্বে পদক্ষেপ নেননি, অথবা আপনি বিশ্বস্ত Google রুট CA বান্ডেল থেকে সার্টিফিকেটের সম্পূর্ণ সেট ইনস্টল করেননি

উপরেরটি প্রযোজ্য হলে, মাইগ্রেশনের এই পর্যায়ে নিরবচ্ছিন্ন Google Maps প্ল্যাটফর্ম ব্যবহার নিশ্চিত করতে আপনার ক্লায়েন্টদের প্রস্তাবিত রুট সার্টিফিকেটের সাথে আপডেট করতে হতে পারে।

আরও প্রযুক্তিগত বিবরণের জন্য নীচে দেখুন। সাধারণ নির্দেশাবলীর জন্য, অনুগ্রহ করে আমার রুট সার্টিফিকেট স্টোরের একটি আপডেটের প্রয়োজন আছে কিনা তা যাচাই করতে কিভাবে বিভাগটি পড়ুন।

আমরা আরও সুপারিশ করি যে আপনি আপনার রুট সার্টিফিকেট স্টোরগুলিকে উপরের কিউরেটেড রুট CA বান্ডেলের সাথে সিঙ্ক করে রাখুন যাতে আপনার পরিষেবাগুলি ভবিষ্যতের রুট CA পরিবর্তনের বিরুদ্ধে প্রমাণিত হয়। তবে এগুলো আগেই ঘোষণা করা হবে। বিভাগগুলি দেখুন কিভাবে আমি এই মাইগ্রেশন পর্বের আপডেট পেতে পারি? এবং কিভাবে আমি ভবিষ্যতের মাইগ্রেশনের আগাম বিজ্ঞপ্তি পেতে পারি? কিভাবে অবগত থাকতে হয় তার উপর আরও নির্দেশাবলীর জন্য।

প্রযুক্তিগত সারাংশ

Google সিকিউরিটি ব্লগে 15 মার্চ 2021-এ ঘোষণা করা হয়েছে, GS Root R2 , 2018 সালের শুরু থেকে ব্যবহৃত রুট CA Google Maps প্ল্যাটফর্মের মেয়াদ 15 ডিসেম্বর, 2021-এ শেষ হবে৷ তাই Google এই বছরের মধ্যে একটি নতুন জারি করা CA GTS Root R1- এ স্থানান্তরিত হবে৷ ক্রস এর মানে হল যে আমাদের পরিষেবাগুলি ধীরে ধীরে এই নতুন CA দ্বারা জারি করা TLS পাতার শংসাপত্রগুলিতে স্থানান্তরিত হবে৷

প্রায় সমস্ত আধুনিক TLS ক্লায়েন্ট এবং সিস্টেমগুলি ইতিমধ্যেই GTS Root R1 শংসাপত্রের সাথে প্রি-কনফিগার করা হয়েছে বা সাধারণ সফ্টওয়্যার আপডেটের মাধ্যমে এটি গ্রহণ করা উচিত, এবং GlobalSign Root CA - R1 এমনকি পুরানো লিগ্যাসি সিস্টেমগুলিতে উপলব্ধ হওয়া উচিত।

যাইহোক, আপনার সিস্টেমগুলি অন্তত যাচাই করা উচিত যদি নিম্নলিখিত দুটি পয়েন্টই প্রযোজ্য হয়:

  • আপনার পরিষেবাগুলি অ-মানক বা লিগ্যাসি প্ল্যাটফর্মে চলে এবং/অথবা আপনি আপনার নিজস্ব রুট সার্টিফিকেট স্টোর বজায় রাখেন
  • আপনি 2017-2018 সালে Google-এর রুট CA মাইগ্রেশনের প্রথম পর্বে পদক্ষেপ নেননি, অথবা আপনি বিশ্বস্ত Google রুট CA বান্ডেল থেকে সার্টিফিকেটের সম্পূর্ণ সেট ইনস্টল করেননি

আমার রুট সার্টিফিকেট স্টোরের আপডেটের প্রয়োজন আছে কিনা তা যাচাই করার বিভাগ আপনার সিস্টেম প্রভাবিত হবে কিনা তা পরীক্ষার জন্য সাধারণ নির্দেশিকা প্রদান করে।

প্রশ্ন দেখুন কেন আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখতে হবে? সম্পূর্ণ বিবরণের জন্য।

কিভাবে আমি এই মাইগ্রেশন পর্বের আপডেট পেতে পারি?

আপডেটের জন্য স্টার পাবলিক ইস্যু 186840968 । এই প্রায়শই জিজ্ঞাসিত প্রশ্নগুলি মাইগ্রেশন প্রক্রিয়া জুড়ে আপডেট করা হয়, যখনই আমরা সাধারণ আগ্রহের বিষয়গুলির মুখোমুখি হই।

কিভাবে আমি ভবিষ্যতের মাইগ্রেশনের অগ্রিম বিজ্ঞপ্তি পেতে পারি?

আমরা আপনাকে Google নিরাপত্তা ব্লগ অনুসরণ করার পরামর্শ দিই। আমরা ব্লগে প্রকাশ্য ঘোষণা অনুসরণ করে যত তাড়াতাড়ি সম্ভব পণ্য-নির্দিষ্ট ডকুমেন্টেশন আপডেট করার চেষ্টা করব।

অনুগ্রহ করে Google Maps প্ল্যাটফর্ম বিজ্ঞপ্তিতেও সাবস্ক্রাইব করুন, কারণ আমরা নিয়মিত ফোরামে এমন পরিবর্তনগুলি সম্পর্কে আপডেট পোস্ট করি যা সম্ভবত আরও বেশি সংখ্যক গ্রাহককে প্রভাবিত করতে পারে৷

আমরা একাধিক Google পরিষেবা ব্যবহার করি। রুট CA মাইগ্রেশন কি তাদের সবাইকে প্রভাবিত করবে?

হ্যাঁ, রুট CA মাইগ্রেশন সমস্ত Google পরিষেবা এবং API জুড়ে ঘটবে, কিন্তু টাইমলাইন পরিষেবা প্রতি পরিবর্তিত হতে পারে। যাইহোক, একবার আপনি যাচাই করেছেন যে আপনার Google মানচিত্র প্ল্যাটফর্ম ক্লায়েন্ট অ্যাপ্লিকেশনগুলির দ্বারা ব্যবহৃত রুট সার্টিফিকেট স্টোরগুলিতে বিশ্বস্ত Google রুট CA বান্ডেলে তালিকাভুক্ত সমস্ত CA রয়েছে, আপনার পরিষেবাগুলি চলমান স্থানান্তর দ্বারা প্রভাবিত হওয়া উচিত নয় এবং এগুলিকে সিঙ্কে রাখাও রক্ষা করবে আপনি ভবিষ্যতের রুট CA পরিবর্তনের বিরুদ্ধে।

প্রশ্ন দেখুন কেন আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখতে হবে? এবং কোন ধরণের অ্যাপ্লিকেশনগুলি ভাঙার ঝুঁকিতে রয়েছে? আরও অন্তর্দৃষ্টি জন্য.

আমার রুট সার্টিফিকেট স্টোরের একটি আপডেটের প্রয়োজন আছে কিনা তা যাচাই করার বিভাগ নীচে আপনার সিস্টেম পরীক্ষা করার জন্য সাধারণ নির্দেশাবলী প্রদান করে।

আমার রুট সার্টিফিকেট স্টোরের একটি আপডেটের প্রয়োজন কিনা তা কীভাবে যাচাই করবেন

নীচে তালিকাভুক্ত পরীক্ষার শেষ পয়েন্টগুলির বিরুদ্ধে আপনার আবেদনের পরিবেশ পরীক্ষা করুন:

  • আপনি যদি GTS Root R1 ক্রস টেস্ট এন্ডপয়েন্টের সাথে একটি TLS সংযোগ স্থাপন করতে সক্ষম হন, তাহলে আপনি GS Root R2 মেয়াদ শেষ হওয়ার দ্বারা প্রভাবিত হবেন না।
  • আপনি যদি GTS Root R1 টেস্ট এন্ডপয়েন্টের সাথে একটি TLS সংযোগ স্থাপন করতে সক্ষম হন, তাহলে আপনার আবেদনটি সম্ভবত 2028 সালে GTS Root R1 Cross এবং GlobalSign Root CA - R1 এর মেয়াদ শেষ হওয়া থেকে রক্ষা পাবে।

আপনার সিস্টেম সাধারণত এই রুট CA পরিবর্তনের সাথে সামঞ্জস্যপূর্ণ হবে যদি:

  • আপনার পরিষেবা একটি রক্ষণাবেক্ষণ করা মূলধারার অপারেটিং সিস্টেমে চলে, এবং আপনি উভয় অপারেটিং সিস্টেম এবং আপনার পরিষেবা ব্যবহার করা লাইব্রেরিগুলিকে প্যাচ আপ করে রেখেছেন এবং আপনি আপনার নিজস্ব রুট সার্টিফিকেট স্টোর বজায় রাখেন না , অথবা:
  • আপনি আমাদের পূর্ববর্তী সুপারিশগুলি অনুসরণ করেছেন এবং বিশ্বস্ত Google রুট CA বান্ডেল থেকে সমস্ত রুট CA ইনস্টল করেছেন৷

সম্ভবত প্রভাবিত গ্রাহকদের অবিলম্বে বিশ্বস্ত Google রুট CA বান্ডেল থেকে শংসাপত্রগুলি ইনস্টল করা উচিত যাতে ভবিষ্যতে পরিষেবা বাধা না হয়।

প্রশ্ন দেখুন কেন আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখতে হবে? সম্পূর্ণ বিবরণের জন্য।

আমাদের রুট সার্টিফিকেট স্টোর যাচাই করার জন্য আমি কি কোন সহজ টুল ব্যবহার করতে পারি?

আপনি আপনার তদন্তে দুটি কমান্ড লাইন curl এবং openssl দরকারী খুঁজে পেতে পারেন। উভয়ই বেশিরভাগ প্ল্যাটফর্মে উপলব্ধ, এবং আপনার সেটআপ পরীক্ষা করার জন্য ব্যাপক বিকল্পগুলি অফার করে।

curl পাওয়ার নির্দেশাবলীর জন্য, নীচের কার্ল পাওয়া বিভাগটি দেখুন।

নীচে দেখানো openssl কমান্ডগুলি 1.1.1 বা পরবর্তী সংস্করণের জন্য। 1.1.1 এর আগের সংস্করণগুলি সমর্থনের বাইরে। আপনি যদি পূর্ববর্তী সংস্করণ ব্যবহার করেন তবে আপনার সংস্করণের জন্য প্রয়োজনীয় এই কমান্ডগুলি আপগ্রেড বা সংশোধন করুন। openssl পাওয়ার নির্দেশাবলীর জন্য, নীচে OpenSSL পাওয়া বিভাগটি দেখুন।

আপনি বিভাগের অধীনে আরও দরকারী সরঞ্জামগুলিও পাবেন আমার প্রয়োজনীয় সরঞ্জামগুলি আমি কোথায় পেতে পারি? নিচে.

কংক্রিট পরীক্ষার নির্দেশাবলীর জন্য, অনুগ্রহ করে আমার রুট সার্টিফিকেট স্টোরের আপডেটের প্রয়োজন আছে কিনা তা কীভাবে যাচাই করবেন বিভাগটি দেখুন।

আপনার ডিফল্ট রুট সার্টিফিকেট স্টোর পরীক্ষা করা হচ্ছে

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

বিশ্বস্ত Google রুট CA বান্ডেল যাচাই করা হচ্ছে

বিশ্বস্ত Google রুট CA বান্ডেল ডাউনলোড করুন, তারপর এই পদক্ষেপগুলি অনুসরণ করুন:

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

কিভাবে এবং কখন Google রুট CA মাইগ্রেশন অব্যাহত থাকবে?

  1. প্রথম পর্যায় (GS Root R2 এ স্থানান্তরিত করা), যা 2017 সালের জানুয়ারিতে ঘোষণা করা হয়েছিল , 2017 সালের শেষের দিকে শুরু হয়েছিল এবং 2018 সালের প্রথমার্ধে শেষ হয়েছিল।
  2. দ্বিতীয় পর্যায় (GTS Root R1 Cross-এ স্থানান্তর) মার্চ 2021-এ ঘোষণা করা হয়েছিল এবং 15 ডিসেম্বর, 2021-এ GS Root R2-এর মেয়াদ শেষ হওয়ার আগে আগামী মাসগুলিতে এটি চালু হবে।

ভবিষ্যতের শংসাপত্রের মেয়াদ শেষ হওয়ার আগেই চূড়ান্ত মাইগ্রেশন পর্বের সময়সূচী ঘোষণা করা হবে।

যাইহোক, আপনি ভবিষ্যতে আপনার অ্যাপগুলি প্রমাণ করতে সক্ষম হবেন, যদি আপনি বিশ্বস্ত Google রুট CA বান্ডেলে রুট CA-এর কিউরেটেড তালিকার সাথে আপনার রুট সার্টিফিকেট স্টোর সিঙ্ক করে রাখেন।

এছাড়াও প্রশ্ন দেখুন কেন আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখতে হবে? আরও পটভূমির জন্য।

প্রতিটি Google পরিষেবার জন্য সাধারণ রোলআউট প্ল্যান৷

  1. স্টেজড রোলআউট একটি একক ডেটা সেন্টারে শুরু হয়।
  2. বিশ্বব্যাপী কভারেজ না হওয়া পর্যন্ত রোলআউটটি ধীরে ধীরে আরও ডেটা সেন্টারে প্রসারিত হয়।
  3. কোনো পর্যায়ে গুরুতর সমস্যা ধরা পড়লে, সমস্যাগুলো সমাধান করার সময় পরীক্ষাগুলো সাময়িকভাবে ফিরিয়ে আনা যেতে পারে।
  4. পূর্ববর্তী পুনরাবৃত্তির ইনপুটের উপর ভিত্তি করে, ধীরে ধীরে সমস্ত Google পরিষেবা নতুন শংসাপত্রে স্থানান্তরিত না হওয়া পর্যন্ত আরও Google পরিষেবাগুলি রোলআউটে অন্তর্ভুক্ত করা হয়।

কে আক্রান্ত হবে, কখন, কোথায়?

Google Maps প্ল্যাটফর্ম ডেভেলপারদের ক্রমবর্ধমান সংখ্যক নতুন ডেটা সেন্টার স্থানান্তরিত হওয়ার সাথে সাথে নতুন শংসাপত্রগুলি পেতে শুরু করবে৷ পরিবর্তনগুলি কিছুটা স্থানীয় করা হবে, কারণ ক্লায়েন্টের অনুরোধগুলি ভৌগলিকভাবে কাছাকাছি ডেটা সেন্টারের সার্ভারগুলিতে ফরোয়ার্ড করা হয়৷

যেহেতু আমরা নিশ্চিতভাবে আগে থেকে বলতে পারি না যে কে প্রভাবিত হবে, কখন এবং কোথায়, আমরা আমাদের সমস্ত গ্রাহকদের তাদের পরিষেবাগুলি ইতিমধ্যেই যাচাই এবং ভবিষ্যতে প্রমাণ করার পরামর্শ দিচ্ছি সম্ভাব্য Google রুট CA মাইগ্রেশন পর্যায়গুলির আগে।

আমার রুট সার্টিফিকেট স্টোরের অতিরিক্ত নির্দেশনার জন্য আপডেটের প্রয়োজন আছে কিনা তা কীভাবে যাচাই করবেন বিভাগটি দেখুন।

কি জন্য চক্ষু মেলিয়া

প্রয়োজনীয় রুট শংসাপত্রের সাথে কনফিগার করা হয়নি এমন ক্লায়েন্টরা Google মানচিত্র প্ল্যাটফর্মে তাদের TLS সংযোগ যাচাই করতে পারবে না। এই পরিস্থিতিতে, ক্লায়েন্টরা সাধারণত একটি সতর্কতা জারি করবে যে শংসাপত্রের বৈধতা ব্যর্থ হয়েছে।

তাদের TLS কনফিগারেশনের উপর নির্ভর করে, ক্লায়েন্টরা একটি Google মানচিত্র প্ল্যাটফর্ম অনুরোধ জারি করতে পারে , অথবা তারা অনুরোধটি চালিয়ে যেতে অস্বীকার করতে পারে।

Google মানচিত্র প্ল্যাটফর্মের সাথে যোগাযোগ করার জন্য একটি TLS ক্লায়েন্টের ন্যূনতম প্রয়োজনীয়তাগুলি কী কী?

Google মানচিত্র প্ল্যাটফর্মের শংসাপত্রগুলি DNS বিষয় বিকল্প নাম (SANs) নিয়োগ করে, তাই একটি ক্লায়েন্টের শংসাপত্র হ্যান্ডলিং অবশ্যই SAN সমর্থন করতে সক্ষম হতে হবে যাতে একটি ওয়াইল্ডকার্ড নামের মধ্যে বাম-সবচেয়ে লেবেল হিসাবে অন্তর্ভুক্ত থাকতে পারে, যেমন *.googleapis.com ।

অন্যান্য প্রয়োজনীয়তার জন্য, অনুগ্রহ করে বিভাগটি দেখুন একজন TLS ক্লায়েন্টের জন্য Google এর সাথে যোগাযোগের জন্য প্রস্তাবিত প্রয়োজনীয়তাগুলি কী কী? GTS FAQ- এ

কোন ধরণের অ্যাপ্লিকেশনগুলি ভাঙার ঝুঁকিতে রয়েছে?

অ্যাপ্লিকেশনটি কোনো বিকাশকারীর আরোপিত বিধিনিষেধ ছাড়াই সিস্টেম রুট সার্টিফিকেট স্টোর ব্যবহার করে

গুগল ম্যাপ প্ল্যাটফর্ম ওয়েব পরিষেবা অ্যাপ্লিকেশন

আপনি যদি একটি মূলধারার OS ব্যবহার করেন, যেমন, Ubuntu, Red Hat, Windows 10 বা Server 2019, OS X) যা এখনও রক্ষণাবেক্ষণ করা হয় এবং নিয়মিত আপডেট পায়, আপনার ডিফল্ট রুট সার্টিফিকেট স্টোরে ইতিমধ্যেই GTS Root R1 শংসাপত্র অন্তর্ভুক্ত করা উচিত।

আপনি যদি একটি লিগ্যাসি OS সংস্করণ ব্যবহার করেন যা আর আপডেট পায় না, তাহলে আপনার কাছে GTS Root R1 শংসাপত্র থাকতে পারে বা নাও থাকতে পারে। যাইহোক, আপনার রুট সার্টিফিকেট স্টোরে সম্ভবত GlobalSign Root CA - R1 থাকবে, যা প্রাচীনতম এবং সর্বাধিক বিশ্বস্ত রুট CAগুলির মধ্যে একটি৷

মোবাইল অ্যাপ্লিকেশানগুলির জন্য সরাসরি শেষ ব্যবহারকারীর ডিভাইস থেকে Google মানচিত্র প্ল্যাটফর্ম ওয়েব পরিষেবাগুলিতে কল করা, প্রশ্ন থেকে নির্দেশিকাগুলি মোবাইল অ্যাপগুলি কি ভাঙার ঝুঁকিতে রয়েছে? আবেদন

ক্লায়েন্ট-সাইড গুগল ম্যাপ প্ল্যাটফর্ম অ্যাপ্লিকেশন

Maps JavaScript API অ্যাপ্লিকেশনগুলি সাধারণত অ্যাপ্লিকেশন চালানো ওয়েব ব্রাউজারের রুট সার্টিফিকেটের উপর নির্ভর করে। বিভাগটি দেখুন জাভাস্ক্রিপ্ট অ্যাপ্লিকেশনগুলি কি ভাঙার ঝুঁকিতে রয়েছে? আরো বিস্তারিত জানার জন্য।

Android-এর জন্য Maps SDK, iOS-এর জন্য Maps SDK, Android-এর জন্য Places SDK বা iOS-এর জন্য Places SDK-এর যে কোনও একটি ব্যবহার করে স্থানীয় মোবাইল অ্যাপ্লিকেশানগুলির জন্য, Google Maps Platform ওয়েব পরিষেবাগুলিতে কল করা অ্যাপগুলির জন্য একই নিয়ম প্রযোজ্য৷

প্রশ্ন দেখুন মোবাইল অ্যাপস কি ভাঙার ঝুঁকিতে রয়েছে? আরো বিস্তারিত জানার জন্য.

অ্যাপটি তার নিজস্ব শংসাপত্র বান্ডিল ব্যবহার করে বা উন্নত নিরাপত্তা বৈশিষ্ট্য ব্যবহার করে, যেমন শংসাপত্র পিনিং

আপনার শংসাপত্রের বান্ডিল নিজেই আপডেট করা নিশ্চিত করতে হবে। প্রশ্নে আলোচনা করা হয়েছে কেন আমি আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখব? , আমরা আপনাকে বিশ্বস্ত Google রুট CA বান্ডেল থেকে সমস্ত শংসাপত্র আপনার নিজস্ব রুট শংসাপত্রের দোকানে আমদানি করার পরামর্শ দিই৷

যদি আপনি Google ডোমেনগুলির জন্য শংসাপত্র বা সর্বজনীন কীগুলি পিন করে থাকেন যেগুলির সাথে আপনার অ্যাপ্লিকেশন সংযোগ করে, আপনার আবেদনের বিশ্বস্ত সত্তার তালিকায় আপনার শংসাপত্র এবং সর্বজনীন কীগুলি যোগ করা উচিত৷

শংসাপত্র বা সর্বজনীন কী পিনিং সম্পর্কে আরও তথ্যের জন্য, প্রশ্নের অধীনে তালিকাভুক্ত বাহ্যিক সংস্থানগুলি পড়ুন আরও তথ্যের প্রয়োজন? .

কেন আমার রুট সার্টিফিকেট স্টোরকে বিশ্বস্ত Google রুট CA বান্ডেলের সাথে সিঙ্কে রাখতে হবে?

বিশ্বস্ত Google রুট CA বান্ডেলে রুট CA-এর কিউরেটেড তালিকায় এমন সমস্ত CA অন্তর্ভুক্ত রয়েছে যা সম্ভবত অদূর ভবিষ্যতে Google পরিষেবা দ্বারা ব্যবহার করা হতে পারে৷

অতএব, আপনি যদি ভবিষ্যতে আপনার সিস্টেমের প্রমাণ করতে চান, আমরা দৃঢ়ভাবে সুপারিশ করি যে আপনি যাচাই করুন যে আপনার রুট শংসাপত্রের দোকানে বান্ডেল থেকে সমস্ত শংসাপত্র রয়েছে এবং দুটিকে সিঙ্কে রাখার অভ্যাস করুন৷

এটি বিশেষভাবে গুরুত্বপূর্ণ যদি আপনার পরিষেবাগুলি একটি অপরিবর্তিত অপারেটিং সিস্টেম সংস্করণে চালিত হয়, আপনি অন্যান্য কারণে আপনার অপারেটিং সিস্টেম এবং লাইব্রেরিগুলি প্যাচ আপ রাখতে অক্ষম হন, অথবা আপনি নিজের রুট সার্টিফিকেট স্টোর বজায় রাখেন৷

প্রশ্ন দেখুন কিভাবে আমি ভবিষ্যতের মাইগ্রেশনের অগ্রিম বিজ্ঞপ্তি পেতে পারি? ভবিষ্যত রুট CA মাইগ্রেশন সম্পর্কে আপডেট কিভাবে পেতে হয় তা খুঁজে বের করতে। নিয়মিতভাবে আপনার রুট সার্টিফিকেট স্টোরকে কিউরেটেড তালিকার সাথে সিঙ্ক করে রাখলে তা CA পরিবর্তনের কারণে আপনার পরিষেবাগুলিকে ভবিষ্যত পরিষেবা বাধার বিরুদ্ধে রক্ষা করবে এবং GTS Root R1 Cross এবং GlobalSign Root CA - R1 উভয়ের মেয়াদ শেষ হওয়ার পরেও আপনার পরিষেবাগুলিকে চালু রাখবে।

এছাড়াও, অনুগ্রহ করে প্রশ্নটি পড়ুন যে আমি একটি পণ্য তৈরি করছি যা Google পরিষেবাগুলির সাথে সংযোগ করে৷ আমার কোন CA শংসাপত্রগুলি বিশ্বাস করতে হবে? আরও সুপারিশের জন্য GTS FAQ- এ।

কেন আমি কোনো পাতা বা মধ্যবর্তী CA সার্টিফিকেট ইনস্টল করব না?

এটি করার ফলে যে কোনো সময়ে আমরা একটি নতুন শংসাপত্র নথিভুক্ত করি, অথবা মধ্যবর্তী CAগুলি পরিবর্তন করি আপনার আবেদন ভঙ্গ করার ঝুঁকি থাকবে৷ যেকোনও সময়ে এবং কোনো পূর্ব বিজ্ঞপ্তি ছাড়াই এগুলির যে কোনো একটি ঘটতে পারে, এবং এটি পৃথক সার্ভার সার্টিফিকেটের ক্ষেত্রে সমানভাবে প্রযোজ্য, যেমন maps.googleapis.com দ্বারা পরিবেশিত , সেইসাথে আমাদের মধ্যবর্তী CA, যেমন GTS Root R1 Cross ।

এর বিরুদ্ধে আপনার পরিষেবাগুলিকে রক্ষা করার জন্য, আপনাকে শুধুমাত্র বিশ্বস্ত Google রুট CA বান্ডেল থেকে রুট শংসাপত্রগুলি ইনস্টল করতে হবে এবং এটিতে নোঙর করা সমগ্র শংসাপত্রের চেইনের বিশ্বস্ততা যাচাই করতে শুধুমাত্র রুট শংসাপত্রের উপর নির্ভর করতে হবে৷

যেকোনো আধুনিক TLS লাইব্রেরি বাস্তবায়ন স্বয়ংক্রিয়ভাবে এই ধরনের বিশ্বাসের চেইন যাচাই করতে সক্ষম হওয়া উচিত, যতক্ষণ না রুট সার্টিফিকেট কর্তৃপক্ষ বিশ্বস্ত থাকে।

জাভাস্ক্রিপ্ট অ্যাপ্লিকেশনগুলি কি ভাঙার ঝুঁকিতে রয়েছে?

GTS রুট শংসাপত্রগুলি ইতিমধ্যেই বেশিরভাগ আধুনিক ব্রাউজারগুলির দ্বারা ভালভাবে এম্বেড করা এবং বিশ্বস্ত, এবং GMO GlobalSign থেকে ক্রস-সাইনটি লিগ্যাসি ব্রাউজারগুলিতে বেশিরভাগ শেষ ব্যবহারকারীদের জন্যও একটি মসৃণ স্থানান্তর নিশ্চিত করতে হবে। এতে মানচিত্র জাভাস্ক্রিপ্ট API-এর জন্য সমস্ত আনুষ্ঠানিকভাবে সমর্থিত ব্রাউজার অন্তর্ভুক্ত রয়েছে।

প্রতিটি আধুনিক ব্রাউজারকে শেষ ব্যবহারকারীদের যাচাই করার অনুমতি দেওয়া উচিত এবং সাধারণত ব্রাউজারটি কোন সার্টিফিকেট বিশ্বাস করে তা সম্পাদনা করতে পারে। যদিও প্রতিটি ব্রাউজারের সাথে সঠিক অবস্থান আলাদা হয়, সার্টিফিকেটের তালিকা সাধারণত সেটিংসের অধীনে কোথাও পাওয়া যেতে পারে।

মোবাইল অ্যাপস কি ভাঙার ঝুঁকিতে রয়েছে?

অ্যান্ড্রয়েড এবং অ্যাপল আইওএস ডিভাইসগুলি এখনও ডিভাইস প্রস্তুতকারকের কাছ থেকে নিয়মিত আপডেট গ্রহণ করে ভবিষ্যতে প্রমাণ হবে বলে আশা করা হচ্ছে। বেশিরভাগ পুরানো অ্যান্ড্রয়েড ফোন মডেলের মধ্যে অন্তত GlobalSign Root CA - R1 সার্টিফিকেট অন্তর্ভুক্ত থাকে, যদিও বিশ্বস্ত সার্টিফিকেটের তালিকা হ্যান্ডসেট প্রস্তুতকারক, ডিভাইস মডেল এবং অ্যান্ড্রয়েড সংস্করণ অনুসারে পরিবর্তিত হতে পারে।

যাইহোক, GTS রুট R1 সহ GTS রুট CA-এর জন্য সমর্থন এখনও 10-এর আগে Android সংস্করণগুলিতে সীমিত হতে পারে।

iOS ডিভাইসগুলির জন্য, Apple তার সমর্থন পৃষ্ঠাগুলিতে প্রতিটি সাম্প্রতিক iOS সংস্করণের জন্য বিশ্বস্ত রুট CA-এর একটি তালিকা বজায় রাখে। যাইহোক, সমস্ত iOS সংস্করণ 5 এবং পরবর্তীতে GlobalSign Root CA - R1 সমর্থন করে।

GTS রুট CA, GTS Root R1 সহ iOS সংস্করণ 12.1.3 থেকে সমর্থিত।

প্রশ্ন দেখুন কিভাবে আমি আমার মোবাইল ফোনে বিশ্বস্ত রুট সার্টিফিকেট চেক করতে পারি? বিস্তারি তথ্যের জন্য.

আমার ব্রাউজার বা অপারেটিং সিস্টেম কখন Google Trust Services রুট সার্টিফিকেট অন্তর্ভুক্ত করবে?

Google বিগত বছরগুলিতে ব্যাপকভাবে ব্যবহৃত এবং বিশ্বস্ত রুট শংসাপত্র বান্ডেলগুলি বজায় রেখে সমস্ত প্রধান তৃতীয় পক্ষের সাথে ব্যাপকভাবে কাজ করেছে। উদাহরণগুলির মধ্যে রয়েছে অপারেটিং সিস্টেম নির্মাতা, যেমন অ্যাপল এবং মাইক্রোসফ্ট, কিন্তু এছাড়াও গুগলের নিজস্ব অ্যান্ড্রয়েড এবং ক্রোম ওএস টিম; ব্রাউজার ডেভেলপার, যেমন Mozilla, Apple, Microsoft, কিন্তু Google এর নিজস্ব Chrome টিম; হার্ডওয়্যার নির্মাতারা, যেমন ফোন, সেট-টপ বক্স, টিভি, গেম কনসোল, প্রিন্টার, শুধুমাত্র কয়েকটি নাম।

তাই খুব সম্ভবত যে কোনো বর্তমানে রক্ষণাবেক্ষণ করা সিস্টেম ইতিমধ্যেই GTS Root R1 সহ Google-এর নতুন GTS Root CAগুলিকে সমর্থন করে এবং এমনকি লিগ্যাসি সিস্টেমগুলিকে GlobalSign Root CA - R1 সমর্থন করার সম্ভাবনা বেশি, যেটি ক্রস-সাইনিং Google-ইস্যু করা শংসাপত্রের জন্য ব্যবহার করা হবে। পরবর্তী বছরগুলির মাধ্যমে।

যাইহোক, যেহেতু তৃতীয় পক্ষের শংসাপত্র অন্তর্ভুক্তির টাইমলাইনগুলি মূলত Google-এর নিয়ন্ত্রণের বাইরে, তাই সর্বোত্তম সাধারণ উপদেশ আমরা দিতে পারি তা হল আপনি নিয়মিত উপলব্ধ সিস্টেম আপডেটগুলি প্রয়োগ করছেন তা নিশ্চিত করা৷

তৃতীয় পক্ষ নির্বাচন করুন, যেমন Mozilla's CA সার্টিফিকেট প্রোগ্রাম তাদের নিজস্ব শংসাপত্র অন্তর্ভুক্তির সময়রেখা নথিভুক্ত করতে পারে।

সমস্যা সমাধান

আমি আমার প্রয়োজনীয় সরঞ্জামগুলি কোথায় পেতে পারি?

কার্ল হচ্ছে

যদি আপনার OS ডিস্ট্রিবিউশন curl প্রদান না করে, আপনি এটি https://curl.haxx.se/ থেকে ডাউনলোড করতে পারেন। আপনি হয় উৎসটি ডাউনলোড করতে পারেন এবং নিজেই টুলটি কম্পাইল করতে পারেন অথবা আপনার প্ল্যাটফর্মের জন্য উপলব্ধ থাকলে একটি প্রাক-সংকলিত বাইনারি ডাউনলোড করতে পারেন।

OpenSSL পাচ্ছেন

যদি আপনার OS ডিস্ট্রিবিউশন openssl প্রদান না করে, আপনি https://www.openssl.org/ থেকে উৎসটি ডাউনলোড করতে পারেন এবং টুলটি কম্পাইল করতে পারেন। 3য় পক্ষ দ্বারা তৈরি বাইনারিগুলির একটি তালিকা https://www.openssl.org/community/binaries.html এর মাধ্যমে পাওয়া যাবে। যাইহোক, এই বিল্ডগুলির কোনটিই সমর্থিত নয় বা কোন নির্দিষ্ট উপায়ে OpenSSL টিম দ্বারা অনুমোদিত নয়।

Wireshark, Tshark বা Tcpdump পাওয়া

যদিও বেশিরভাগ লিনাক্স ডিস্ট্রিবিউশন wireshark অফার করে, এর কমান্ড-লাইন টুল tshark এবং tcpdump , অন্যান্য OS-এর জন্য প্রথম দুটির প্রাক-সংকলিত সংস্করণ https://www.wireshark.org- এ পাওয়া যাবে।

Tcpdump এবং LibPCAP-এর সোর্স কোড https://www.tcpdump.org- এ পাওয়া যাবে।

এই দরকারী টুলগুলির জন্য ডকুমেন্টেশন পাওয়া যাবে Wireshark ব্যবহারকারীর নির্দেশিকাতে , যথাক্রমে Tshark ম্যান পেজে এবং Tcpdump ম্যান পেজে ।

জাভা কীটুল পাওয়া যাচ্ছে

keytool কমান্ড লাইন টুলটি প্রতিটি জাভা ডেভেলপমেন্ট কিট (জেডিকে) বা জাভা রানটাইম এনভায়রনমেন্ট (জেআরই) সংস্করণের সাথে পাঠানো উচিত। keytool. যাইহোক, মূল শংসাপত্র যাচাইকরণের জন্য keytool ব্যবহার করা অসম্ভব, যদি না আপনার অ্যাপ্লিকেশন জাভা ব্যবহার করে তৈরি করা হয়।

একটি উত্পাদন বিভ্রাটে কি করতে হবে

আপনার জন্য প্রাথমিক পদক্ষেপ হল বিশ্বস্ত Google রুট CA বান্ডেল থেকে প্রয়োজনীয় রুট শংসাপত্রগুলি আপনার অ্যাপ্লিকেশন ব্যবহার করে রুট সার্টিফিকেট স্টোরে ইনস্টল করা।

  1. আপনার স্থানীয় রুট সার্টিফিকেট স্টোর আপগ্রেড করতে আপনার সিস্টেম অ্যাডমিনিস্ট্রেটরদের সাথে একসাথে কাজ করুন।
  2. আপনার সিস্টেমে প্রযোজ্য পয়েন্টারগুলির জন্য এই FAQ চেক করুন।
  3. আপনার যদি আরও প্ল্যাটফর্ম- বা সিস্টেম-নির্দিষ্ট সহায়তার প্রয়োজন হয়, আপনার সিস্টেম প্রদানকারীর দ্বারা অফার করা প্রযুক্তিগত সহায়তা চ্যানেলগুলির সাথে যোগাযোগ করুন।
  4. সাধারণ সহায়তার জন্য, আমাদের সহায়তা টিমের সাথে যোগাযোগ করুন, যেমনটি Google Maps প্ল্যাটফর্ম সমর্থনে পৌঁছানো বিভাগে বর্ণিত হয়েছে। দ্রষ্টব্য: প্ল্যাটফর্ম-নির্দিষ্ট সমস্যাগুলির জন্য, নির্দেশিকা শুধুমাত্র সর্বোত্তম প্রচেষ্টার ভিত্তিতে প্রদান করা হয়।
  5. আরও মাইগ্রেশন সম্পর্কিত আপডেটের জন্য স্টার পাবলিক ইস্যু 186840968 ।

Google Maps প্ল্যাটফর্ম সমর্থনে পৌঁছানো

প্রাথমিক সমস্যা সমাধান

জেনেরিক সমস্যা সমাধানের নির্দেশাবলীর জন্য আমার রুট সার্টিফিকেট স্টোরের একটি আপডেটের প্রয়োজন কিনা তা কীভাবে যাচাই করবেন বিভাগটি দেখুন।

আপনার যদি রুট সার্টিফিকেট আমদানি বা রপ্তানি করার প্রয়োজন হয় তবে আপনার বিশ্বস্ত শংসাপত্রগুলি পরিচালনা করা বিভাগ মূল্যবান তথ্য সরবরাহ করতে পারে।

যদি সমস্যাটির সমাধান না হয়, এবং আপনি Google মানচিত্র প্ল্যাটফর্ম সহায়তার সাথে যোগাযোগ করার সিদ্ধান্ত নেন, তাহলে নিম্নলিখিত তথ্য প্রদান করতে প্রস্তুত থাকুন:

  1. আপনার প্রভাবিত সার্ভার কোথায় অবস্থিত?
  2. কোন Google IP ঠিকানাগুলি আপনার পরিষেবা কল করছে?
  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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

প্রয়োজনীয় সরঞ্জামগুলি পাওয়ার নির্দেশাবলীর জন্য, প্রশ্ন দেখুন আমার প্রয়োজনীয় সরঞ্জামগুলি কোথায় পেতে পারি? .

একটি সমর্থন মামলা দায়ের

Google মানচিত্র প্ল্যাটফর্ম সমর্থন এবং সম্পদের অধীনে একটি সমর্থন কেস তৈরি করার জন্য অনুগ্রহ করে নির্দেশাবলী অনুসরণ করুন৷

একটি সমর্থন মামলা দায়ের করার সময়, প্রাথমিক সমস্যা সমাধান বিভাগে তালিকাভুক্ত ডেটা ছাড়াও, অনুগ্রহ করে নিম্নলিখিতগুলিও প্রদান করুন:

  • আপনার পাবলিক আইপি ঠিকানা কি?
  • আপনার DNS সার্ভারের সর্বজনীন আইপি ঠিকানা কি?
  • যদি সম্ভব হয়, একটি tcpdump বা Wireshark প্যাকেট ক্যাপচার করা ব্যর্থ TLS আলোচনার জন্য PCAP ফরম্যাটে https://maps.googleapis.com/ , একটি যথেষ্ট বড় স্ন্যাপশট-দৈর্ঘ্য ব্যবহার করে পুরো প্যাকেটটি ছাঁটাই না করে ক্যাপচার করা (যেমন -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

কিভাবে কার্ল আউটপুট ব্যাখ্যা

-vvI পতাকা সহ curl চালানো অনেক দরকারী তথ্য প্রদান করে। আউটপুট ব্যাখ্যা করার জন্য এখানে কয়েকটি নির্দেশাবলী রয়েছে:

  • ' * ' দিয়ে শুরু হওয়া লাইনগুলি TLS আলোচনা থেকে আউটপুট প্রদর্শন করে, সেইসাথে সংযোগ সমাপ্তির তথ্য।
  • ' > ' দিয়ে শুরু হওয়া লাইনগুলি curl পাঠানো বহির্গামী HTTP অনুরোধ প্রদর্শন করে।
  • ' < ' দিয়ে শুরু হওয়া লাইনগুলি সার্ভার থেকে পাওয়া HTTP প্রতিক্রিয়া প্রদর্শন করে।
  • প্রোটোকলটি HTTPS হলে, ' > ' বা ' < ' লাইনের উপস্থিতি একটি সফল TLS হ্যান্ডশেক বোঝায়।

Used TLS library and root certificate bundle

Running curl with the -vvI flags also prints out the used root certificates store, but the exact output may vary per system as shown here.

Output from a Red Hat Linux machine with curl linked against NSS may contain these lines:

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

Output from an Ubuntu or Debian Linux machine may contain these lines:

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

Output from an Ubuntu or Debian Linux machine using the Google root certificate PEM file given using the --cacert flag may contain these lines:

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

User agent

Outgoing requests contain the User-Agent header, which may provide useful information about curl and your system.

An example from a Red Hat Linux machine:

> 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: */*
>

Failed TLS handshake

Lines, such as the ones in this code sample, indicate the connection was terminated mid-TLS-handshake because of an untrusted server certificate. The absence of debug output starting with > or < are also strong indicators of an unsuccessful connection attempt:

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

Successful TLS handshake

A successful TLS handshake is indicated by the presence of similar looking lines to the ones in this code sample. The cipher suite used for the encrypted connection should be listed, as should details of the accepted server certificate. Furthermore, the presence of lines starting with > or < indicate that payload HTTP traffic is being successfully transmitted over the TLS encrypted connection:

*   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
…

How to print the received server certificates in human readable form

Presuming the output is PEM formatted, eg the output from openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null , you can print out the served certificate following these steps:

  • Copy the entire Base 64 encoded certificate, including header and footer:

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

  • Then do:

    openssl x509 -inform pem -noout -text
````

  • Then paste the contents of your copy buffer into the terminal.

  • Hit the Return key.

For example input and output, see section How to print PEM certificates in human readable form .

What do cross-signed Google certificates look like in OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.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.demo.pki.goog

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

---
…

Managing your trusted certificates

How can I check the trusted root certificates on my mobile phone?

Android trusted certificates

As mentioned under question Are mobile apps at risk of breaking? , Android has since version 4.0 allowed handset users to verify the list of trusted certificates under Settings . This table shows the exact Settings menu path:

Android version Menu path
1.x, 2.x, 3.x N/A
4.x, 5.x, 6.x, 7.x Settings > Security > Trusted credentials
8.x, 9 Settings > Security & Location > Encryption & credentials > Trusted credentials
10+ Settings > Security > Advanced > Encryption & credentials > Trusted credentials

This table illustrates the likely availability of the most critical root certificates per Android version, based on manual verification using currently available Android Virtual Device (AVD) system images, falling back to the AOSP ca-certificates Git repository version history, where system images were no longer available:

Android version GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valid until Dec 15, 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Updating the Android system root certificates store is generally not possible without a firmware update or rooting the device. However, on most Android versions that are still in wide use, the current set of trusted root certificates is likely to provide uninterrupted service for multiple years to come, beyond the effective lifetime of most currently existing devices.

Beginning with version 7.0, Android offers application developers a secure method for adding trusted certificates which are only trusted by their application. This is done by bundling the certificates with the application and creating a custom network security configuration, as described in the Android Best Practices for Security & Privacy Network Security Configuration training document.

However, as third-party application developers will not be able to influence the network security configuration of traffic originating from the Google Play Services APK , such efforts would likely only provide a partial workaround.

On older legacy devices, your only available option would be to rely on user-added CAs, either installed by a corporate group policy applied to the end user device, or by the end users themselves.

iOS Trust Store

While Apple does not directly show its default set of trusted root certificates to the handset user, the company has links to the sets of trusted root CAs for iOS versions 5 and up from the Apple Support articles:

However, any additional certificates installed on the iOS device should be visible under Settings > General > Profile . If no additional certificates are installed, the Profile menu item may not be displayed.

This table illustrates the availability of the most critical root certificates per iOS version, based on the above sources:

iOS version GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (valid until Dec 15, 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Where is my system root certificates store and how can I update it?

The location of the default root certificates store varies with operating system and used SSL/TLS library. However, on most Linux distributions, the default root certificates can be found under one of the following paths:

  • /usr/local/share/ca-certificates : Debian, Ubuntu, older RHEL and CentOS versions
  • /etc/pki/ca-trust/source/anchors and /usr/share/pki/ca-trust-source : Fedora, newer RHEL and CentOS versions
  • /var/lib/ca-certificates : OpenSUSE

Other certificate paths may include:

  • /etc/ssl/certs : Debian, Ubuntu
  • /etc/pki/tls/certs : RHEL, CentOS

Some of the certificates in these directories are likely symbolic links to files in other directories.

OpenSSL root certificates store

For applications using OpenSSL , you can check the configured location of its installed components, including the default root certificates store using the following command:

openssl version -d

The command prints out OPENSSLDIR , which corresponds to the top level directory the library and its configurations can be found under:

OPENSSLDIR: "/usr/lib/ssl"

The root certificates store is located in the certs subdirectory.

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
…

If OpenSSL relies on the default system root certificates store as in the example above, check the top-level section Where is my system root certificates store and how can I update it? to ensure the system root certificate bundle is up to date.

For instructions getting openssl , see section Getting OpenSSL .

Java root certificates store

Java applications might use their own root certificates store, which on Linux systems is typically located at /etc/pki/java/cacerts or /usr/share/ca-certificates-java , which can be managed using the Java keytool command-line tool.

To import an individual certificate into your Java certificate store, issue the following command:

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

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, alias with a unique but meaningful certificate alias, and certs.jks with the certificate database file used in your environment.

For further information, please refer to the following Oracle and Stack Overflow articles:

Mozilla NSS root certificates store

Applications using Mozilla NSS may by default also use a system-wide certificate database typically located under /etc/pki/nssdb , or a user-specific default store under ${HOME}/.pki/nssdb .

For updating your NSS database, use the certutil tool.

To import an individual certificate file into your NSS database, issue the following command:

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

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, cert-name with a meaningful certificate nickname, and certdir with the certificate database path used in your environment.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

Microsoft .NET root certificates store

Windows .NET developers may find at least the following Microsoft articles useful for updating their root certificates store:

Certificate file formats

What is a PEM file?

Privacy-Enhanced Mail (PEM) is a de-facto standard textual file format for storing and sending cryptographic certificates, keys, etc., formalized as a de-jure standard in RFC 7468 .

While the file format itself is human readable, the Base64 encoded binary certificate data information is not. However, the PEM specification permits emitting explanatory text either before or after the text encoded certificate body, and many tools use this feature to also provide a clear-text summary of the most relevant data elements in a certificate.

Tools, such as openssl can also be used to decode the entire certificate into human-readable form. See section How to print PEM certificates in human readable form for more info.

What is a ".crt" file?

Tools that allow exporting of certificates in PEM format commonly use the file extension ".crt" to indicate the file uses a textual encoding.

What is a DER file?

Distinguished Encoding Rules (DER) is a standardized binary format for encoding certificates. Certificates in PEM files are typically Base64 encoded DER certificates.

What is a ".cer" file?

An exported file with a ".cer" suffix may contain a PEM-encoded certificate, but more typically a binary, usually DER-encoded certificate. By convention , ".cer" files generally only contain a single certificate.

My system refuses to import all certificates from roots.pem

Some systems, eg, Java keytool , may only import a single certificate from a PEM file, even if it contains several. See question How do I extract individual certificates from roots.pem? to see how the file can first be split up.

How do I extract individual certificates from roots.pem?

You can split up roots.pem into its component certificates using the following simple bash script:

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

This should create a number of individual PEM files similar to the ones listed here:

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

The individual PEM files, such as 02265526.pem can then be imported separately, or further converted into a file format your certificate store accepts.

How to convert between a PEM file and a format supported by my system

The OpenSSL toolkit command-line tool openssl can be used to convert files between all commonly used certificate file formats. Instructions for converting from a PEM file to most commonly used certificate file formats are listed below.

For a full list of available options, check the official OpenSSL Command Line Utilities documentation .

For instructions getting openssl , see section Getting OpenSSL .

How do I convert a PEM file to DER format?

Using openssl you can issue the following command to convert a file from PEM to DER:

openssl x509 -in roots.pem -outform der -out roots.der
How do I convert a PEM file to PKCS #7?

Using openssl you can issue the following command to convert a file from PEM to PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
How do I convert a PEM file to PKCS #12 (PFX)?

Using openssl you can issue the following command to convert a file from PEM to PKCS #12:

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

You need to provide a file password when creating a PKCS #12 archive. Make sure to store the password somewhere safe, if you don't immediately import the PKCS #12 file into your system.

Listing, printing and exporting certificates from your root certificates store

How do I export a certificate from the Java Key Store as a PEM file?

Using keytool you can issue the following command to list all certificates in your certificate store, together with the alias you can use to export each one:

keytool -v -list -keystore certs.jks

Just replace certs.jks with the certificate database file used in your environment. This command will also show the alias of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

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

Just replace certs.jks with the certificate database file used in your environment, and provide an alias and alias.pem corresponding to the certificate you wish to export.

For further information, please refer to the Java Platform, Standard Edition Tools Reference: keytool manual.

How do I export certificates from the NSS root certificates store as a PEM file?

Using certutil you can issue the following command to list all certificates in your certificate store, together with the nickname you can use to export each one:

certutil -L -d certdir

Just replace certdir with the certificate database path used in your environment. This command will also show the nickname of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

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

Just replace certdir with the certificate database path used in your environment, and provide a cert-name and cert.pem corresponding to the certificate you wish to export.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

How to print PEM certificates in human readable form

In the following examples we presume you have the file GTS_Root_R1.pem with the following contents:

# 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-----
Printing certificate files using OpenSSL

Issuing the command

openssl x509 -in GTS_Root_R1.pem -text

should output something similar to:

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
        …

For instructions getting openssl , see section Getting OpenSSL .

Printing certificates using Java keytool

Issuing the following command

keytool -printcert -file GTS_Root_R1.pem

should output something similar to:

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>
]
]

For instructions getting keytool , see section Getting Java keytool .

How do I see what certificates are installed in my root certificates store?

This varies per operating system and SSL/TLS library. However, the tools that allows importing and exporting certificates to and from the root certificates store typically also provide an option to list the installed certificates.

Also, if you have successfully exported the trusted root certificates into PEM files, or your root certificates store already contains stored PEM files, you can try opening the files in any text editor, as it is a plain text file format.

The PEM file may be properly labeled, providing human readable information of the associated certificate authority (example from the trusted Google root CA bundle ):

# 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-----

The file may also just contain the certificate part. In such cases, the name of the file, such as GTS_Root_R1.pem may describe which CA the certificate belongs to. The certificate string between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tokens is also guaranteed to be unique for each CA.

However, even if you lack the above tools, as each certificate in the trusted Google root CA bundle is properly labeled, you can reliably match the root CAs from the bundle aganist the ones from your root certificates store either by Issuer , or by comparing PEM file certificate strings.

Web browsers may use their own root certificates store, or rely on the default one provided by the operating. However, all modern browsers should allow you to manage or at least view the set of root CAs they trust. See question Are JavaScript applications at risk of breaking? for further details.

For mobile phone specific instructions, see the separate question How can I check the trusted root certificates on my mobile phone? .

Appendix

Need more info?

Always rely primarily on your operating system documentation, the documentation of your application programming language(s), as well as the documentation from any external libraries that your application is using.

Any other source of information including this FAQ may be outdated or otherwise incorrect, and should not be taken as authoritative. However, you may still find useful information on many of the Stack Exchange Q&A communities , as well as sites such as AdamW on Linux and more and the confirm blog , among others.

Please also check out the Google Trust Services FAQ .

For further details about advanced topics, such as certificate pinning, you may find the Open Web Application Security Project (OWASP) Certificate and Public Key Pinning article and Pinning Cheat Sheet informative. For Android specific instructions, please refer to the official Android Best Practices for Security & Privacy Security with HTTPS and SSL training document. For discussion about certificate vs. public key pinning on Android, you may find Matthew Dolan's blog post Android Security: SSL Pinning useful.

The Android Best Practices for Security & Privacy Network Security Configuration training document and JeroenHD's blog post Android 7 Nougat and certificate authorities provide further information about managing additional trusted certificates on Android.

For a comprehensive list of root CAs trusted by AOSP, refer to the ca-certificates Git repository. For any versions based on unofficial Android forks, eg LineageOS, refer to the appropriate repositories provided by the OS vendor.