SSD Nodes Learn
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-07-25

Ubuntu वर self-signed certificate कसे बनवायचे

Ubuntu 24.04 वर Chrome स्वीकारणारे self-signed TLS cert बनवा. SAN सह एकच openssl command, nginx/Apache सेटअप, आणि curl -k न वापरता ते विश्वासार्ह कसे बनवायचे याची सविस्तर माहिती.

तुम्ही काय तयार करत आहात

एक स्व-स्वाक्षरी TLS प्रमाणपत्र ज्याला आधुनिक ब्राउझर आणि क्लायंट वास्तविक स्वीकारतात — योग्य subjectAltName, योग्य की परवानग्या, nginx किंवा Apache मध्ये जोडलेले — तसेच जो भाग जवळजवळ प्रत्येक मार्गदर्शक वगळतो: तुमच्या क्लायंटना ते विश्वासार्ह कसे बनवायचे, त्याऐवजी इशारे दुर्लक्षून स्क्रिप्टमध्ये कायमचरितार्थाने curl -k हार्ड-कोड करण्याची सवय टाळणे. शेवटी, एका आंतरिक सेवेची संख्या सहापर्यंत वाढल्यास, पाच-कमांडचे खाजगी CA वापरण्याची पद्धत.

प्रथम निर्णय, कारण स्व-स्वाक्षरी प्रमाणपत्र हे योग्य साधन त्यापेक्षा क्वचितच वापरले जाते जितक्या वेळा ते वापरले जाते. जर सेवा खर्या DNS नावाखाली सार्वजनिक इंटरनेटवरून पोहोचण्यायोग्य असेल, तर वाचन थांबवा आणि त्याऐवजी nginx वर certbot सह विनामूल्य Let's Encrypt प्रमाणपत्र किंवा Apache समतुल्य पर्याय मिळवा. याला काहीही खर्च येत नाही, ते स्वतःच नूतनीकरण करते, आणि पृथ्वीवरील प्रत्येक ब्राउझर आधीच त्यावर विश्वास ठेवतो. सार्वजनिक साइटवर स्व-स्वाक्षरी प्रमाणपत्र तुमच्या वापरकर्त्यांना सुरक्षा इशारे दुर्लक्ष करायला प्रशिक्षित करते, जी साध्या HTTP पेक्षा वाईट सवय आहे.

जेव्हा चित्रात सार्वजनिक इंटरनेट नसेल तेव्हा स्व-स्वाक्षरी हे योग्य साधन आहे: तुमच्या VPS वर WireGuard टनल पत्त्याशी बांधलेले admin पॅनल, खाजगी नेटवर्कवरील staging बॉक्स, बॅकएंडमधील सेवा-ते-सेवा रहदारी, होम-लॅब अप्लायन्स, किंवा Webmin पोर्ट 10000 वर स्वतःसाठी तयार करते ते प्लेसहोल्डर प्रमाणपत्र बदलणे. Let's Encrypt वैसे तरी 10.8.0.1 किंवा git.internal.lan साठी प्रमाणपत्र जारी करू शकत नाही — कोणताही सार्वजनिक CA खाजगी IP किंवा बनावट TLD प्रमाणपत्रात ठेवणार नाही. त्या नावांसाठी, तुम्हीच CA आहात.

खालील सर्व काही नवीन Ubuntu 24.04 बॉक्सवर चालते, ज्यामध्ये OpenSSL 3.0.x आधीच आलेले आहे (खात्री करण्यासाठी openssl version). याला इंटरनेट कनेक्टिव्हिटीची गरज नाही; हे सर्व एअर-गॅप वातावरणातही कार्य करते.

जुनी एक-ओळीची कमांड का असे प्रमाणपत्र तयार करते जी Chrome नाकारते

2017 पूर्वीचे प्रत्येक ट्यूटोरियल तुम्हाला जी कमांड देते ती अशी दिसते:

# Do not run this — shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

ती कमांड अनेक परस्परसंवादी प्रश्न विचारते. तुमचे hostname ते Common Name फील्डमध्ये ठेवते. आणि subjectAltName extension नसलेले प्रमाणपत्र तयार करते. ते प्रमाणपत्र तयार होताच निकामी असते. Chrome ने आवृत्ती 58 मध्ये, एप्रिल 2017 मध्ये Common Name वाचणे बंद केले. RFC 2818 ने वर्ष 2000 मध्येच CN मॅचिंग वापरणे बंद केले होते. Firefox, Safari, curl आणि Python हे समान वागणूक देतात. एखादे प्रमाणपत्र आपला सर्व्हर SAN extension कडून ओळखते किंवा अजिबात ओळखत नाही. ब्राउझर तुम्हाला हेच त्या शब्दांत सांगतो:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

ट्रस्ट-स्टोरमध्ये काहीही बदल केल्याने ती त्रुटी दूर होत नाही. कारण ते प्रमाणपत्र प्रत्यक्षात काहीच नाव देत नाही. तुम्ही आत्ता NET::ERR_CERT_COMMON_NAME_INVALID कडे बघत असाल, तर तुमच्या प्रमाणपत्रात SAN नाही किंवा चुकीचा आहे. तुम्हाला नवीन प्रमाणपत्र तयार करावे लागेल. आनंदाची गोष्ट म्हणजे उपाय फक्त एकच कमांड आहे.

ब्राउझर स्वीकारतील असे प्रमाणपत्र तयार करा: एकच कमांड

OpenSSL 1.1.1 मध्ये -addext फ्लॅग आला. यामुळे SAN टाकण्यासाठी जुन्या मार्गदर्शकांनी वापरलेल्या कॉन्फिग-फाइलच्या जटिल प्रक्रियेची गरज राहिली नाही. Ubuntu 24.04 वर:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

प्रत्येक फ्लॅग काय करतो:

  • -x509 स्वाक्षरी प्रमाणपत्र थेट तयार करते, स्वाक्षरी विनंती नाही.
  • -newkey rsa:4096 त्याच पायरीत नवीन की तयार करते. RSA 4096 कोणत्याही जुन्या क्लायंटला त्रास देत नाही. जर सर्व कनेक्शन्स आधुनिक असतील, तर -newkey ec -pkeyopt ec_paramgen_curve:P-256 लहान आणि जलद आहे.
  • -noenc हे जुन्या -nodes चे OpenSSL 3.x मधील नवीन लेखन आहे: कीवर कोणताही पासफ्रेज नाही. दोन्ही लेखन काम करतात. पासफ्रेज असलेल्या कीमुळे nginx प्रत्येक बूटवर इनपुटची वाट पाहत अडकते, म्हणून सर्व्हर कीसाठी हेच हवे.
  • -days 730 — दोन वर्षे. या संख्येबद्दल कालबाह्यता विभागात अधिक माहिती आहे.
  • -subj संवादात्मक प्रश्नांची उत्तरे थेट देते. CN आता केवळ दिसण्यासाठी आहे, पण तरीही ते मुख्य नावावर सेट करा. काही साधने ते दर्शवतात.
  • -addext "subjectAltName=..." हा मुख्य फ्लॅग आहे. क्लायंट टाईप करतील असे प्रत्येक नाव आणि प्रत्येक IP यादीत द्या: होस्टनावांसाठी DNS: प्रविष्ट्या (DNS:*.internal.lan सारखे वाइल्डकार्ड चालतात), पत्त्यांसाठी IP: प्रविष्ट्या. जर कोणी https://10.8.0.1 वर ब्राउझ करणार असेल, तर IP:10.8.0.1 प्रविष्टी तिथे असणे आवश्यक आहे — फक्त DNS असलेला SAN त्यांना पुन्हा NET::ERR_CERT_COMMON_NAME_INVALID देईल.

काही जोडण्यापूर्वी SAN खरोखर तयार झाले आहे याची खात्री करा:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

योग्य आउटपुट:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

जर त्याऐवजी ते No extensions in certificate छापेल, तर प्रमाणपत्रात SAN नाही आणि ब्राउझर ते नाकारतील — पुढे जाण्याऐवजी प्रमाणपत्र पुन्हा तयार करा.

की लॉक करा

प्रत्येक वापरकर्त्याला वाचता येईल अशी खाजगी की ही खाजगी की नसते. Ubuntu वर, /etc/ssl/private आधीच 710 root:ssl-cert आहे, जे यादचित्‌त लोकांपासून की लपवते. पण फाईलचे परवानग्या स्पष्टपणे सेट करा:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

nginx आणि Apache दोन्ही प्रमाणगुणवत्ता कमी करण्यापूर्वी प्रमाणपत्रे root म्हणून वाचतात. त्यामुळे त्यांसाठी root:root mode 600 काम करते. जर की ही अशा सेवेसाठी असेल जी स्वतःच्या वापरकर्ता म्हणून चालते आणि की स्वतः लोड करते — उदाहरणार्थ Node ॲप, Gitea किंवा Python डेमन — तर ती त्या सेवा वापरकर्त्याला chown करा, पण mode 600 ठेवाच. जे तुम्ही कधीच करू नये: mode 644, git रिपॉझिटरीमधील प्रत, किंवा /tmp मधील प्रत.

nginx मध्ये त्याची जोडणी करा

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
sudo nginx -t && sudo systemctl reload nginx

nginx -t ने reload कार्य करण्यापूर्वी syntax is ok आणि test is successful हे छापले पाहिजेत. त्याऐवजी जर ते SSL_CTX_use_PrivateKey_file() failed ... key values mismatch छापत असेल, तर प्रमाणपत्र आणि की या दोन वेगवेगळ्या निर्मिती टप्प्यांमधील आहेत — अपयश-प्रकार विभाग पहा.

Apache मध्ये त्याची जोडणी करा

sudo a2enmod ssl proxy proxy_http

ssl येथे एकटेच पुरे होत नाही: खालील vhost ProxyPass वापरते, आणि mod_proxy आणि mod_proxy_http न घातल्यास कॉन्फिग चाचणी Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration सह अयशस्वी होते. vhost ला /etc/apache2/sites-available/git-internal.conf म्हणून सेव्ह करा:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>
sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest ने Syntax OK ला उत्तर द्यावे. आता क्लायंट मशीनवरून चाचणी करा:

curl -v https://git.internal.lan/

आणि तुम्हाला एक त्रुटी मिळेल:

curl: (60) SSL certificate problem: self-signed certificate

ती बग नाही. ती TLS कार्य करत आहे असे दर्शवते: curl ने तुमचे प्रमाणपत्र कधीच पाहिलेले नाही आणि अशा सर्व्हरशी बोलण्यास नकार देते ज्याचे ते प्रमाणीकरण करू शकत नाही. पुढील विभाग हा खरा उपाय आहे — आणि तो असा नाही जसा याच क्षणी निम्म्या इंटरनेटवर केला जात आहे.

क्लायंटना ते विश्वासार्ह बनवा — आणि नाकारायच्या अँटी-पॅटर्न

आधी चुकीचे उपाय, त्यांच्या वास्तविक नावानुसार. स्क्रिप्टमध्ये बसवलेले curl -k (किंवा --insecure), Python requests मधील verify=False, Node मधील NODE_TLS_REJECT_UNAUTHORIZED=0 — यापैकी कोणताही उपाय तुमचे प्रमाणपत्र विश्वासार्ह बनवत नाही. हे प्रमाणपत्र तपासणे बंद करतात. त्यामुळे क्लायंट कोणत्याही सर्व्हरने दिलेले कोणतेही प्रमाणपत्र स्वीकारतो, ज्यात हल्लेखोराने दिलेले प्रमाणपत्रही समाविष्ट आहे. तुम्हाला TLS चा ताण तर सहन करावा लागतो, पण त्याचा मुख्य उद्देश असलेली ओळख पटवण्याची प्रक्रिया गमावता. परिस्थिती अधिक बिकट होते कारण हे फ्लॅग पसरत जातात: एका cron job मध्ये टाकले, नंतर deploy स्क्रिप्टमध्ये, नंतर production कोडमध्ये, आणि शेवटी कोणालाच कोणते कनेक्शन तात्पुरते होते हे आठवत नाही. जर verify=False ते तयार करणाऱ्या डीबगिंग सत्रानंतरही टिकून राहिला, तर रचना चुकीची आहे.

योग्य उपाय म्हणजे प्रत्येक क्लायंट OS ला हे प्रमाणपत्र एक विश्वासार्ह रूट आहे असे शिकवणे. Ubuntu आणि Debian क्लायंटवर:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

आउटपुटमध्ये महत्त्वाची असलेली ओळ (त्यानंतर एक Running hooks in /etc/ca-certificates/update.d... ब्लॉक येतो):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

या ओळींमध्ये दोन अडचणी दडलेल्या आहेत. फाईलची एक्स्टेंशन नक्की .crt असावी — .pem एक्स्टेंशन शांतपणे दुर्लक्षिले जाते आणि तुम्हाला कोणताही एरर मेसेज न देता 0 added मिळते. आणि फाईलची सामग्री PEM स्वरूपात असावी — फाईल -----BEGIN CERTIFICATE----- पासून सुरू होते; DER बायनरी फाईल आधी openssl x509 -inform der -in file.der -out file.crt वापरून रूपांतरित करा. स्व-स्वाक्षरी प्रमाणपत्र रूट म्हणून स्वतःच समाविष्ट करणे काम करते कारण स्व-स्वाक्षरी प्रमाणपत्र स्वतःच रूट असते.

यानंतर, curl, wget, git, apt, आणि सिस्टम बंडलवरून OpenSSL वापरणारे इतर कोणतेही क्लायंट कोणताही फ्लॅग न वापरता सर्व्हरवर विश्वास करतात. काही क्लायंट त्यांचे स्वतःचे ट्रस्ट स्टोअर वापरतात आणि त्यांना स्वतंत्र उपाय लागतात:

  • Linux वरील Chrome/Chromium सिस्टम स्टोअर वापरत नाही, तर NSS डेटाबेस वाचतो: sudo apt install libnss3-tools, नंतर प्रत्येक वापरकर्त्यासाठी certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt.
  • Firefox चे स्वतःचे स्टोअर आहे: Settings → Privacy & Security → Certificates → Import, किंवा about:config मध्ये security.enterprise_roots.enabled ला true करा जेणेकरून ते सिस्टम स्टोअर वाचेल.
  • Python requests स्वतःचा CA बंडल (certifi) वापरते आणि सिस्टम स्टोअरकडे दुर्लक्ष करते: verify="/usr/local/share/ca-certificates/git.internal.crt" पास करा किंवा REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt एक्सपोर्ट करा.
  • Node.js: NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt एक्सपोर्ट करा.

Windows क्लायंटवर, .crt वर डबल-क्लिक करा आणि ते Trusted Root Certification Authorities मध्ये इंस्टॉल करा; macOS वर, Keychain Access मध्ये ते System keychain मध्ये समाविष्ट करा आणि ते Always Trust म्हणून चिन्हांकित करा.

अनेक सेवांसाठी एकच मूळ: एक लहान खाजगी CA

प्रत्येक-प्रमाणपत्रावर आधारित विश्वास लगेच मर्यादेत अडकतो: सहा सेवांचा आणि चार क्लायंट मशीनचा गुणाकार म्हणजे चोवीस विश्वास-स्थापना होतात, आणि प्रत्येक नवीन सेवा यात भर घालते. यावर उपाय म्हणजे खाजगी CA — क्लायंट फक्त एका मूळावर विश्वास ठेवतात, आणि तुम्ही प्रत्येक सेवेचे प्रमाणपत्र त्याने साइन करता.

सोपा पर्याय म्हणजे mkcert, जे Ubuntu 24.04 रेपॉजिटरींमध्ये उपलब्ध आहे आणि ते NSS स्टोअर (Chrome, Firefox) हाताळते, जे update-ca-certificates वगळते:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install एक मूळ तयार करते आणि त्या मशीनवरील प्रत्येक ट्रस्ट स्टोअरमध्ये ते नोंदवते; तिसरी कमांड git.internal.lan+2.pem आणि git.internal.lan+2-key.pem तयार करते, जे वरील nginx किंवा Apache स्निपेट्समध्ये थेट वापरता येतील. याची मूळभूत गृहीतक म्हणजे ही एक डेव्हलपमेंट मशीन आहे — मूळ की त्याच बॉक्सवर राहते ज्यावर -install चालवले गेले — म्हणून हे डेव्हलपमेंट लॅपटॉपसाठी उत्तम आहे आणि सर्व्हर फ्लीटसाठी अयोग्य आहे.

सर्व्हरसाठी, साधे OpenSSL पाच कमांडमध्ये संपूर्ण CA तयार करते:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

सर्वात मोठा संकट शेवटच्या कमांडमध्ये आहे: openssl x509 -req डीफॉल्टनुसार CSR मधील सर्व एक्सटेंशन्स वगळते, ज्यात तुम्ही काळजीपूर्वक सामील केलेला SAN सुद्धा समाविष्ट आहे. -copy_extensions copy (एक OpenSSL 3.x पर्याय, म्हणून ते 24.04 वर काम करते) त्यांना पुढे नेते; तो वगळल्यास साइन केलेल्या प्रमाणपत्रात SAN असणार नाही, आणि Chrome पुन्हा NET::ERR_CERT_COMMON_NAME_INVALID सह तुमचे स्वागत करेल. आधीच्याप्रमाणेच openssl x509 -noout -ext subjectAltName तपासणीने हे तपासा.

lab-ca.crt क्लायंट्सवर वरील ट्रस्ट-स्टोअर स्टेप्सद्वारे वितरीत करा — प्रति मशीन एकदाच, कायमचे. lab-ca.key ला त्याच्या अत्यंत महत्त्वानुसार संरक्षित करा: मोड 600, आणि आदर्शपणे ती अशा बॉक्सवर ठेवा जो त्या सर्व्हरपैकी एक नाही ज्यांसाठी ते साइन करते, कारण ज्याच्याकडे ती आहे तो तुमच्या क्लायंट ज्या कोणत्याही नावावर विश्वास ठेवतील त्यासाठी प्रमाणपत्र तयार करू शकतो.

समाप्ती आणि रोटेशन

सार्वजनिक CA प्रमाणपत्रांचा कालावधी कमी होत आहे — CA/Browser Forum ने मार्च 2026 मध्ये नव्याने जारी केलेली सार्वजनिक विश्वासार्ह प्रमाणपत्रे 200 दिवसांपुरती मर्यादित केली (आधीच्या 398 पासून कमी). 2027 मध्ये ही मर्यादा 100 दिवसांवर आणि मार्च 2029 पर्यंत 47 दिवसांवर येईल — पण हे नियम फक्त सार्वजनिक विश्वासार्ह CA ला बांधतात. तुमच्या खाजगी CA वर या नियमांचा बंधनार्ह परिणाम होत नाही. आणि ब्राउझर हे नियम मॅन्युअली इंस्टॉल केलेल्या रूटवर लागू करत नाहीत. एक व्यावहारिक मर्यादा लागू होते: Apple प्लॅटफॉर्म 825 दिवसांहून अधिक कालावधीची TLS सर्व्हर प्रमाणपत्रे नाकारतात, कोणीही जारी केलेली असली तरी. म्हणून iPhone किंवा Mac जोडले जाणार असतील, तर लीफ प्रमाणपत्रे दोन वर्षांपुरतीच ठेवा. -days 730 ही मर्यादा सर्वत्र पूर्ण करते; दहा वर्षांचे रूट आणि दोन वर्षांच्या लीफसह एक आरामदायक अंतर्गत रचना तयार होते.

दीर्घकाळ टिकणारी प्रमाणपत्रे एकाच प्रकारे अपयशी ठरतात: शांतपणे, एकाच वेळी, एका अशा तारखेला जी कोणी निवडली होती असे कोणालाही आठवत नाही. तुमच्याकडे असलेले तपासा:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

रिन्युअल एका वास्तविक कॅलेंडरमध्ये ठेवा, किंवा cron ला 30 दिवस आधी सूचित करायला लावा — openssl x509 -checkend 2592000 -in cert.crt समाप्ती इतक्या सेकंदांच्या आत असल्यास नॉन-झिरो स्टेटससह बाहेर पडते. तुम्ही आधीच Uptime Kuma स्टेटस मॉनिटरिंगसाठी चालवत असाल, तर त्याचे HTTPS मॉनिटर विनामूल्य जवळ येणाऱ्या प्रमाणपत्र समाप्तीचा संकेत देतात.

खाजगी CA सह रोटेशन अगदी साधे आहे: CSR-आणि-साईन कमांड पुन्हा चालवा, फायली बदला, वेब सर्व्हर रीलोड करा. रूट बदललेले नाही, म्हणून कोणत्याही क्लाएंटला काही जाणवत नाही.

अपयशाच्या पद्धती, आणि तुम्हाला दिसणाऱ्या स्ट्रिंग्ज

NET::ERR_CERT_AUTHORITY_INVALID — ही trust इंस्टॉल करण्यापूर्वीची अपेक्षित स्थिती आहे, प्रमाणपत्रातील दोष नाही. तुम्ही root इंस्टॉल केल्यानंतरही ही स्थिती टिकून राहिल्यास: Linux वर, Chrome सिस्टम स्टोअरऐवजी NSS वाचते (certutil हा टप्पा पहा); किंवा कॉपी केलेल्या फाईलच्या शेवटी .crt नाही आणि update-ca-certificates ने 0 added असे म्हटले; किंवा सर्व्हर तुम्ही विश्वास ठेवलेल्या प्रमाणपत्रापेक्षा वेगळे प्रमाणपत्र सादर करत आहे — openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 सह फिंगरप्रिंट्स तुलना करा.

NET::ERR_CERT_COMMON_NAME_INVALID — प्रमाणपत्रात SAN नाही, किंवा SAN अॅड्रेस बारमधील नावाव्यतिरिक्त आहे. सर्वसामान्य उदाहरण: SAN मध्ये DNS:git.internal.lan सूचीबद्ध आहे, पण वापरकर्ता https://10.8.0.1 ला ब्राउझ करत आहे. Trust-store बदलणे हे या समस्येचे निराकरण करू शकत नाही; न आढळलेली नोंद जोडून प्रमाणपत्र पुन्हा जारी करा.

curl: (60) SSL certificate problem: self-signed certificate — curl ला प्रमाणपत्रावर विश्वास नाही. self-signed certificate in certificate chain हा प्रकार तुमच्या खाजगी CA ने स्वाक्षरी केलेल्या प्रमाणपत्रासाठी समान अर्थ दर्शवतो. एकवेळचा उपाय: curl --cacert lab-ca.crt https://...; कायमस्वरूपी उपाय: trust store. -k नाही.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (किंवा Expecting: CERTIFICATE REQUEST, किंवा no start line) — PEM मधील गोंधळ. तुम्ही OpenSSL ला चुकीच्या प्रकारची फाईल दिली: जिथे प्रमाणपत्र अपेक्षित होते तिथे key किंवा CSR, किंवा जिथे PEM अपेक्षित होते तिथे DER बायनरी. head -1 filename तुमच्याकडे असलेली फाईल कोणत्या प्रकारची आहे हे सांगते — प्रमाणपत्र -----BEGIN CERTIFICATE----- पासून सुरू होते. DER साठी, openssl x509 -inform der -in file.der -out file.crt सह रूपांतर करा.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch) — प्रमाणपत्र आणि key एकत्र जोडी नाहीत, सामान्यतः कारण जनरेशन कमांड दोनदा चालवले गेले आणि फायली एकमेकांत मिसळल्या. openssl x509 -in git.internal.crt -noout -pubkey | sha256sum आणि openssl pkey -in git.internal.key -pubout | sha256sum च्या तुलनेने खात्री करा; जुळणारे हॅश म्हणजे जुळणारी जोडी. त्या वेगळे असल्यास, दोन्ही एकत्र पुन्हा तयार करा.

FAQ

स्वतः-स्वाक्षरीत प्रमाणपत्र तयार केल्यानंतरही Chrome का अजून "Not secure" असे सांगते?

त्रुटी NET::ERR_CERT_AUTHORITY_INVALID असल्यास, प्रमाणपत्र योग्य आहे — Chrome ला अद्याप त्यावर विश्वास ठेवण्याचे कारण नाही. क्लायंटच्या ट्रस्ट स्टोअरमध्ये ते (किंवा तुमचे खाजगी CA रूट) इंस्टॉल करा. Linux वर Chrome certutil द्वारे NSS डेटाबेस वापरते, सिस्टम स्टोअर वापरत नाही हे लक्षात ठेवा. त्रुटी NET::ERR_CERT_COMMON_NAME_INVALID असल्यास, प्रमाणपत्रात URL शी जुळणारा Subject Alternative Name नाही आणि ते -addext "subjectAltName=..." सह पुन्हा जारी करावे लागेल.

curl ला -k वापरल्याशिवाय स्वतः-स्वाक्षरीत प्रमाणपत्रावर विश्वास ठेवण्यास कसे लावावे?

प्रमाणपत्र (PEM स्वरूप, .crt एक्सटेंशन) /usr/local/share/ca-certificates/ मध्ये कॉपी करा आणि sudo update-ca-certificates चालवा — आउटपुटमध्ये 1 added असे दिसले पाहिजे. त्यानंतर curl हे प्रमाणपत्र कोणत्याही सार्वजनिक प्रमाणपत्राप्रमाणे तपासते. सिस्टमला न छुता एकदाच्या विनंतीसाठी, curl --cacert /path/to/cert.crt फक्त त्या फाईलविरुद्ध तपास करते; -k तपास पूर्णपणे बंद करते आणि कोणाच्याही स्क्रिप्टमध्ये ते असू नये.

स्वतः-स्वाक्षरीत प्रमाणपत्र किती काळ वैध असू शकते?

तांत्रिकदृष्ट्या तुम्हाला आवडेल तितके — CA/Browser Forum मर्यादा (आता 200 दिवस, 2029 पर्यंत 47) सार्वजनिक विश्वासू CA ला बांधतात, खाजगी विश्वासाला नाही. व्यवहारात, सर्व्हर प्रमाणपत्रे 825 दिवसांपुरती मर्यादित ठेवा, कारण Apple डिव्हाइसेस जारीकर्त्याची पर्वा न करता यापेक्षा जास्त कालावधीचे प्रमाणपत्र नाकारतात. दहा वर्षांचे खाजगी रूट आणि दोन वर्षांची (-days 730) लीफ प्रमाणपत्रे हा एक योग्य डिफॉल्ट आहे; फक्त नूतनीकरणाची तारीख नोंदवून ठेवा, कारण कोणालाही आठवत नसलेल्या तारखेला कालबाह्य झालेले आंतरिक प्रमाणपत्र सर्व गोष्टी शांतपणे बंद करून टाकते.

मी स्वतः-स्वाक्षरीत प्रमाणपत्र वापरावे की Let's Encrypt?

सेवेचे सार्वजनिक DNS नाव असेल आणि ती इंटरनेटवरून पोहोचण्यायोग्य असेल, तर नेहमी Let's Encrypt वापरा — मोफत, स्वयंचलित, प्रत्येक क्लायंटने आधीच विश्वासू मानलेले. स्वतः-स्वाक्षरीत (किंवा खाजगी CA) त्यासाठी आहे जे Let's Encrypt जारी करू शकत नाही: खाजगी IP, फक्त आंतरिक होस्टनेम जसे की .lan, एर-गॅप्ड नेटवर्क, आणि जाणीवपूर्वक VPN मागे लपवलेल्या सेवा. हा निर्णय पोहोचण्यायोग्यता आणि नामकरणावर आधारित आहे, सुरक्षा क्षमतेवर नाही — क्रिप्टोग्राफी समान आहे.

/usr/local/share/ca-certificates मध्ये प्रमाणपत्र जोडल्यानंतरही माझे प्रमाणपत्र का नाकारले जाते?

तीन गोष्टी तपासा. फाईलच्या शेवटी .crt असले पाहिजे — .pem एक्सटेंशन शांतपणे वगळले जाते आणि update-ca-certificates 0 added असे दर्शवते. सामग्री -----BEGIN CERTIFICATE----- ने सुरू होणारी PEM मजकूर असली पाहिजे, DER बायनरी नाही. आणि अनुप्रयोगाने प्रत्यक्षात सिस्टम स्टोअर वापरले पाहिजे — Linux वर Chrome, Firefox, Python requests, Node.js, आणि Java प्रत्येक एक खाजगी ट्रस्ट स्टोअर ठेवतात आणि त्यांना प्रमाणपत्र वेगळे जोडावे लागते.

#openssl#tls#self-signed#ubuntu#security