🌐 Detecting your location…

‘एसएसएल प्रमाणपत्र समस्या: स्थानीय जारीकर्ता प्रमाणपत्र प्राप्त करने में असमर्थ’ को कैसे ठीक करें

⏱️3 min read  ·  536 words

SSL certificate problem: unable to get local issuer certificateइसका मतलब है कि आपका क्लाइंट सर्वर के प्रमाणपत्र से उस प्रमाणपत्र प्राधिकारी तक विश्वास की श्रृंखला नहीं बना सका जिस पर वह भरोसा करता है। प्रलोभन सत्यापन को अक्षम करने का है। ऐसा न करें – यह अवरोधन के विरुद्ध सुरक्षा को पूरी तरह से हटा देता है। वास्तविक समाधान आमतौर पर सीधा होता है।

त्रुटि का क्या अर्थ है

जब कोई क्लाइंट टीएलएस से जुड़ता है, तो सर्वर अपना प्रमाणपत्र और कोई भी मध्यवर्ती प्रमाणपत्र प्रस्तुत करता है। क्लाइंट को उस श्रृंखला को अपने स्थानीय सीए स्टोर में किसी विश्वसनीय रूट से लिंक करना होगा। त्रुटि तब प्रकट होती है जब कोई लिंक गायब होता है – या तो सर्वर ने मध्यवर्ती नहीं भेजा, या आपका स्थानीय ट्रस्ट स्टोर गायब है या पुराना है।

जिसका निदान चेन का निरीक्षण कर करें।

openssl s_client -connect example.com:443 -showcerts </dev/null

# Look for the verification result at the end:
#   Verify return code: 0 (ok)
#   Verify return code: 20 (unable to get local issuer certificate)
#   Verify return code: 21 (unable to verify the first certificate)

रिटर्न कोड21 आम तौर पर इसका मतलब है कि सर्वर गलती पर है – उसने अपना मध्यवर्ती प्रमाणपत्र नहीं भेजा है। रिटर्न कोड20 आम तौर पर इसका मतलब है कि समस्या आपका स्थानीय ट्रस्ट स्टोर है।

कारण 1: सर्वर इंटरमीडिएट नहीं भेज रहा है

एक सामान्य सर्वर गलत कॉन्फ़िगरेशन. ब्राउज़र अक्सर इसे छिपाते हैं क्योंकि वे पिछली विज़िट से इंटरमीडिएट को कैश करते हैं, इसलिए साइट “क्रोम में काम करती है” जबकि कर्ल और आपकी सीआई पाइपलाइन विफल हो जाती है।

# Count the certificates the server sends
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# 1 means only the leaf — the intermediate is missing

यदि आप सर्वर को नियंत्रित करते हैं, तो इसे वहां ठीक करें। nginx को उसी क्रम में लीफ़ और मध्यवर्ती को एक फ़ाइल में संयोजित करने की आवश्यकता है।

# Correct order: leaf first, then intermediates
cat leaf.crt intermediate.crt > fullchain.crt
server {
    # Use the full chain, not just the leaf certificate
    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/privkey.key;
}

सर्टबोट काfullchain.pem पहले से ही श्रृंखला शामिल है – nginx कोcert.pemकी ओर इंगित करता है इसके बजाय Let’s Encrypt साइटों पर इस त्रुटि का सबसे आम कारण है।

कारण 2: पुराना या गुम सीए बंडल

यदि सर्वर की श्रृंखला पूरी हो गई है, तो आपका स्थानीय ट्रस्ट स्टोर पुराना है।

# Debian / Ubuntu
sudo apt update && sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

# RHEL / Fedora
sudo dnf reinstall ca-certificates
sudo update-ca-trust

# Alpine (very common in Docker images)
apk add --no-cache ca-certificates
update-ca-certificates

# macOS
brew install ca-certificates
# or update curl, which bundles its own
brew install curl

मिनिमल डॉकर छवियां इस त्रुटि का लगातार स्रोत हैं क्योंकि वे बिना किसी सीए बंडल के शिप की जाती हैं। जोड़ रहा हूँca-certificates छवि को आमतौर पर एक पंक्ति में हल किया जाता है।

कारण 3: कॉर्पोरेट टीएलएस अवरोधन

कई कॉर्पोरेट नेटवर्क आंतरिक सीए द्वारा हस्ताक्षरित अपना प्रमाणपत्र प्रस्तुत करके टीएलएस को रोकते हैं। ब्राउज़र काम करते हैं क्योंकि CA को डिवाइस प्रबंधन के माध्यम से OS स्तर पर स्थापित किया जाता है; अपने स्वयं के ट्रस्ट स्टोर के साथ कमांड-लाइन टूल नहीं हैं।

समाधान कॉर्पोरेट रूट सीए को संबंधित ट्रस्ट स्टोर में जोड़ना है – सत्यापन को अक्षम करना नहीं।

# Capture the certificate the proxy is presenting
openssl s_client -showcerts -connect example.com:443 </dev/null \
  | openssl x509 -outform PEM > corp-ca.crt

# Inspect it to confirm what it is
openssl x509 -in corp-ca.crt -noout -subject -issuer -dates

# Install system-wide (Debian/Ubuntu)
sudo cp corp-ca.crt /usr/local/share/ca-certificates/corp-ca.crt
sudo update-ca-certificates

जहां संभव हो, इसे स्वयं निकालने के बजाय आधिकारिक रूट सीए फ़ाइल के लिए अपने आईटी विभाग से पूछें – लाइव कनेक्शन से निकालने से यह माना जाता है कि कनेक्शन पहले से ही समझौता नहीं किया गया है।

प्रति-टूल फिक्स

कर्ल

# Point at a specific bundle
curl --cacert /path/to/ca-bundle.crt https://example.com

# Or set it for the session
export CURL_CA_BUNDLE=/path/to/ca-bundle.crt

गिट

# Correct fix: point Git at a valid bundle
git config --global http.sslCAInfo /path/to/ca-bundle.crt

# Scope it to one host if only that host is affected
git config --global http."https://internal.company.com/".sslCAInfo /path/to/corp-ca.crt

git config --global http.sslVerify false इस त्रुटि के लिए प्रत्येक खोज परिणाम में दिखाई देता है। यह आपके द्वारा क्लोन किए गए प्रत्येक होस्ट के लिए प्रमाणपत्र सत्यापन को स्थायी रूप से अक्षम कर देता है। इसका उपयोग ना करें।

नोड.जेएस

# Add a CA to Node's trust store for this process
export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.crt
node app.js
// Or per-request, which is more precise
import https from 'node:https';
import fs from 'node:fs';

const agent = new https.Agent({
  ca: fs.readFileSync('/path/to/corp-ca.crt'),
});

await fetch('https://internal.example.com', { agent });

NODE_TLS_REJECT_UNAUTHORIZED=0 सत्यापन प्रक्रिया को पूरी तरह से अक्षम कर देता है और नोड ठीक यही कहते हुए एक चेतावनी प्रिंट करता है। यह एक स्थानीय परीक्षण में ही स्वीकार्य है और कहीं नहीं।

पायथन

import certifi, requests

# Use certifi's bundle explicitly
requests.get('https://example.com', verify=certifi.where())

# Or a corporate CA
requests.get('https://internal.example.com', verify='/path/to/corp-ca.crt')
# Environment variables respected by requests and urllib3
export REQUESTS_CA_BUNDLE=/path/to/ca-bundle.crt
export SSL_CERT_FILE=/path/to/ca-bundle.crt

# Keep certifi current
pip install --upgrade certifi

डॉकर

FROM node:22-alpine

# Alpine ships without a CA bundle
RUN apk add --no-cache ca-certificates

# Add a corporate CA if you are behind interception
COPY corp-ca.crt /usr/local/share/ca-certificates/
RUN update-ca-certificates

ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt

कारण 4: प्रमाणपत्र समाप्त हो गया है

ट्रस्ट स्टोर समस्या मानने से पहले जांच लें।

echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates
# notBefore=...
# notAfter=...

ग्राहक की घड़ी भी सत्यापित करें. बुरी तरह से गलत तारीख वाली एक मशीन वैध प्रमाणपत्रों को अभी तक वैध नहीं या समाप्त होने के रूप में खारिज कर देती है, और यह उन कंटेनरों और वर्चुअल मशीनों को पकड़ लेती है जिन्हें निलंबित कर दिया गया है।

date
timedatectl status    # Linux

निदान अनुक्रम

  1. openssl s_client -connect host:443 -showcerts — सत्यापित रिटर्न कोड पढ़ें
  2. भेजे गए प्रमाणपत्रों की गिनती करें. एक का अर्थ है सर्वर पर एक लापता मध्यवर्ती।
  3. समाप्ति तिथियां और स्थानीय सिस्टम घड़ी जांचें।
  4. किसी अन्य मशीन या नेटवर्क से तुलना करें – यदि यह वहां काम करता है, तो समस्या स्थानीय है।
  5. जांचें कि क्या जारीकर्ता आपका कॉर्पोरेट सीए है, जो अवरोधन का संकेत देता है।
  6. अद्यतनca-certificates और कोई भी भाषा-विशिष्ट बंडल।

सत्यापन को अक्षम क्यों नहीं कर दिया गया

क्योंकि प्रमाणपत्र सत्यापन संपूर्ण तंत्र है जो नेटवर्क पर किसी को उस सर्वर का प्रतिरूपण करने से रोकता है जिसके बारे में आप सोचते हैं कि आप बात कर रहे हैं। इसे अक्षम करने का मतलब है कि कोई भी मध्यस्थ ट्रैफ़िक को पढ़ और संशोधित कर सकता है – जिसमें क्रेडेंशियल, टोकन और आपके द्वारा डाउनलोड किए जा रहे पैकेज शामिल हैं।

यथार्थवादी जोखिम सैद्धांतिक नहीं है. सत्यापन अक्षम के साथ एक सीआई पाइपलाइन ख़ुशी से एक प्रतिरूपित रजिस्ट्री से एक पैकेज स्थापित करेगी। ठीक करने में कुछ मिनट लगते हैं; इसे छोड़ने का परिणाम एक समझौतापूर्ण निर्माण हो सकता है।

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: यह मेरे ब्राउज़र में क्यों काम करता है लेकिन कर्ल में नहीं?
उ: ब्राउज़र पिछले कनेक्शन से मध्यवर्ती प्रमाणपत्रों को कैश करते हैं और गुम हुए प्रमाणपत्रों को स्वचालित रूप से प्राप्त कर सकते हैं। कर्ल ऐसा नहीं करता है, इसलिए यह सर्वर-साइड श्रृंखला समस्या को उजागर करता है जिसे ब्राउज़र छिपाते हैं।

प्रश्न: त्रुटि 20 और त्रुटि 21 के बीच क्या अंतर है?
ए: 21 का मतलब है कि ग्राहक पहले प्रमाणपत्र को सत्यापित नहीं कर सका, आमतौर पर क्योंकि मध्यवर्ती नहीं भेजे गए थे। 20 का मतलब है कि जारीकर्ता आपके स्थानीय ट्रस्ट स्टोर में नहीं मिला।

प्रश्न: मेरे सिस्टम पर सीए बंडल कहां है?
ए: आमतौर पर/etc/ssl/certs/ca-certificates.crt डेबियन और उबंटू पर,/etc/pki/tls/certs/ca-bundle.crt आरएचईएल पर। पायथन में,python -m certifi सर्टिफ़िकेट द्वारा उपयोग किए जाने वाले पथ को प्रिंट करता है।

प्रश्न: क्या केवल स्थानीय विकास के लिए सत्यापन को अक्षम करना सुरक्षित है?
उ: स्व-हस्ताक्षरित प्रमाणपत्र वाले स्थानीय सर्वर के लिए, उस प्रमाणपत्र को अपने ट्रस्ट स्टोर में जोड़ें – इसमें उतना ही समय लगता है और ऐसी आदत नहीं बनती है जो उत्पादन कॉन्फ़िगरेशन में आपका अनुसरण करती है।

प्रश्न: मेरा सीआई काम करता है लेकिन उत्पादन विफल रहता है। क्यों?
उत्तर: आधार छवि में लगभग हमेशा अंतर होता है। पतली और अल्पाइन छवियां अक्सर छोड़ दी जाती हैंca-certificates पूरी तरह से.

निष्कर्ष

इस त्रुटि का मतलब है कि विश्वास की श्रृंखला टूट गई है, और इसके केवल कुछ ही कारण हैं:सर्वर अपने मध्यवर्ती प्रमाणपत्र नहीं भेज रहा है, आपका स्थानीय सीए बंडल गायब है या पुराना हो गया है, एक कॉर्पोरेट प्रॉक्सी अपने स्वयं के सीए के साथ टीएलएस को रोक रहा है, या प्रमाणपत्र समाप्त हो गया है। Diagnose with openssl s_clientसे निदान करें और रिटर्न कोड को सत्यापित करें, फिर वास्तविक कारण को ठीक करें – सीए स्थापित करें, अपडेट करेंca-certificates, या पूरी श्रृंखला परोसें। किसी स्थानीय परीक्षण के बाहर सत्यापन को कभी भी अक्षम न करें, क्योंकि इससे त्रुटि द्वारा प्रदान की जाने वाली सुरक्षा समाप्त हो जाती है।

MD Rafikul Islam

Written by

MD Rafikul Islam is a software developer and the editor of TechPulse. He writes about developer tooling, hardware, and the practical decisions that come up in day-to-day engineering work — which laptop to buy, which framework to commit to, why a build broke at 2am. He tests the tools he writes about and says plainly when something is not worth the money. Corrections and corrections requests are welcome at rony.yf25@gmail.com.

✍️ Leave a Comment

Your email address will not be published. Required fields are marked *

🌐 Read in:🇬🇧 English🇩🇪 Deutsch🇧🇷 Português🇸🇦 العربية🇮🇳 हिन्दी🇧🇩 বাংলা