# TLS certificate failures: agent response procedure

Agent API call में certificate error stop signal है, कोई मामूली networking परेशानी नहीं। Call में bearer token, signed request, customer record या production state बदलने वाले instructions हो सकते हैं। यदि client यह तय नहीं कर सकता कि connection के दूसरे सिरे का मालिक कौन है, तो उसे इनमें से कुछ भी भेजने का अधिकार नहीं है।

दबाव में काम कर रहा व्यक्ति expired certificate देखकर insecure flag इस्तेमाल कर लेता है, इसलिए यह समस्या अक्सर गलत तरीके से संभाली जाती है। Autonomous agent इस shortcut को और खतरनाक बना देता है। वह तेजी से retry कर सकता है, repository issue में छिपे instruction का पालन कर सकता है और एक से अधिक credentials के साथ वही unsafe call दोहरा सकता है। अच्छी response procedure run रोकती है, facts और guesses को अलग करती है और access तभी बहाल करती है जब कोई यह साबित कर दे कि intended endpoint फिर से वही endpoint है जिसे traffic मिल रहा है।

## Certificate warning trust का निर्णय बदल देती है

TLS के दो काम हैं, जिन्हें लोग अक्सर एक ही समझ लेते हैं। यह traffic encrypt करता है और server की identity verify करता है। Identity verification के बिना encryption attacker को आपके client के साथ private conversation करने का मौका भर देती है।

RFC 6125 बताता है कि application service identity को reference identifier से कैसे जांचती है। आम तौर पर यह वही DNS name होता है जहां client पहुंचना चाहता है। RFC 5280 certificate path validation का वर्णन करता है: client प्रस्तुत leaf certificate से intermediates के जरिए trust anchor तक chain बनाता है। दोनों checks जरूरी हैं। Certificate का signature valid हो सकता है, फिर भी वह `api.example` के बजाय `api-attacker.example` का हो सकता है। उसमें सही hostname हो सकता है, फिर भी वह ऐसे issuer तक chain कर सकता है जिसे आपके संगठन ने कभी approve नहीं किया।

Agent traffic में इसका असर साफ है। HTTPS request में डाला गया bearer token connection terminate करने वाले व्यक्ति के लिए usable हो जाता है। Client credential से signed request state changes को authorize कर सकती है। Impostor के API response से बाद का action प्रभावित हो सकता है या agent का working context दूषित हो सकता है। Request encrypted थी, इससे इनमें से कोई जोखिम कम नहीं होता।

इन messages का कारण पता चलने तक इन्हें security-relevant मानें:

- certificate expire हो गया है या अभी valid नहीं है
- hostname या subject alternative name match नहीं करता
- local issuer certificate नहीं मिल रहा या first certificate verify नहीं हो रहा
- certificate chain में self-signed certificate है
- proxy, DNS या network change के बाद certificate verification fail हो रहा है

हर failure को active attack न मानें। भूला हुआ intermediate certificate और गलत समय वाली laptop clock सामान्य operational failures हैं। फिर भी response uncertainty से शुरू होती है, क्योंकि यही error class traffic redirect होने या unapproved interception proxy install होने पर भी दिखाई देती है।

Successful TCP connection केवल यह साबित करता है कि किसी address पर किसी चीज ने जवाब दिया। Verification बंद करके हुआ successful TLS handshake इससे भी कम साबित करता है। Server identity check वही बिंदु है जहां credential वाले API call को machine से बाहर जाने की अनुमति मिलती है।

## Clues इकट्ठे करने से पहले प्रभावित run रोकें

पहला operational action failing destination पर होने वाले अतिरिक्त credential वाले calls रोकना है। Agent process suspend करें, यदि आपका action layer revocation support करता है तो active session revoke करें, या उसकी action करने की permission हटा दें। Certificate परिचित लग रहा है या नहीं, इस पर एक घंटा चर्चा करने से पहले यह करें।

मूल error को ठीक उसी रूप में सुरक्षित रखें। पूरा hostname और port, authorization header के बिना request method, timezone सहित timestamp, client runtime और version तथा call शुरू करने वाली process दर्ज करें। यह भी लिखें कि machine ने कौन-सा network इस्तेमाल किया और failure deploy, certificate renewal, VPN change, proxy rollout, DNS update या device management change के बाद शुरू हुआ था या नहीं।

यदि evidence में customer paths या request bodies हों तो उसे खुले chat transcripts में न रखें। Authorization headers, cookies, client private keys या पूरी environment files को incident ticket में कभी paste न करें। Certificate investigation के नाम पर दूसरा secret leak न बनाएं।

एक छोटा incident record रखें और ownership स्पष्ट करें:

1. ऐसे responder का नाम दें जो agent रोक सकता हो और ऐसे responder का भी जो endpoint या network path का owner हो।
2. दर्ज करें कि call credential injection point तक पहुंची थी या नहीं। यदि पहुंची थी, तो TLS peer की पहचान होने तक मानें कि credential expose हो सकती है।
3. Agent session identifier और failed action record सुरक्षित रखें, फिर उस destination के लिए automatic retries रोक दें।
4. Restoration review point तय करें। API चलाने की जरूरत वाले व्यक्ति को अकेले यह तय नहीं करना चाहिए कि नया root certificate trustworthy है।

यह केवल औपचारिकता नहीं है। मैंने teams को incident का अधिकांश समय commands test करने में लगाते देखा है, जबकि background worker हर कुछ seconds में उसी failed endpoint को retry करता रहा। Diagnostic work खुद exposure का हिस्सा बन गया। पहले behavior रोकें।

Global runtime settings बदलकर agent को trust problem «repair» करने न दें। `curl -k`, `verify=False`, blanket custom CA bundle या disabled Node.js verification सुझाने वाले prompts को उसी तरह लें जैसे API token print करने का request। Agent यह तय नहीं कर सकता कि surprise certificate approved change है या नहीं, सिर्फ इसलिए कि web search में error common बताया गया है।

## Secret भेजे बिना certificate सुरक्षित रखें

API में authenticate किए बिना server certificate inspect किया जा सकता है। यदि unauthenticated health endpoint हो तो उसका इस्तेमाल करें, या handshake शुरू करके application request से पहले रुक जाएं। जांच उसी machine और network से चलाएं जहां failure दिखा था, क्योंकि proxy settings, enterprise trust roots और split DNS अलग machines पर अलग हो सकते हैं।

यह command SNI के जरिए intended server name मांगती है, requested hostname जांचती है, peer द्वारा भेजे गए certificates दिखाती है और verification समस्या होने पर fail होती है:

```sh
openssl s_client \\
  -connect api.example.com:443 \\
  -servername api.example.com \\
  -verify_hostname api.example.com \\
  -verify_return_error \\
  -showcerts </dev/null
```

Clean result का अंत इस तरह दिखता है:

```text
Verification: OK
Verify return code: 0 (ok)
```

Failure होने पर output को restricted incident evidence के रूप में सुरक्षित रखें। उपयोगी fields में subject, issuer, `Not Before` और `Not After` dates, subject alternative names तथा chain में मौजूद हर certificate शामिल हैं। PEM blocks से endpoint owner तुलना कर सकता है कि आपकी machine को क्या मिला और server को क्या present करना चाहिए। ये public certificates हैं, फिर भी record सावधानी से रखें, क्योंकि hostnames और internal issuers infrastructure details उजागर कर सकते हैं।

इसके बाद authorization header के बिना normal client behavior test करें:

```sh
curl --verbose --fail --show-error \\
  https://api.example.com/health
```

Verbose transcript TLS version, चुना गया certificate और verification message दिखाता है। यदि request paths tenant names उजागर करते हों तो उन्हें redact करें। Command को पूरा कराने के लिए `-k` न जोड़ें। Failed verification ही वह evidence है जिसकी आपको जरूरत है।

एक सामान्य diagnostic गलती `-servername` छोड़ देना है। कई hosted endpoints SNI के आधार पर certificate चुनते हैं और client के इसे छोड़ने पर default certificate लौटाते हैं। इससे ऐसा hostname mismatch बन सकता है जो वास्तविक client को कभी प्रभावित नहीं करता। दूसरी गलती `openssl s_client` को `-verify_hostname` के बिना चलाकर chain result को hostname match होने का प्रमाण मानना है। वह प्रमाण नहीं है।

अपने सामान्य DNS diagnostic tool से resolved address अलग से record करें। Address matching को पूरी जांच न बनाएं। बड़े providers के पास स्वाभाविक रूप से कई addresses होते हैं, जबकि attacker ऐसा DNS answer नियंत्रित कर सकता है जो plausible दिखे। Certificate name, issuer path, network path और approved change record मिलकर पूरी कहानी बताते हैं।

## Repair चुनने से पहले failure classify करें

Log में certificate errors एक जैसे दिख सकते हैं, लेकिन उनके fixes अलग होते हैं। Trust configuration बदलने से पहले evidence को किसी category में रखें। वरना team दिखाई देने वाले error को ठीक कर देगी, जबकि मूल routing या deployment fault बना रहेगा।

Expired certificate का आम अर्थ है कि endpoint operator renewal भूल गया या renewed leaf certificate deploy नहीं कर पाया। Captured certificate के validity interval को trusted clock से मिलाएं। Clock error से current certificate expired या not yet valid दिखाई दे सकता है, इसलिए provider से कुछ rotate करने को कहने से पहले client time जांचें।

Hostname mismatch का अर्थ है कि server ने client द्वारा मांगे गए name का ownership साबित नहीं किया। सामान्य कारण wrong API base URL, SNI configuration error, default virtual host, stale DNS या अलग name के लिए proxy certificate हैं। केवल समान दिखने वाले alternate name को स्वीकार न करें। `api.example.com` और `api.internal.example.com` अलग services और trust boundaries हो सकते हैं।

Unknown issuer का अर्थ हो सकता है कि client के पास legitimate private root या intermediate certificate नहीं है। यह भी हो सकता है कि unapproved TLS inspection device ने substitute leaf certificate जारी किया हो। Independent channel से endpoint owner की published या recorded deployment information के साथ issuer और chain की तुलना करें। उसी system से आया chat message जिसने error पैदा किया, independent confirmation नहीं है।

Incomplete chain आम तौर पर endpoint की गलती होती है। Servers को leaf certificate और जरूरी intermediate certificates भेजने चाहिए। Clients के पास पहले से केवल trust roots होने चाहिए। Missing intermediate को locally install करने से एक machine पर broken server configuration छिप सकती है, जबकि हर दूसरा caller broken रहेगा। Server owner से सही chain serve करने को कहें।

Self-signed leaf certificate को अतिरिक्त संदेह से देखें। Internal development service पर यह सामान्य हो सकता है, लेकिन अपने आप में public identity proof नहीं देता। Managed private CA ठीक काम कर सकती है, यदि administrators approved device या workload trust store के जरिए उसका root distribute करें और दर्ज करें कि उस CA को कौन नियंत्रित करता है। Endpoint owner द्वारा email किया गया कोई random self-signed certificate trust program नहीं है।

Certificate revocation पर सावधानी जरूरी है। हर environment में कई clients online revocation checks reliably नहीं करते, और network failures इन checks को प्रभावित कर सकते हैं। केवल इसलिए certificate को safe न कहें कि basic handshake `0 (ok)` लौटाता है। यदि owner compromised private key या revoked certificate की सूचना दे, तो destination block करें, exposed credentials rotate करें और replacement deployment लगवाएं।

## Server path और proxy path अलग रखें

Managed proxy TLS को वैध रूप से terminate करके substitute certificates जारी कर सकता है, लेकिन यह बात स्पष्ट होनी चाहिए। यदि machine अचानक अपरिचित corporate issuer देखने लगे, तो subject में company name होने भर से उसे harmless न मानें। Proxy rollout, approved root, scope और यह बात confirm करें कि API का data और credentials उसके जरिए जा सकते हैं या नहीं।

Calling environment में proxy configuration जांचें, लेकिन ऐसे values dump न करें जिनमें credentials हो सकते हैं। Unix-like shell पर यह केवल configured proxy variables के नाम print करता है:

```sh
for n in HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY http_proxy https_proxy all_proxy no_proxy; do
  [ -n "${!n}" ] && printf '%s is set\n' "$n"
done
```

Proxy setting बता सकती है कि वही API mobile connection पर काम करती है, लेकिन office network पर fail क्यों होती है। इससे proxy approve नहीं हो जाती। Organization के नियम अनुमति दें तभी authorized alternate network पर results compare करें। यदि certificate issuer network के साथ बदलता है, तो result record करके network owner को दें।

Name resolution और routing changes भी देखें। Migration के बाद stale DNS calls को पुराने load balancer तक भेज सकता है, जो retired certificate प्रस्तुत करता हो। Split-horizon DNS office devices को private certificate वाले internal address और अन्य जगहों को public address दे सकता है। ये ठीक किए जा सकने वाले designs हैं, लेकिन client को route के लिए उचित issuer पर भरोसा करना होगा और requested hostname match भी करना होगा।

IP address hardcode करके समस्या से बचने की कोशिश न करें। HTTPS identity checks DNS names का इस्तेमाल करते हैं, और direct IP intended routing bypass कर सकता है, SNI selection fail कर सकता है या DNS control problem छिपा सकता है। IP override कभी-कभी tightly controlled diagnostic test में उपयोगी है, लेकिन endpoint owner की approval चाहिए और इसे agent की permanent configuration नहीं बनना चाहिए।

Proxies एक data governance question भी पैदा करते हैं जिसका उत्तर केवल certificate error से नहीं मिलता। यदि proxy TLS terminate करती है, तो वह API bodies और injected authorization material पढ़ सकती है। Security team को तय करना होगा कि उस API के लिए inspection allowed है या नहीं। Endpoint फिर से काम करने लगे, इससे यह साबित नहीं होता कि नया path स्वीकार्य है।

## Private CA trust को सीमित और reviewable रखें

Private certificate authorities internal APIs, development environments और controlled service meshes की वास्तविक समस्या हल करती हैं। समस्या तब आती है जब teams roots को अनौपचारिक रूप से distribute करती हैं और भूल जाती हैं कि कौन-सी processes उन पर भरोसा करती हैं। Root certificate अपने holder को trust domain के भीतर identities जारी करने की व्यापक शक्ति देता है। इसलिए इसे जोड़ना compatibility tweak नहीं, administrative security change है।

Approved private root को उस managed operating system, container image या application trust store के जरिए install करें जो call को नियंत्रित करता है। Root का subject, fingerprint, owner, intended DNS suffixes, approval date और removal path record करें। Runtime अनुमति दे तो trust scope सीमित रखें। Development CA को चुपचाप हर machine के हर production agent के लिए trusted नहीं होना चाहिए।

Missing CA process के shortcut के रूप में किसी एक leaf certificate पर भरोसा न करें। Renewal पर leaf trust टूट जाता है और लोगों को repositories में PEM strings paste करने की आदत पड़ती है। इससे deliberate endpoint rotation और unexpected substitution में अंतर करना भी कठिन हो जाता है। यदि दोनों ends आपके नियंत्रण में हैं, तो protected signing material, documented issuance और planned rotation वाली private CA process बनाएं।

Mutual TLS identity की एक अलग दिशा जोड़ता है। सामान्य HTTPS में client server certificate validate करता है। mTLS में server client से भी certificate मांगता है। `alert certificate required` या `bad certificate` जैसी failure का अर्थ हो सकता है कि client ने अपना certificate नहीं दिया, गलत issuer का certificate दिया या उसके पास matching private key नहीं है। Server verification बंद करने से यह समस्या हल नहीं होगी।

Client private keys को prompts, shell snippets और agent workspaces से बाहर रखें। Controlled caller को client credential तक operating system store या किसी अन्य protected mechanism के जरिए पहुंच दें। यदि client certificate या उसकी private key unverified TLS connection से गुजरने की संभावना हो, तो issuing CA की procedure के अनुसार उसे revoke या replace करें। इसे server certificate से अलग समझें, लेकिन हल्के में न लें।

Certificate pinning भी ऐसा क्षेत्र है जहां अच्छे इरादे outages ला सकते हैं। Leaf certificate pin करने से client किसी खास renewal artifact से बंध जाता है, इसलिए सामान्य rotation हर agent को रोक सकती है। Narrow, high-risk integration में pinning उचित हो सकती है, यदि operators backup pins रखें और rotation test करें। अधिकांश teams के लिए hostname verification, approved trust roots और certificate expiry monitoring बेहतर परिणाम देते हैं।

## Independent check के बाद ही access बहाल करें

Agent को तभी restore करें जब किसी ने failed agent workflow के बाहर repair verify कर लिया हो। Check में actual hostname, expected trust store और normal verification करने वाला client इस्तेमाल होना चाहिए। Browser visit अक्सर पर्याप्त नहीं होता, क्योंकि browsers और command-line clients अलग proxy settings और trust stores इस्तेमाल कर सकते हैं।

Public API के लिए verify करें कि presented chain expected public trust root तक पहुंचती है, subject alternative names configured hostname को शामिल करते हैं और endpoint owner recorded change के जरिए deployment या renewal confirm करता है। Private API के लिए approved private root, issuer, hostname और expected network route verify करें। Successful command result को original failure के साथ capture करें।

इसके बाद उसी path से एक low-impact authenticated action चलाएं जिसका इस्तेमाल agent करेगा। Read-only endpoint या API में उपलब्ध harmless identity check चुनें। Action log और उपलब्ध हो तो server-side audit record देखें। Destination hostname, response status और इस्तेमाल हुई credential identity confirm करें। पहले test के रूप में broad batch job restore न करें।

यदि पहले failure में token, signed request या mTLS credential के impostor तक पहुंचने की कोई संभावना हो, तो normal work फिर शुरू करने से पहले credential rotate करें। Evidence अधूरा होने के कारण teams अक्सर rotation से बचती हैं। बात उलटी है। अधूरा evidence ही कारण है कि unverified connection से गुजर चुकी credential को exposed मानना चाहिए।

Vague conclusion जैसे «TLS fixed» के बजाय exact repair लिखें। उपयोगी closure में लिखा हो कि endpoint operator ने intermediate certificate deploy किया, managed trust store में specified approved root जोड़ा गया या proxy configuration हटाई गई। यह भी दर्ज हो कि hostname verify किसने किया और कौन-से agent runs resume हुए। यह record अगले responder को certificate renew होने पर insecure override फिर से जोड़ने से रोकता है।

## Safe path को bypass से आसान बनाएं

यदि secure handling में कई घंटे लगें और bypass के लिए केवल एक environment variable चाहिए, तो procedure fail होगी। Agent integration इस तरह बनाएं कि वह insecure TLS mode न चुन सके, global trust configuration न बदल सके और troubleshooting के दौरान long-lived credentials न देख सके। Connection settings, approved hostnames और trust material को सामान्य change review के अधीन रखें।

Sallyport API credentials को encrypted vault में रख सकता है और agent के लिए HTTP calls कर सकता है, इसलिए agent को credentials खुद नहीं मिलते। उसके session और call records यह भी सुरक्षित रख सकते हैं कि action किसने करने की कोशिश की, लेकिन बदला हुआ certificate approved change है या dangerous route, यह निर्णय फिर भी human को लेना होगा।

Repeated validation failures और known bypasses invoke करने की हर कोशिश पर alert करें। Failed call में इतना structured context होना चाहिए कि responder secret के बिना hostname, failure class और agent run पहचान सके। Agents को fixed instruction दें: certificate validation error पर रुकें, exact error और endpoint report करें और human review मांगें। उनसे workaround खोजने को न कहें।

पहला repair आम तौर पर साधारण होता है: scripts में पहले से मौजूद insecure verification switch हटाएं और normal client को managed trust store इस्तेमाल करने दें। फिर production से पहले certificate renewal test करें। जो teams एक renewal और एक unexpected-issuer incident का अभ्यास करती हैं, वे उन teams से तेज response देती हैं जिनकी पूरी TLS योजना किसी forum से copy की गई command है।

Certificate warning ने अपना काम तब किया है जब उसने ऐसी request रोक दी हो जिसे आगे नहीं बढ़ना चाहिए था। इसे इसी तरह बनाए रखें।