# Webship-এ TLS সার্টিফিকেটসমূহ: এমবেডেড ACME CA
একটি TLS সার্টিফিকেট দুইটি কাজ করে: এটি একটি সংযোগকে এনক্রিপ্ট করতে সাহায্য করে এবং ক্লায়েন্টকে জানায় যে এটি কোন পরিচয়ের সঙ্গে কথা বলছে। এনক্রিপশন শক্তিশালী হতে পারে যেকোনো সময়ে, কিন্তু বিশ্বাসের সিদ্ধান্ত দর্শকের জন্য ভুল হতে পারে। এজন্য সার্টিফিকেট অটোমেশন শুরু করতে হবে একটি প্রশ্ন দিয়ে: কে এই সাইটটিকে বিশ্বাস করতে হবে?
Webship 1.4.0 প্রতিটি কনফিগার্ড সাইটের জন্য স্বতন্ত্রভাবে সেই পছন্দটি করে। একটি পাবলিক ওয়েবসাইট ব্রাউজার-ট্রাস্টেড ACME সার্টিফিকেট ব্যবহার করতে পারে, একটি অভ্যন্তরীণ সেবা Webship’এর এমবেডেড প্রাইভেট সার্টিফিকেট অথরিটি ব্যবহার করতে পারে, এবং একটি সাইট যা বিদ্যমান PKI রয়েছে তা অপারেটর-ম্যানেজড সার্টিফিকেট ফাইল রাখতে পারে। তারা সবাই একটি Webship প্রক্রিয়া ভাগ করে নিতে পারে, কিন্তু একই প্রাইভেট কী বা একই ট্রাস্ট বাউন্ডারি ভাগ করতে হবে না।
চারটি স্বয়ংক্রিয় সার্টিফিকেট মোড, সাইট অনুযায়ী নির্বাচন করা
certificate_mode ক্ষেত্রটি প্রতিটি [[sites]] এন্ট্রির সাথে সম্পর্কিত। এটি একটি গ্লোবাল সুইচ নয়।
| মোড | ট্রাস্ট সোর্স | সেরা ফিট | ভ্যালিডেশন পাথ | | --- | --- | --- | --- | | per_site | পাবলিক ব্রাউজার এবং অপারেটিং-সিস্টেম ট্রাস্ট স্টোর | একটি পাবলিক সাইট একটি নির্দিষ্ট হোস্টনেম সহ | পাবলিক ACME TLS-ALPN-01 সহ | | ফ্লিট | পাবলিক ব্রাউজার এবং অপারেটিং-সিস্টেম ভরসাযোগ্য স্টোর | স্পষ্টভাবে নিবন্ধিত ডোমেইনের অধীনে তৃতীয় ও চতুর্থ স্তরের নামের বড় সেট | DNS-01 সহ পাবলিক ACME এবং স্থিতিশীল সার্টিফিকেট শার্ড | | এমবেডেড | অপারেটরের দ্বারা ইনস্টল করা একটি ব্যক্তিগত Webship রুট | অভ্যন্তরীণ সেবা, পরিচালিত ডিভাইস, ব্যক্তিগত ফ্লিট, এবং পরীক্ষামূলক পরিবেশ | প্রক্রিয়ার মধ্যে ইস্যু; কোনো বাহ্যিক চ্যালেঞ্জ নেই | | ভাগ করা | পাবলিক ব্রাউজার এবং অপারেটিং-সিস্টেম ট্রাস্ট স্টোর | লিগ্যাসি ডিপ্লয়মেন্ট যা ইচ্ছাকৃতভাবে একটি পাবলিক মাল্টি-SAN গ্রুপ ব্যবহার করে | পাবলিক ACME TLS-ALPN-01 সহ |
ডিফল্ট হলো per_site। এটি সাইটের সঠিক নামের জন্য একটি পাবলিক সার্টিফিকেট অর্ডার করে। ফ্লিট মোড হলো অনেক গভীর সাবডোমেইনের জন্য স্কেলেবল পাবলিক অপশন। এমবেডেড মোড Webship এর প্রাইভেট ইন-প্রসেস CA ব্যবহার করে। শেয়ারড মোড সামঞ্জস্যের জন্য উপলব্ধ থাকে, কিন্তু এটি ডিফল্ট নয়।
[sites.tls]-এর অধীনে একটি সম্পূর্ণ সার্টিফিকেট এবং কী সর্বদা ওই সাইটের স্বয়ংক্রিয় ইস্যুর উপরে প্রাধান্য পায়।
“এম্বেডেড ACME CA” মানে কী
কনফিগারেশন সেকশনটির নাম [acme_ca], কিন্তু এমবেডেড CA কোনও পাবলিক বা নেটওয়ার্ক-অ্যাক্সেসযোগ্য ACME সার্ভিস নয়। এটি কোনও ডিরেক্টরি এন্ডপয়েন্ট প্রকাশ করে না, কোনও রিমোট এনরোলমেন্ট গ্রহণ করে না, কোনও রেজিস্ট্রার API কল করে না, এবং কোনও প্রুফ-অফ-কন্ট্রোল চ্যালেঞ্জ সম্পাদন করে না।
পরিবর্তে, Webship পুরো ব্যক্তিগত ইস্যু প্রক্রিয়াটি একটিমাত্র প্রক্রিয়ায় রাখে:
- সাইটটি certificate_mode = "embedded" নির্বাচন করে।
- Webship কনফিগার করা স্টেট ডিরেক্টরিতে ব্যক্তিগত রুট পরিচয় লোড করে বা তৈরি করে।
- Webship সাইটটির জন্য একটি নতুন প্রাইভেট কী তৈরি করে।
- এম্বেডেড মূলটি সেই সঠিক নামের জন্য একটি পাতার সার্টিফিকেট সই করে।
- Webship লাইভ TLS রেজলভারে এটি ইনস্টল করার আগে সম্পূর্ণ পরিচয় যাচাই করে।
- তারপর সার্টিফিকেটটি সেই সাইটের প্রতিটি সক্রিয় প্রটোকলের জন্য উপলব্ধ হয়।
একটি ACME-শৈলীর নেটওয়ার্ক চ্যালেঞ্জ শুধুমাত্র Webship-কে নিজেই প্রমাণ করতে সক্ষম হবে, তাই এমবেড করা পথটির কোন নেটওয়ার্ক প্রোটোকল deliberately নেই। [acme_ca] সেকশনটি ব্যক্তিগত PKI স্টেট: এটি সংজ্ঞায়িত করে কোথায় root থাকে এবং ইস্যুকৃত leaf সার্টিফিকেট কত সময় বৈধ থাকে।
একটি সাইটের জন্য এম্বেডেড সার্টিফিকেট কনফিগার করুন
এটি একটি ব্যক্তিগত সাইটের জন্য ন্যূনতম আকার:
~~~টমল listen = "0.0.0.0:443"
[টিএলএস] unknown_sni = "প্রত্যাখ্যান"
[স্বয়ংক্রিয়_tls] সক্ষম = সত্য cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" পাতার_প্রযোজ্যতা_দিন = ৯০
[[সাইটগুলি]] ডোমেইন = "service.internal.example" মূল = "/srv/service" certificate_mode = "এম্বেডেড"
[সাইট.প্রোটোকল] h1 = সত্য h2 = সত্য h3 = সত্য ~~~
মূল সনাক্তকরণটি আলস্যে তৈরি করা হয় যখন একটি এমবেডেড সাইট প্রথমে এটি প্রয়োজন। Webship state_dir-এ সীমাবদ্ধ অনুমতির সঙ্গে মূল কী সংরক্ষণ করে। মূল সার্টিফিকেটের আয়ু দশ বছর; লিফ আয়ু leaf_validity_days দ্বারা নিয়ন্ত্রিত হয়।
উভয় সংরক্ষণ স্থলকেই উৎপাদন অবস্থার মতো বিবেচনা করুন:
- ACME ক্যাশে স্বয়ংক্রিয়ভাবে পরিচালিত সাইট পরিচয় ধারণ করে।
- এম্বেডেড-সিএ স্টেট ডিরেক্টরি প্রাইভেট রুট পরিচয় ধারণ করে।
- সার্ভিস অ্যাকাউন্টের অ্যাক্সেস প্রয়োজন, কিন্তু অ্যাপ্লিকেশন ব্যবহারকারীদের নয়।
- ব্যাকআপের সময় গোপনীয়তা এবং ফাইলের অনুমতি রক্ষা করা উচিত।
- উৎপাদন, উন্নয়ন, এবং পরীক্ষার জন্য আলাদা রুট এবং আলাদা ডিরেক্টরি ব্যবহার করা উচিত।
মূল ডিরেক্টরি মুছে ফেলার মানে “TLS রিসেট করা” নয়। এটি একটি নতুন ট্রাস্ট অ্যাঙ্কর তৈরি করে। পুরনো মূলকে বিশ্বাসকারী ক্লায়েন্টরা প্রতিস্থাপনের দ্বারা ইস্যুকৃত সার্টিফিকেটগুলো প্রত্যাখ্যান করবে যতক্ষণ না তাদের ট্রাস্ট স্টোর আপডেট হয়।
ব্যক্তিগত ট্রাস্ট ইচ্ছাকৃত
এম্বেডেড CA থেকে প্রাপ্ত সার্টিফিকেটগুলি স্বয়ংক্রিয়ভাবে পাবলিক ব্রাউজার বা অপারেটিং সিস্টেম দ্বারা বিশ্বাসযোগ্য হয় না। এগুলি কেবল তখনই বিশ্বাসযোগ্য হয় যখন অপারেটর ক্লায়েন্টের ট্রাস্ট স্টোরে রপ্তানি করা Webship রুট সার্টিফিকেট ইনস্টল করে।
এটি এমবেডেড মোডকে এর জন্য উপযুক্ত করে তোলে:
- কোম্পানি-পরিচালিত ল্যাপটপ এবং ফোন যেগুলি ডিভাইস ব্যবস্থাপনার মাধ্যমে নিবন্দন করা হয়েছে;
- সুস্পষ্ট CA বন্ডেলের সাথে অভ্যন্তরীণ সার্ভিস-টু-সার্ভিস ট্রাফিক;
- বেসরকারি যন্ত্রপাতি এবং নিয়ন্ত্রিত এজ ফ্লিট;
- উন্নয়ন এবং পরীক্ষা পরিবেশ যা আসল TLS আচরণ প্রয়োগ করতে হবে;
- সংশ্লিষ্ট নয় এমন নেটওয়ার্ক যা একটি পাবলিক CA-র ওপর নির্ভর করতে পারে না।
এটি একটি সাধারণ পাবলিক ওয়েবসাইটের জন্য সঠিক মোড নয় যার দর্শকরা অপ্রশাসিত ব্রাউজার ব্যবহার করে। একটি নির্দিষ্ট পাবলিক নামের জন্য পাবলিক পার_সাইট ইস্যু ব্যবহার করুন, বড় পাবলিক সাবডোমেইন সেটের জন্য ফ্লিট ইস্যু ব্যবহার করুন, শুধুমাত্র ইচ্ছাকৃত লেগেসি মাল্টি-এসএএন ডিপ্লয়মেন্টের জন্য শেয়ার করা ব্যবহার করুন, বা ইতিমধ্যেই বিশ্বাসযোগ্য পিকেআই থেকে ম্যানুয়াল ফাইল ব্যবহার করুন।
শুধুমাত্র মূল সার্টিফিকেটটি ক্লায়েন্টদের মধ্যে বিতরণ করুন। কখনও মূল ব্যক্তিগত কী বিতরণ করবেন না। সেই কীর অধিকার থাকা মানে হলো যে কেউ সমস্ত নিবন্ধিত ক্লায়েন্টের দ্বারা বিশ্বাসযোগ্য পরিচয় জারির ক্ষমতা রাখে।
পাবলিক এবং প্রাইভেট সার্টিফিকেট একত্রে থাকতে পারে
Webship 1.4.0 একই লিসেনারে সার্টিফিকেট কৌশল মিশ্রণ করতে পারে:
~~~টমল listen = "0.0.0.0:443"
[টিএলএস] unknown_sni = "প্রত্যাখ্যান"
[স্বয়ংক্রিয়_tls] সক্ষম = সত্য directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] সেবার শর্তাবলী_মেনে_নেবেন = সত্য
[acme_ca] state_dir = "/var/lib/webship/acme-ca" পাতার_প্রযোজ্যতা_দিন = ৯০
[[সাইটগুলি]] ডোমেইন = "www.example.com" মূল = "/srv/public" certificate_mode = "প্রতি_সাইট"
[[সাইটগুলি]] ডোমেইন = "control.internal.example" মূল = "/srv/control" certificate_mode = "এম্বেডেড"
[[সাইটগুলি]] ডোমেইন = "payments.example.com" root = "/srv/payments"
[সাইটগুলি.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~
এখানে, www.example.com তার নিজস্ব পাবলিক ACME সার্টিফিকেট পায়। control.internal.example এমবেডেড CA থেকে একটি প্রাইভেট সার্টিফিকেট পায়। payments.example.com অপারেটরের এক্সটার্নাল PKI এর অধীনে থাকে কারণ এর স্পষ্ট ফাইলগুলো অগ্রাধিকার পায়।
সর্বসাধারণ ACME নির্দেশিকা সংযুক্ত সাইট দ্বারা উপেক্ষা করা হয়। সংযুক্ত মূল কখনও সর্বসাধারণ সাইটে স্বাক্ষর করে না। ম্যানুয়াল সাইট কখনও স্বয়ংক্রিয় ওয়ার্কফ্লোতে নিঃশব্দে নিবন্ধিত হয় না।
H1, H2, H3 এবং WebTransport এর জন্য একটি সার্টিফিকেট রিজলভার
সার্টিফিকেট নির্বাচন TLS হ্যান্ডশেকের সময় ঘটে, HTTP অনুরোধ তৈরি হওয়ার আগে। Webship সাইট আইডেন্টিটি নির্বাচন করতে ClientHello সার্ভার নাম ব্যবহার করে এবং তারপর অ্যাপ্লিকেশন প্রোটোকল নিয়ে আলোচনার প্রক্রিয়া শুরু করে।
- HTTP/1.1 এবং HTTP/2 TCP এর উপর TLS ব্যবহার করে।
- HTTP/3 এবং WebTransport UDP এর উপর QUIC এর ভেতরে TLS ব্যবহার করে।
- একটি বৈধ সাইট পরিচয় প্রতিটি সক্রিয় প্রটোকলকে সেবা দিতে পারে।
- HTTP/3 এছাড়াও UDP সংযোগযোগ্যতা প্রয়োজন; H1 এবং H2 TCP পথ ব্যবহার করে।
- Alt-Svc একটি TCP ফ্যালব্যাক সংরক্ষণ করে H3 প্রচার করতে পারে।
TCP, TLS এবং QUIC একই সাইট-সচেতন পরিচয় মডেল ব্যবহার করে। সঠিক নামগুলি প্রাধান্য পায়, যেখানে ওয়াইল্ডকার্ড সার্টিফিকেট কনফিগার করা হয় সেখানে দীর্ঘতম বৈধ ওয়াইল্ডকার্ড জয়ী হয়, এবং অজানা নামযুক্ত SNI প্রত্যাখ্যাত হতে পারে অপরিচিত ডিফল্ট সার্টিফিকেট গ্রহণের পরিবর্তে।
যখন একটি অজানা হোস্টনেমে ব্যর্থ হওয়া প্রয়োজন, তখন একটি মাল্টি-সাইট লিসেনারে unknown_sni = "reject" ব্যবহার করুন। প্রোডাকশন রোলআউটের আগে স্বীকৃত নাম, অস্বীকৃত নাম এবং আপনার প্রত্যাশিত no-SNI আচরণ পরীক্ষা করুন।
সার্ভিং গ্যাপ ছাড়া অন্তর্নিহিত পরিচয় আবর্তন করুন
Webship এর প্রমাণপত্রের অবস্থা এবং নিয়ন্ত্রিত পরিবর্তনগুলি এর প্রমাণীকৃত, লুপব্যাক-বাউন্ড MCP সার্ভারের মাধ্যমে প্রকাশ করে:
- webship.tls.get_status সক্রিয় সার্টিফিকেট রিজোলভার এবং নবায়ন অবস্থা রিপোর্ট করে।
- webship.tls.reissue_certificate স্বয়ংক্রিয়ভাবে পরিচালিত একটি সাইট শুধুমাত্র তখনই পুনঃপ্রদায়ন করে যখন সেই সাইটটি এমবেডেড মোড ব্যবহার করে।
- webship.tls.reload সাধারণ সুরক্ষিত TLS পথের মাধ্যমে সার্টিফিকেটের অবস্থাকে পুনঃলোড করে।
- webship.acme_ca.status রিপোর্ট করে যে প্রাইভেট CA নির্বাচিত হয়েছে কি না, এর স্টেট ডিরেক্টরি, লিফ লাইফটাইম, ইস্যু সংখ্যা, রিভোকেশন সংখ্যা, এবং সাম্প্রতিক ডোমেইনের নমুনা।
- webship.sites.apply একটি পিন করা কনফিগারেশন সংস্করণের বিরুদ্ধে সাইট যোগ বা অপসারণ করে।
একটি এমবেডেড পুনঃমুদ্রণের জন্য, Webship সার্ভিসে প্রতিস্থাপন করার আগে সেটি তৈরি এবং যাচাই করে। বর্তমান বৈধ পরিচয় নতুন পরিচয় প্রস্তুত হওয়া পর্যন্ত সার্ভিস প্রদান চালিয়ে যায়। প্রতিস্থাপন ইনস্টল হওয়ার পরেই অবসরপ্রাপ্ত পরিচয়টি রেকর্ড করা হয়।
তাৎক্ষণিক পুনঃপ্রকাশ কার্যক্রম সচেতনভাবে পাবলিক per_site সার্টিফিকেটগুলো প্রত্যাখ্যান করে। পাবলিক নবায়ন অবশ্যই পাবলিক ACME লাইফসাইকেলের মধ্যে থাকতে হবে, ব্যক্তিগত প্রক্রিয়াধীন সইয়ের সাথে বিভ্রান্ত হওয়া উচিত নয়। শেয়ার্ড-মোড সদস্যপনাও পুনরায় শুরু-প্রক্রিয়ায় স্থগিত থাকে কারণ একটি বহু-SAN গ্রুপ পরিবর্তন করা আইডেন্টিটি সীমানা পুনর্গঠন করে।
MCP একটি বিশেষাধিকারপ্রাপ্ত নিয়ন্ত্রণ পৃষ্ঠ। এটি লুপব্যাকে রাখুন, TLS এবং একটি শক্তিশালী বেয়ার টোকেন প্রয়োজন, দূরবর্তী প্রশাসনের জন্য একটি প্রমাণীকৃত টানেল ব্যবহার করুন, এবং প্রতিটি পরিবর্তনের অডিট করুন।
ব্যর্থতার সীমা যা গুরুত্বপূর্ণ
একটি নিরাপদ সার্টিফিকেট সিস্টেমকে সঠিক দিকেই ব্যর্থ হতে হবে।
- নতুনভাবে কনফিগার করা এমবেডেড সাইটটি ইস্যু প্রক্রিয়ার সময় অন্য সাইটের পরিচয় পায় না।
- একটি অবৈধ প্রতিস্থাপন কার্যকর সার্টিফিকেটের উপর স্থাপন করা হয়নি।
- স্পষ্ট ম্যানুয়াল ফাইলগুলি সেই সাইটের স্বয়ংক্রিয় মালিকানা রোধ করে।
- অজানা নামের SNI HTTP রাউটিংয়ের আগে প্রত্যাখ্যাত হতে পারে।
- এম্বেডেড CA ব্যক্তিগত থাকে এবং এর কোনও রিমোট এনরোলমেন্ট এন্ডপয়েন্ট নেই।
- সাধারণ ও এমবেডেড পরিচয়গুলি স্বয়ংক্রিয়-TLS অবস্থার মধ্যে পৃথক ক্যাশ পথ ব্যবহার করে।
এটি একটি সতর্কবার্তা যে এমবেডেড CA ইনিশিয়ালাইজ করা হয়নি, অর্থাৎ Webship কনফিগার করা স্টেট ডিরেক্টরিটি আর্ম করতে পারেনি। প্রভাবিত সাইটে ট্রাফিক পাঠানোর আগে মালিকানা, অনুমতি, স্থায়িত্ব, বা স্টোরেজের প্রাপ্যতা ঠিক করুন। অন্য পরিবেশের রুট কী অনুলিপি করে ত্রুটিটি এড়ানোর চেষ্টা করবেন না।
উৎপাদন চেকলিস্ট
এম্বেডড মোড সক্রিয় করার আগে:
- প্রতিটি ক্লায়েন্ট জনসংখ্যা চিহ্নিত করুন যারা সাইটটিতে বিশ্বাস রাখতে হবে।
- রুট সার্টিফিকেট রপ্তানি এবং ইনস্টল করার জন্য একটি নিয়ন্ত্রিত প্রক্রিয়া তৈরি করুন।
- প্রোডাকশন, ডেভেলপমেন্ট, এবং টেস্টিং-এর জন্য আলাদা রুট স্টেট ব্যবহার করুন।
- এম্বেডেড-CA স্টেট ডিরেক্টরি এবং অটোমেটিক-TLS ক্যাশ সংরক্ষণ এবং সুরক্ষিত রাখুন।
- শুধুমাত্র প্রয়োজনীয় কী উপাদানে অ্যাক্সেস সহ একটি সংরক্ষিত সার্ভিস অ্যাকাউন্টে Webship চালান।
- প্রতিটি সাইটে certificate_mode নির্বাচন করুন যার বিশ্বাস সীমা স্পষ্ট হতে হবে।
- অজানা-SNI নীতি সেট করুন এবং পরীক্ষা করুন।
- H1, H2, এবং H3 ইচ্ছাকৃতভাবে সক্ষম করুন এবং TCP এবং UDP উভয় পথ যাচাই করুন।
- প্রোডাকশনের বাইরে পুনঃনিঃপ্রচার, পুনঃপ্রারম্ভ, ব্যাকআপ, পুনরুদ্ধার, এবং ক্লায়েন্ট-ভরসা যাচাই অনুশীলন করুন।
- রোলআউটের আগে webship --check-config চালান, তারপর একটি বাস্তব ক্লায়েন্ট থেকে ইস্যুকারী, নাম, বৈধতা, চেইন এবং আলোচ্য প্রোটোকলগুলি যাচাই করুন।
প্রথমে বিশ্বাস নির্বাচন করুন, দ্বিতীয়ে স্বয়ংক্রিয়তা
এম্বেডেড CA একটি ব্যক্তিগত অবকাঠামোর জন্য বাহ্যিক সার্টিফিকেট-সার্ভিস নির্ভরতা অপসারণ করে। এটি একটি ব্যক্তিগত রুটকে বৈশ্বিকভাবে বিশ্বাসযোগ্য করে তোলে না, এবং এটি অপারেটরের PKI দায়িত্বও অপসারণ করে না।
Webship মূল জেনারেশন, স্বাক্ষর, যাচাই, ইনস্টলেশন, ঘূর্ণন এবং প্রোটোকল-ব্যাপী সার্টিফিকেট নির্বাচন স্বয়ংক্রিয় করে। অপারেটর এখনও মূল দখল, ক্লায়েন্ট রেজিস্ট্রেশন, পরিবেশ বিভাজন, ব্যাকআপ, পুনরুদ্ধার এবং পাবলিক বা প্রাইভেট ট্রাস্ট পাথ ব্যবহার করার সিদ্ধান্তের মালিকানা রাখে।
সেই বিচ্ছিন্নতাই বৈশিষ্ট্য। একটি স্ব-সম্পূর্ণ সার্ভার প্রকাশ্য CA হিসেবে себя-ভান না করে ব্যক্তিগত TLS স্বয়ংক্রিয় করতে পারে—এবং প্রকাশ্য সাইটগুলো এখনও একই প্রক্রিয়ায় ব্রাউজার-ভরসাযোগ্য per-site বা fleet ইস্যু ব্যবহার করতে পারে।
রোলআউটের আগে সংস্করণকৃত Webship 1.4.0 ডকুমেন্টেশন পড়ুন। RFC 5280 সার্টিফিকেট প্রোফাইল এবং যাচাইকরণ সংজ্ঞায়িত করে, RFC 6066 TLS সার্ভার-নেম সংকেত সংজ্ঞায়িত করে, RFC 8446 TLS 1.3 সংজ্ঞায়িত করে, RFC 8555 পাবলিক ACME সংজ্ঞায়িত করে, এবং RFC 9525 সেবা পরিচয় যাচাইকরণ সংজ্ঞায়িত করে।