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

Ubuntu 24.04 वर Chrome-मान्य self-signed TLS certificate

Ubuntu 24.04 वर SAN सह openssl वापरून Chrome स्वीकारेल असे self-signed TLS certificate तयार करा, nginx किंवा Apache जोडा आणि curl -k न वापरता trust निर्माण करा.

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

आधुनिक browsers आणि clients प्रत्यक्षात स्वीकारतील असे self-signed TLS certificate, योग्य subjectAltName, सुरक्षित key permissions, तसेच nginx किंवा Apache मध्ये केलेले integration. यासोबत जवळजवळ प्रत्येक मार्गदर्शिकेत वगळला जाणारा भागही असेल: warnings वर click करून पुढे जाण्याऐवजी आणि scripts मध्ये curl -k कायम hard-code करण्याऐवजी clients कडून या certificate वर योग्य प्रकारे trust निर्माण करणे. शेवटी, एक internal service वाढून सहा services झाल्यास वापरता येईल असा five-command private CA तयार कराल.

सर्वप्रथम निर्णय घ्या, कारण self-signed certificate ज्या ठिकाणी योग्य असतो त्यापेक्षा जास्त ठिकाणी वापरला जातो. सेवा public internet वर real DNS name द्वारे उपलब्ध असेल, तर पुढे वाचू नका. त्याऐवजी nginx वर certbot सह मोफत Let's Encrypt certificate मिळवा किंवा Apache साठीचा समतुल्य मार्ग वापरा. त्यासाठी कोणताही खर्च येत नाही, certificate आपोआप renew होते आणि जगभरातील प्रत्येक browser त्यावर आधीपासून trust ठेवतो. Public site वर self-signed certificate वापरल्यास users ना security warnings कडे दुर्लक्ष करून पुढे जाण्याची सवय लागते. ही सवय plain HTTP वापरण्यापेक्षा अधिक धोकादायक आहे.

Public internet उपलब्ध नसताना self-signed certificate योग्य ठरते. उदाहरणार्थ, तुमच्या VPS वरील WireGuard tunnel address ला bind केलेले admin panel, private network वरील staging box, backends मधील service-to-service traffic, home-lab appliance किंवा Webmin स्वतः port 10000 वर तयार करत असलेले placeholder certificate बदलण्यासाठी ते वापरता येते. Let's Encrypt 10.8.0.1 किंवा git.internal.lan साठी certificate जारी करू शकत नाही. कोणतीही public CA private IP किंवा बनावट TLD certificate मध्ये समाविष्ट करणार नाही. अशा नावांसाठी तुम्हीच CA असता.

खालील सर्व प्रक्रिया fresh Ubuntu 24.04 box वर चालते. त्यामध्ये OpenSSL 3.0.x समाविष्ट आहे (पुष्टी करण्यासाठी openssl version). येथे internet access ची आवश्यकता नाही; ही संपूर्ण प्रक्रिया air-gapped वातावरणातही चालते.

जुनी one-liner Chrome नाकारत असलेली प्रमाणपत्रे का तयार करते

2017 पूर्वीच्या प्रत्येक tutorial मध्ये दिलेली command अशी दिसते:

# 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 field मध्ये ठेवते आणि कोणत्याही subjectAltName extension शिवाय certificate तयार करते. असे certificate सुरुवातीपासूनच निरुपयोगी असते. Chrome ने एप्रिल 2017 मध्ये version 58 पासून Common Name वाचणे बंद केले. RFC 2818 ने त्यापूर्वीच, 2000 मध्ये, CN matching deprecated केले होते. Firefox, Safari, curl आणि Python यांचे वर्तनही असेच आहे. Certificate आपल्या server ची ओळख SAN extension द्वारे करते; अन्यथा ते server ची ओळख करत नाही. Browser हे अगदी पुढील शब्दांत सांगतो:

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.

Trust store मध्ये कितीही बदल केले तरी ही error दूर होत नाही, कारण certificate मध्ये प्रत्यक्षात कोणत्याही नावाची नोंद नसते. तुम्हाला सध्या NET::ERR_CERT_COMMON_NAME_INVALID दिसत असल्यास, तुमच्या certificate मध्ये SAN नाही किंवा चुकीचा SAN आहे. त्यामुळे नवीन certificate तयार करणे आवश्यक आहे. सुदैवाने, यासाठी एकच command पुरेशी आहे.

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

OpenSSL ने 1.1.1 मध्ये -addext flag समाविष्ट केला. त्यामुळे जुन्या मार्गदर्शकांमध्ये SAN समाविष्ट करण्यासाठी वापरले जाणारे config-file मधील गुंतागुंतीचे बदल आता आवश्यक नाहीत. 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"

प्रत्येक flag काय करतो:

  • -x509 signing request ऐवजी थेट self-signed certificate तयार करतो.
  • -newkey rsa:4096 त्याच टप्प्यात नवीन key तयार करतो. RSA 4096 मुळे जुन्या client ला अडचण येत नाही; जोडणारे सर्व client आधुनिक असतील, तर -newkey ec -pkeyopt ec_paramgen_curve:P-256 अधिक लहान आणि जलद आहे.
  • -noenc हा OpenSSL 3.x मधील जुन्या -nodes चा पर्याय आहे: key वर passphrase ठेवत नाही. दोन्ही पद्धती चालतात. passphrase असलेल्या key मुळे प्रत्येक boot वेळी nginx input ची वाट पाहत थांबतो. त्यामुळे server key साठी हा पर्याय वापरा.
  • -days 730 म्हणजे दोन वर्षे; त्या संख्येबद्दल expiry विभागात अधिक माहिती आहे.
  • -subj interactive प्रश्नांची उत्तरे command मध्येच देतो. आता CN केवळ दर्शनी स्वरूपाचे आहे, तरी ते primary name वर सेट करा; काही tools ते दाखवतात.
  • -addext "subjectAltName=..." हा अत्यावश्यक flag आहे. client ज्या प्रत्येक name आणि प्रत्येक IP चा वापर करतील, ते सर्व समाविष्ट करा: hostname साठी DNS: entries वापरा (DNS:*.internal.lan सारखे wildcards चालतात) आणि address साठी IP: entries वापरा. कोणी https://10.8.0.1 वर browse करणार असेल, तर IP:10.8.0.1 entry असणे आवश्यक आहे. केवळ DNS असलेला SAN वापरल्यास पुन्हा त्यांना NET::ERR_CERT_COMMON_NAME_INVALID हीच समस्या येईल.

काहीही configuration करण्यापूर्वी SAN प्रत्यक्षात certificate मध्ये समाविष्ट झाला आहे का ते तपासा:

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

योग्य output:

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

त्याऐवजी No extensions in certificate दिसत असेल, तर certificate मध्ये SAN नाही. पुढे जाण्याऐवजी certificate पुन्हा तयार करा.

कळीवर प्रवेश मर्यादित करा

सर्व वापरकर्त्यांना वाचता येणारी private key ही private key राहत नाही. Ubuntu मध्ये, /etc/ssl/private आधीच 710 root:ssl-cert असते. त्यामुळे अनधिकृत पाहणी टाळता येते. तरीही फाइलच्या permissions स्पष्टपणे सेट करा:

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

nginx आणि Apache दोन्ही privileges कमी करण्यापूर्वी certificates root म्हणून वाचतात. त्यामुळे root:root mode 600 त्यांच्यासाठी पुरेसे आहे. जर key स्वतःच्या user म्हणून चालणारी सेवा स्वतःच लोड करत असेल, उदाहरणार्थ Node app, Gitea किंवा Python daemon, तर chown त्याऐवजी त्या service user कडे द्या आणि mode 600 ठेवा. हे कधीही करू नका: mode 644 ठेवू नका, git repository मध्ये copy ठेवू नका आणि /tmp मध्ये copy ठेवू नका.

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

Reload करण्यापूर्वी nginx -t ने syntax is ok आणि test is successful प्रिंट करणे आवश्यक आहे. त्याऐवजी SSL_CTX_use_PrivateKey_file() failed ... key values mismatch प्रिंट झाल्यास, certificate आणि key वेगवेगळ्या generation run मधील आहेत. failure-modes विभाग पाहा.

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

sudo a2enmod ssl proxy proxy_http

ssl येथे एकट्याने पुरेसे नाही: खालील vhost मध्ये ProxyPass वापरले आहे. mod_proxy आणि mod_proxy_http नसल्यास config चाचणी 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 ला प्रतिसाद द्यावा. आता client मशीनवरून चाचणी करा:

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

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

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

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

क्लायंटना त्यावर विश्वास ठेवायला शिकवा आणि टाळावयाचे चुकीचे नमुने

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

योग्य उपाय म्हणजे प्रत्येक client OS ला हे certificate trusted root असल्याचे शिकवणे. Ubuntu आणि Debian clients वर:

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

Output मधील महत्त्वाची ओळ खालीलप्रमाणे आहे (त्यानंतर Running hooks in /etc/ca-certificates/update.d... block येतो):

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

या ओळींमध्ये दोन बाबी लक्षात घ्याव्या लागतात. File चा शेवट .crt नेच झाला पाहिजे. .pem extension असलेली file कोणताही error message न देता दुर्लक्षित केली जाते आणि तुम्हाला 0 added मिळते. तसेच contents PEM स्वरूपातील असणे आवश्यक आहे; file ची सुरुवात -----BEGIN CERTIFICATE----- ने होते. DER binary चे रूपांतर आधी openssl x509 -inform der -in file.der -out file.crt ने करा. Self-signed certificate स्वतः root म्हणून जोडणे योग्य आहे, कारण self-signed certificate स्वतःचेच root असते.

यानंतर curl, wget, git, apt आणि system bundle विरुद्ध OpenSSL वापरणारे इतर कोणतेही clients कोणतेही flags न देता server वर विश्वास ठेवतात. काही clients स्वतःची trust stores वापरतात. त्यांच्यासाठी स्वतंत्र configuration आवश्यक आहे:

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

Windows clients वर .crt वर double-click करा आणि ते Trusted Root Certification Authorities मध्ये install करा. macOS वर ते Keychain Access मधील System keychain मध्ये जोडा आणि Always Trust म्हणून mark करा.

अनेक सेवांसाठी एकच root: छोटी private CA

प्रत्येक प्रमाणपत्रावर स्वतंत्र trust ठेवण्याची पद्धत लगेच मोठी आणि अव्यवहार्य होते: सहा सेवा आणि चार client machines म्हणजे चोवीस trust installs, आणि प्रत्येक नवीन सेवेमुळे ही संख्या वाढते. उपाय म्हणजे private CA. Clients फक्त एका root वर trust ठेवतात आणि तुम्ही तिच्या मदतीने प्रत्येक सेवेचे प्रमाणपत्र sign करता.

सोप पर्याय म्हणजे mkcert. हे Ubuntu 24.04 repos मध्ये उपलब्ध आहे आणि update-ca-certificates ज्या NSS stores हाताळत नाही तेही हाताळते, म्हणजे Chrome आणि Firefox:

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

mkcert -install root तयार करते आणि त्या मशीनवरील प्रत्येक trust store मध्ये ती register करते. तिसरी command git.internal.lan+2.pem आणि git.internal.lan+2-key.pem तयार करते. ही nginx किंवा Apache मधील वरील snippets मध्ये ठेवण्यासाठी तयार असतात. याची रचना development machine गृहीत धरते. Root key -install ज्या box वर चालवले गेले त्याच्यावर राहते. त्यामुळे हे dev laptop साठी योग्य आहे; मात्र server fleet साठी ही योग्य रचना नाही.

Servers साठी plain OpenSSL पाच commands मध्ये संपूर्ण 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

शेवटच्या command मध्ये एक महत्त्वाचा धोका आहे: openssl x509 -req default ने CSR मधील सर्व extensions काढून टाकते, यात तुम्ही काळजीपूर्वक जोडलेला SAN देखील येतो. -copy_extensions copy ही OpenSSL 3.x option आहे, त्यामुळे ती 24.04 वर कार्य करते आणि extensions पुढे नेते. ती वगळल्यास signed certificate मध्ये SAN राहत नाही आणि Chrome पुन्हा NET::ERR_CERT_COMMON_NAME_INVALID दाखवते. आधीप्रमाणेच openssl x509 -noout -ext subjectAltName check वापरून पडताळणी करा.

वरील trust-store steps वापरून lab-ca.crt clients वर वितरित करा. प्रत्येक machine साठी हे आयुष्यातून एकदाच करावे लागते. आता lab-ca.key अत्यंत मौल्यवान private key प्रमाणे सुरक्षित ठेवा: mode 600 वापरा आणि शक्य असल्यास ती ज्या servers साठी certificates sign करते त्यांपैकी कोणत्याही server वर ठेवू नका. कारण ती ज्याच्या ताब्यात असेल तो clients विश्वास ठेवतील अशा कोणत्याही नावासाठी certificate तयार करू शकतो.

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

सार्वजनिक CA प्रमाणपत्रांची वैधता झपाट्याने कमी होत आहे. CA/Browser Forum ने मार्च 2026 मध्ये नव्याने जारी केलेल्या सार्वजनिकरीत्या विश्वसनीय प्रमाणपत्रांची कमाल वैधता 200 दिवसांवर निश्चित केली; ती यापूर्वी 398 दिवस होती. 2027 मध्ये ही मर्यादा 100 दिवसांवर आणि मार्च 2029 पर्यंत 47 दिवसांवर येईल. मात्र हे नियम सार्वजनिकरीत्या विश्वसनीय CA वर लागू होतात. तुमची private CA या नियमांच्या अधीन नाही. तसेच manually installed root विरुद्ध browsers ही मर्यादा लागू करत नाहीत. एक प्रत्यक्ष मर्यादा मात्र लागू होते: प्रमाणपत्र कोणीही जारी केले असले तरी 825 दिवसांपेक्षा जास्त वैध असलेले कोणतेही TLS server certificate Apple platforms नाकारतात. त्यामुळे iPhones किंवा Macs जोडले जाणार असतील, तर leaf certificates ची वैधता दोन वर्षे किंवा त्यापेक्षा कमी ठेवा. -days 730 ही मर्यादा सर्वत्र पूर्ण करते; दहा वर्षांचा root आणि दोन वर्षांचे leaves ही अंतर्गत वापरासाठी सोयीची रचना आहे.

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

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

Renewal प्रत्यक्ष calendar मध्ये नोंदवा किंवा 30 दिवस आधी सूचना देण्यासाठी cron वापरा. मुदत समाप्तीसाठी उरलेला कालावधी त्या संख्येइतक्या सेकंदांपेक्षा कमी झाल्यावर openssl x509 -checkend 2592000 -in cert.crt non-zero exit करते. तुम्ही आधीपासून स्थितीच्या monitoring साठी Uptime Kuma चालवत असाल, तर त्याचे HTTPS monitors येणारी certificate expiry विनामूल्य दाखवतात.

private CA सह रोटेशन कंटाळवाणे नसते: CSR-and-sign commands पुन्हा चालवा, files बदला आणि web server reload करा. root बदललेला नसल्यामुळे कोणत्याही client ला याची जाणीव होत नाही.

दोषस्थिती आणि दिसणारे संदेश

NET::ERR_CERT_AUTHORITY_INVALID, trust स्थापित करण्यापूर्वी अपेक्षित असलेली स्थिती आहे; प्रमाणपत्रातील दोष नाही. root स्थापित केल्यानंतरही ती कायम राहिल्यास: Linux वर Chrome system store ऐवजी NSS वाचतो (certutil पायरी पहा); किंवा कॉपी केलेली फाइल .crt ने संपत नाही आणि update-ca-certificates ने 0 added असे सांगितले; किंवा सर्व्हरने तुम्ही trust केलेल्या प्रमाणपत्राऐवजी वेगळे प्रमाणपत्र सादर केले आहे. fingerprints ची तुलना 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 मध्ये address bar मधील नाव समाविष्ट नाही. नेहमीचे उदाहरण: SAN मध्ये DNS:git.internal.lan आहे, पण वापरकर्त्याने https://10.8.0.1 उघडले. trust-store मधील बदलांनी ही समस्या सुटत नाही; नसलेली entry समाविष्ट करून प्रमाणपत्र पुन्हा जारी करा.

curl: (60) SSL certificate problem: self-signed certificate, curl ला प्रमाणपत्रावर trust नाही. self-signed certificate in certificate chain हा variant private 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 binary दिले आहे. तुमच्याकडे प्रत्यक्षात काय आहे हे 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 एकमेकांशी संबंधित नाहीत. बहुतेकदा generation command दोनदा चालवली जाते आणि फाइल्सची अदलाबदल होते. openssl x509 -in git.internal.crt -noout -pubkey | sha256sum आणि openssl pkey -in git.internal.key -pubout | sha256sum यांची तुलना करून पडताळा; hashes जुळत असल्यास जोडी जुळते. ते वेगळे असल्यास दोन्ही पुन्हा एकत्र generate करा.

FAQ

Chrome ने self-signed certificate तयार केल्यानंतरही "Not secure" का दाखवते?

त्रुटी NET::ERR_CERT_AUTHORITY_INVALID असल्यास certificate योग्य आहे. Chrome ला त्यावर विश्वास ठेवण्याचे कारण अजून उपलब्ध नसते. ते certificate किंवा तुमच्या private CA root ला client च्या trust store मध्ये install करा. Linux वर Chrome certutil द्वारे NSS database वापरते; ते system store वापरत नाही. त्रुटी NET::ERR_CERT_COMMON_NAME_INVALID असल्यास certificate मध्ये URL शी जुळणारा Subject Alternative Name नाही. त्यामुळे ते -addext "subjectAltName=..." सह पुन्हा issue करावे लागेल.

-k शिवाय curl ला self-signed certificate वर विश्वास ठेवायला कसे लावावे?

PEM format मधील certificate (.crt extension) /usr/local/share/ca-certificates/ मध्ये copy करा आणि sudo update-ca-certificates चालवा. Output मध्ये 1 added असे दिसले पाहिजे. त्यानंतर curl ते कोणत्याही public certificate प्रमाणे verify करेल. System मध्ये बदल न करता एकदाच request पाठवायची असल्यास curl --cacert /path/to/cert.crt फक्त त्या file विरुद्ध verification करते. -k verification पूर्णपणे बंद करते. ते कोणत्याही script मध्ये वापरू नका.

Self-signed certificate किती काळ valid ठेवता येते?

तांत्रिकदृष्ट्या तुम्हाला हवा तितका काळ ठेवता येतो. CA/Browser Forum च्या मर्यादा, ज्या सध्या 200 days आणि 2029 पर्यंत 47 days आहेत, public trust असलेल्या CA साठी लागू होतात; private trust साठी नाहीत. प्रत्यक्षात server certificates 825 days पर्यंत मर्यादित ठेवा. Issuer कोणताही असला तरी Apple devices त्यापेक्षा जास्त कालावधीचे certificates नाकारतात. दोन वर्षांचे (-days 730) leaf certificates आणि दहा वर्षांचा private root हा योग्य default आहे. Renewal साठी calendar reminder ठेवा. Expired internal certificate मुळे कोणालाही आठवत नसलेल्या तारखेला संपूर्ण व्यवस्था शांतपणे बंद पडू शकते.

Self-signed certificate वापरावे की Let's Encrypt?

सेवेला public DNS name असल्यास आणि ती internet वरून reachable असल्यास नेहमी Let's Encrypt वापरा. ते विनामूल्य आणि automated आहे आणि प्रत्येक client त्यावर आधीपासून विश्वास ठेवतो. Let's Encrypt issue करू शकत नाही अशा ठिकाणी self-signed certificate किंवा private CA वापरा. यामध्ये private IPs, .lan सारखी internal-only hostnames, air-gapped networks आणि VPN मागे मुद्दाम लपवलेल्या services यांचा समावेश होतो. निर्णय security strength वर नाही, तर reachability आणि naming वर आधारित असतो. Cryptography मात्र समान असते.

/usr/local/share/ca-certificates मध्ये certificate add केल्यानंतरही ते reject का होते?

तीन गोष्टी तपासा. File चा शेवट .crt ने झाला पाहिजे. .pem extension असलेल्या file ला शांतपणे skip केले जाते आणि update-ca-certificates मध्ये 0 added दाखवले जाते. Contents हे -----BEGIN CERTIFICATE----- ने सुरू होणारे PEM text असले पाहिजे; DER binary नसावे. तसेच application प्रत्यक्षात system store वापरते का ते तपासा. Linux वरील Chrome, Firefox, Python requests, Node.js आणि Java यांच्याकडे स्वतंत्र trust store असतात. त्यामुळे प्रत्येकामध्ये certificate स्वतंत्रपणे add करावे लागते.

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