SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-01

Ubuntu 24.04లో Chrome అంగీకరించే self-signed TLS cert

Ubuntu 24.04లో Chrome అంగీకరించే self-signed TLS certను SANతో ఒక openssl commandలో సృష్టించండి. nginx లేదా Apacheలో జత చేసి, curl -k లేకుండానే trust చేయండి.

మీరు నిర్మించేది

ఆధునిక బ్రౌజర్లు మరియు క్లయింట్లు వాస్తవంగా అంగీకరించే self-signed TLS certificate, సరైన subjectAltName, సురక్షితమైన key permissions, nginx లేదా Apacheలో అనుసంధానం, అలాగే దాదాపు ప్రతి గైడ్ వదిలివేసే ముఖ్యమైన భాగం: హెచ్చరికలను దాటి క్లిక్ చేయకుండా, scriptsలో శాశ్వతంగా curl -kను hard-code చేయకుండా, మీ క్లయింట్లు దీనిని సరిగ్గా trust చేసేలా చేయడం. చివరలో, ఒక internal service ఆరు servicesగా మారినప్పుడు ఉపయోగించగల ఐదు commandsతో private CA ఉంటుంది.

ముందుగా నిర్ణయం తీసుకోండి. Self-signed certificate సరైన సాధనంగా ఉపయోగపడే సందర్భాలు, ఇది సాధారణంగా ఉపయోగించబడే సందర్భాల కంటే చాలా తక్కువ. Service నిజమైన DNS nameతో public internet ద్వారా అందుబాటులో ఉంటే, ఇక్కడితో ఆపి nginxలో certbotతో ఉచిత Let's Encrypt certificate పొందండి లేదా Apache కోసం సమానమైన విధానాన్ని ఉపయోగించండి. దీనికి ఖర్చు లేదు, ఇది స్వయంచాలకంగా renew అవుతుంది, అలాగే ప్రపంచంలోని ప్రతి browser దీన్ని ఇప్పటికే trust చేస్తుంది. Public siteలో self-signed certificate ఉపయోగిస్తే, మీ users security warningsను దాటి క్లిక్ చేయడం అలవాటు చేసుకుంటారు. ఇది plain HTTP కంటే మరింత ప్రమాదకరమైన అలవాటు.

Public internet సంబంధం లేని సందర్భాల్లో self-signed certificate సరైన సాధనం: మీ VPSలోని WireGuard tunnel addressకు కట్టుబడి ఉన్న admin panel, private networkలోని staging box, backends మధ్య service-to-service traffic, home-lab appliance, లేదా port 10000లో Webmin తన కోసం తానే generate చేసే placeholder certificateను మార్చడం. 10.8.0.1 లేదా git.internal.lan కోసం Let's Encrypt certificate జారీ చేయలేదు. ఏ public CA కూడా private IP లేదా కల్పిత TLDను certificateలో చేర్చదు. ఆ పేర్లకు మీరు CAగా వ్యవహరించాలి.

క్రింద ఉన్న ప్రతిదీ తాజా Ubuntu 24.04 boxపై నడుస్తుంది. ఇందులో OpenSSL 3.0.x వస్తుంది (నిర్ధారించడానికి openssl version). ఇక్కడ internet access అవసరం లేదు. ఇది పూర్తిగా air-gapped వాతావరణంలో కూడా పనిచేస్తుంది.

పాత one-liner Chrome తిరస్కరించే certs ను ఎందుకు తయారు చేస్తుంది

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

ఇది interactive ప్రశ్నల శ్రేణిని అడుగుతుంది, మీ 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 ద్వారా మాత్రమే గుర్తిస్తుంది; లేకపోతే అసలు గుర్తించదు. 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 settings మార్చడం ద్వారా ఆ error పరిష్కారం కాదు, ఎందుకంటే certificate లో నిజంగా ఏ పేరు లేదు. మీరు ప్రస్తుతం NET::ERR_CERT_COMMON_NAME_INVALID ను చూస్తుంటే, మీ certificate లో SAN లేదు లేదా తప్పు SAN ఉంది. మీరు కొత్త certificate ను తయారు చేయాలి. అదృష్టవశాత్తూ, దీనికి ఒక 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లతో కూడా అనుకూలంగా ఉంటుంది. కనెక్ట్ అయ్యే ప్రతిదీ ఆధునికమైనదైతే, -newkey ec -pkeyopt ec_paramgen_curve:P-256 చిన్నదిగా ఉండి వేగంగా పనిచేస్తుంది.
  • -noenc అనేది పాత -nodesకు OpenSSL 3.xలో ఉపయోగించే రూపం: keyపై passphrase ఉండదు. రెండు రూపాలూ పనిచేస్తాయి. Passphrase ఉన్న key వల్ల ప్రతి boot సమయంలో nginx input కోసం వేచి ఉంటుంది. అందువల్ల server key కోసం దీన్నే ఉపయోగించాలి.
  • -days 730 రెండు సంవత్సరాలను సూచిస్తుంది. ఆ సంఖ్య గురించి expiry విభాగంలో మరింత సమాచారం ఉంది.
  • -subj interactive ప్రశ్నలకు inline సమాధానాలను ఇస్తుంది. ప్రస్తుతం CN కేవలం cosmetic అంశం మాత్రమే. అయినప్పటికీ దాన్ని primary nameగా సెట్ చేయండి; కొన్ని tools దాన్ని చూపిస్తాయి.
  • -addext "subjectAltName=..." అత్యంత ముఖ్యమైన flag. Clients టైప్ చేసే ప్రతి nameను, ప్రతి IPను జాబితాలో చేర్చండి: hostnames కోసం DNS: entries (DNS:*.internal.lan వంటి wildcards అనుమతించబడతాయి), addresses కోసం IP: entries. ఎవరైనా https://10.8.0.1కి browse చేస్తే, IP:10.8.0.1 entry తప్పనిసరిగా ఉండాలి. DNS-only SAN ఉపయోగిస్తే మళ్లీ NET::ERR_CERT_COMMON_NAME_INVALID సమస్యనే ఎదుర్కొంటారు.

ఏదైనా configuration చేయడానికి ముందు SAN నిజంగా చేర్చబడిందో నిర్ధారించండి:

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గా ఉంది. ఇది సాధారణంగా ఇతరుల దృష్టికి ఫైల్‌ను దూరంగా ఉంచుతుంది. అయినప్పటికీ, ఫైల్‌పై అనుమతిని స్పష్టంగా సెట్ చేయండి:

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 వాటికి పనిచేస్తుంది. కీని ప్రత్యేక userగా నడిచే service స్వయంగా load చేసుకుంటే, ఉదాహరణకు Node app, Gitea లేదా Python daemon, chown ను ఆ service userకు మార్చండి. mode 600నే ఉంచండి. మీరు ఎప్పుడూ చేయకూడనివి: mode 644 ఉపయోగించడం, git repositoryలో కాపీ ఉంచడం లేదా /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

reload అమలు కావడానికి ముందు nginx -t తప్పనిసరిగా syntax is ok మరియు test is successfulను ప్రింట్ చేయాలి. దాని బదులు SSL_CTX_use_PrivateKey_file() failed ... key values mismatchను ప్రింట్ చేస్తే, certificate మరియు key వేర్వేరు generation runs‌కు చెందినవి. 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 machine నుంచి పరీక్షించండి:

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

అప్పుడు మీకు ఒక లోపం కనిపిస్తుంది:

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

ఇది bug కాదు. TLS సరిగ్గా పనిచేస్తోంది. curlకు మీ certificate గురించి తెలియదు. అందువల్ల authenticate చేయలేని serverతో సంభాషించడానికి అది నిరాకరిస్తుంది. తదుపరి విభాగంలో దీనికి సరైన పరిష్కారం ఉంది. ఈ క్షణంలో internetలో చాలామంది చేస్తున్న విధానం అది కాదు.

క్లయింట్లు దీనిని విశ్వసించేలా చేయడం, తిరస్కరించాల్సిన తప్పు పద్ధతులు

ముందుగా తప్పు పరిష్కారాలను అవి ఏవో స్పష్టంగా చూద్దాం. స్క్రిప్ట్‌లో curl -k (లేదా --insecure) చేర్చడం, Python requestsలో verify=False ఉపయోగించడం, Nodeలో NODE_TLS_REJECT_UNAUTHORIZED=0 ఉపయోగించడం—ఇవేవీ మీ సర్టిఫికేట్‌ను విశ్వసనీయంగా చేయవు. ఇవి సర్టిఫికేట్ ధృవీకరణను ఆపివేస్తాయి. అంటే దాడి చేసేవాడు మార్గంలో ఉంచిన సర్టిఫికేట్‌తో సహా, ఏ సర్టిఫికేట్‌నైనా అందించే ఏ serverతోనైనా client మాట్లాడుతుంది. TLS వల్ల కలిగే overheadను మాత్రం ఉంచుకుని, TLSకు ప్రధాన ఉద్దేశమైన authenticationను కోల్పోతారు. ఇంకా ప్రమాదకరంగా, ఈ flags ఇతరచోట్లకూ వ్యాపిస్తాయి: ఒక cron jobలో అతికించిన తర్వాత deploy scriptలోకి, ఆపై production codeలోకి చేరుతాయి. ఏ connections తాత్కాలికంగా ఉండాల్సిందో ఎవరికీ గుర్తుండదు. దాన్ని సృష్టించిన debugging session ముగిసిన తర్వాత కూడా verify=False కొనసాగితే, ఆ design తప్పు.

సరైన పరిష్కారం ఏమిటంటే, ఈ certificateను trusted rootగా విశ్వసించేలా ప్రతి client OSకు నేర్పడం. Ubuntu మరియు Debian clientsలో:

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

Outputలో ముఖ్యమైన line (దాని తర్వాత Running hooks in /etc/ca-certificates/update.d... block వస్తుంది):

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

ఆ linesలో రెండు ముఖ్యమైన జాగ్రత్తలు ఉన్నాయి. File తప్పనిసరిగా .crtతో ముగియాలి. .pem extensionను మౌనంగా విస్మరిస్తారు, దాంతో error message లేకుండానే 0 added వస్తుంది. Contents PEM formatలో ఉండాలి. File -----BEGIN CERTIFICATE-----తో ప్రారంభమవుతుంది. ముందుగా DER binaryని openssl x509 -inform der -in file.der -out file.crtతో convert చేయండి. Self-signed certificateనే rootగా జోడించడం పనిచేస్తుంది, ఎందుకంటే self-signed certificate తనకు తానే root.

ఆ తర్వాత, curl, wget, git, apt మరియు system bundleకు వ్యతిరేకంగా OpenSSLను ఉపయోగించే ఇతర ఏదైనా, 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 ఎంచుకోండి. లేదా system storeను చదివేలా about:configలో security.enterprise_roots.enabledను trueగా మార్చండి.
  • 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గా గుర్తించండి.

అనేక సేవలకు ఒకే root: చిన్న private CA

ప్రతి certificate పై వేర్వేరుగా trust ఏర్పాటు చేయడం వెంటనే విస్తరించలేని విధంగా మారుతుంది: ఆరు services కు నాలుగు client machines ఉంటే 24 trust installations అవసరం, అలాగే ప్రతి కొత్త service మరిన్ని installations జోడిస్తుంది. దీనికి పరిష్కారం private CA. Clients ఒకే root ను trust చేస్తాయి, మరియు మీరు ప్రతి service యొక్క certificate ను దానితో sign చేస్తారు.

సులభమైన ఎంపిక mkcert. ఇది Ubuntu 24.04 repositories లో ఉంది మరియు 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 ను సృష్టించి, ఆ machine లోని ప్రతి 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 తో మొత్తం CA ను ఐదు commands లో ఏర్పాటు చేయవచ్చు:

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 డిఫాల్ట్‌గా CSR లోని అన్ని extensions ను తొలగిస్తుంది. మీరు జాగ్రత్తగా జోడించిన SAN కూడా ఇందులో ఉంటుంది. -copy_extensions copy (ఇది OpenSSL 3.x option, కాబట్టి 24.04 లో పనిచేస్తుంది) వాటిని certificate కు తీసుకువెళుతుంది. దీన్ని వదిలేస్తే signed certificate లో SAN ఉండదు, మరియు Chrome మళ్లీ NET::ERR_CERT_COMMON_NAME_INVALID చూపిస్తుంది. ముందులాగే అదే openssl x509 -noout -ext subjectAltName check తో ధృవీకరించండి.

పైన పేర్కొన్న trust-store steps ద్వారా lab-ca.crt ను clients కు ప్రతి machine కు ఒక్కసారి మాత్రమే distribute చేయండి. ఇప్పుడు అది అత్యంత కీలకమైనది కాబట్టి lab-ca.key ను అత్యంత జాగ్రత్తగా రక్షించండి: mode 600 ఉంచండి. సాధ్యమైనంత వరకు, అది sign చేసే servers లో ఏదీ కాని box లో ఉంచండి. ఎందుకంటే దాన్ని కలిగి ఉన్న ఎవరైనా, మీ clients నమ్మే ఏ name కోసమైనా certificate ను సృష్టించగలరు.

గడువు ముగింపు మరియు రొటేషన్

పబ్లిక్ CA సర్టిఫికేట్‌ల చెల్లుబాటు వ్యవధులు వేగంగా తగ్గుతున్నాయి. CA/Browser Forum మార్చి 2026లో కొత్తగా జారీ చేసే పబ్లిక్‌గా విశ్వసనీయ సర్టిఫికేట్‌ల గరిష్ఠ వ్యవధిని 200 రోజులకు పరిమితం చేసింది (ఇది మునుపటి 398 రోజుల నుంచి తగ్గింది). ఈ పరిమితి 2027లో 100 రోజులకు, మార్చి 2029 నాటికి 47 రోజులకు తగ్గుతుంది. అయితే ఈ నియమాలు పబ్లిక్‌గా విశ్వసనీయ CAలకు మాత్రమే వర్తిస్తాయి. మీ private CAపై ఇవి వర్తించవు. Manually installed rootsపై browsers కూడా ఈ పరిమితులను అమలు చేయవు. వాస్తవంగా వర్తించే ఒక పరిమితి ఉంది: సర్టిఫికేట్‌ను ఎవరు జారీ చేసినా, 825 రోజులకు మించి చెల్లుబాటు అయ్యే ఏ TLS server certificateనైనా Apple platforms తిరస్కరిస్తాయి. కాబట్టి iPhones లేదా Macs కనెక్ట్ అవుతాయని భావిస్తే, leaf certificatesను రెండు సంవత్సరాలు లేదా అంతకంటే తక్కువ వ్యవధికి పరిమితం చేయండి. -days 730 ఈ పరిమితిని అన్ని చోట్ల పాటిస్తుంది. పది సంవత్సరాల rootతో రెండు సంవత్సరాల leaf certificates కలయిక అంతర్గత వినియోగానికి అనుకూలంగా ఉంటుంది.

దీర్ఘకాలిక సర్టిఫికేట్‌లు ఒకే విధంగా విఫలమవుతాయి: ఎప్పుడు ఎంచుకున్నారో ఎవరికీ గుర్తులేని తేదీన, ఎలాంటి హెచ్చరిక లేకుండా, ఒకేసారి. మీ వద్ద ఉన్న వాటిని తనిఖీ చేయండి:

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

Renewalను వాస్తవ calendarలో నమోదు చేయండి. లేదా cron ద్వారా 30 రోజుల ముందుగా హెచ్చరిక పొందండి. గడువు ముగియడానికి ఇంకా ఆన్ని సెకన్లు మాత్రమే ఉన్నప్పుడు openssl x509 -checkend 2592000 -in cert.crt non-zeroతో ముగుస్తుంది. మీరు ఇప్పటికే స్థితి monitoring కోసం Uptime Kuma నడుపుతున్నట్లయితే, దాని HTTPS monitors సర్టిఫికేట్ గడువు సమీపిస్తున్నట్లు ఉచితంగా తెలియజేస్తాయి.

Private CAతో rotation చాలా సులభంగా ఉంటుంది: CSR-and-sign commandsను మళ్లీ అమలు చేయండి, filesను మార్చండి, web serverను reload చేయండి. Root మారలేదు కాబట్టి clientకు ఎలాంటి మార్పు కనిపించదు.

మీరు చూడబోయే సందేశాలతో వైఫల్య పరిస్థితులు

NET::ERR_CERT_AUTHORITY_INVALID, మీరు trust ఇన్‌స్టాల్ చేయడానికి ముందు కనిపించే అంచనా స్థితి. ఇది certificate లోపం కాదు. root ఇన్‌స్టాల్ చేసిన తర్వాత కూడా ఇది కొనసాగితే: Linuxలో Chrome system store బదులుగా NSSను చదువుతుంది (certutil దశను చూడండి); లేదా కాపీ చేసిన ఫైల్ చివర .crt ఉండలేదు మరియు update-ca-certificates, 0 added అని తెలిపింది; లేదా server మీరు trust చేసిన certificateకు బదులుగా వేరే certificateను అందిస్తోంది. openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256తో fingerprintsను సరిపోల్చండి.

NET::ERR_CERT_COMMON_NAME_INVALID, certificateలో SAN లేదు, లేదా SAN address barలోని పేరును కవర్ చేయదు. సాధారణ ఉదాహరణ: SANలో DNS:git.internal.lan ఉంది, కానీ user https://10.8.0.1కు browse చేశారు. trust-store మార్పులతో దీన్ని పరిష్కరించలేరు; తప్పిపోయిన entryతో certificateను మళ్లీ issue చేయండి.

curl: (60) SSL certificate problem: self-signed certificate, curl certificateను trust చేయడం లేదు. private CAతో signed చేసిన certificateకు కూడా self-signed certificate in certificate chain variant ఇదే అర్థాన్ని ఇస్తుంది. ఒక్కసారి ఉపయోగించే పరిష్కారం: curl --cacert lab-ca.crt https://...; శాశ్వత పరిష్కారం: trust store. -k కాదు.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (లేదా Expecting: CERTIFICATE REQUEST, లేదా no start line), PEMకు సంబంధించిన గందరగోళం. OpenSSL certificateను ఆశించినప్పుడు మీరు తప్పు రకమైన ఫైల్‌ను ఇచ్చారు: certificate స్థానంలో key లేదా CSR, లేదా PEM స్థానంలో DER binary. మీ వద్ద వాస్తవంగా ఏముందో head -1 filename తెలియజేస్తుంది. Certificate -----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), certificate మరియు key ఒకే జతకు చెందినవి కావు. సాధారణంగా generation commandను రెండుసార్లు అమలు చేసి, ఫైళ్లు కలిసిపోవడం వల్ల ఇది జరుగుతుంది. openssl x509 -in git.internal.crt -noout -pubkey | sha256sumను openssl pkey -in git.internal.key -pubout | sha256sumతో పోల్చి నిర్ధారించండి; hashes సరిపోతే జత కూడా సరిపోతుంది. అవి భిన్నంగా ఉంటే, రెండింటినీ కలిసి మళ్లీ generate చేయండి.

FAQ

స్వీయ సంతకం చేసిన సర్టిఫికేట్ సృష్టించిన తర్వాత కూడా Chrome “సురక్షితం కాదు” అని ఎందుకు చూపిస్తుంది?

లోపం NET::ERR_CERT_AUTHORITY_INVALID అయితే, సర్టిఫికేట్ సరిగానే ఉంది. Chrome దాన్ని ఇంకా విశ్వసించడానికి కారణం లేదు. దాన్ని లేదా మీ private CA root‌ను client trust storeలో ఇన్‌స్టాల్ చేయండి. Linuxలో Chrome system storeను కాకుండా certutil ద్వారా NSS databaseను ఉపయోగిస్తుందని గుర్తుంచుకోండి. లోపం NET::ERR_CERT_COMMON_NAME_INVALID అయితే, సర్టిఫికేట్‌లో URLకు సరిపోలే Subject Alternative Name లేదు. -addext "subjectAltName=..."తో దాన్ని మళ్లీ జారీ చేయాలి.

-k లేకుండా curl స్వీయ సంతకం చేసిన సర్టిఫికేట్‌ను విశ్వసించేలా ఎలా చేయాలి?

సర్టిఫికేట్‌ను PEM formatలో, .crt extensionతో, /usr/local/share/ca-certificates/లోకి కాపీ చేసి sudo update-ca-certificates అమలు చేయండి. అవుట్‌పుట్‌లో 1 added అని ఉండాలి. ఆ తర్వాత curl దాన్ని ఏదైనా public certificateలాగే ధృవీకరిస్తుంది. systemను మార్చకుండా ఒక్కసారి మాత్రమే request చేయాలంటే curl --cacert /path/to/cert.crt ఆ fileను మాత్రమే ఉపయోగించి ధృవీకరిస్తుంది. -k ధృవీకరణను పూర్తిగా నిలిపివేస్తుంది. దీన్ని ఎవరి scriptsలోనూ ఉపయోగించకండి.

స్వీయ సంతకం చేసిన సర్టిఫికేట్ ఎంతకాలం చెల్లుబాటు కావచ్చు?

సాంకేతికంగా, మీకు నచ్చినంతకాలం చెల్లుబాటు కావచ్చు. CA/Browser Forum పరిమితులు (ప్రస్తుతం 200 రోజులు, 2029 నాటికి 47) public trust పొందిన CAsకు మాత్రమే వర్తిస్తాయి; private trustకు వర్తించవు. అయితే ఆచరణలో server certificatesను 825 రోజులకు పరిమితం చేయండి. Issuer ఎవరు అయినా, అంతకంటే ఎక్కువ కాలం ఉన్న certificatesను Apple పరికరాలు తిరస్కరిస్తాయి. రెండు సంవత్సరాల (-days 730) leaf certificatesతో పది సంవత్సరాల private root ఉపయోగించడం సముచితమైన default. Renewal తేదీని calendarలో నమోదు చేయండి. గడువు ముగిసిన internal cert, ఎవరికీ గుర్తులేని తేదీన, మొత్తం సేవను నిశ్శబ్దంగా నిలిపివేస్తుంది.

నేను స్వీయ సంతకం చేసిన సర్టిఫికేట్‌ను ఉపయోగించాలా, లేక Let's Encryptను ఉపయోగించాలా?

సేవకు public DNS name ఉండి, internet నుంచి అందుబాటులో ఉంటే, ఎల్లప్పుడూ Let's Encryptను ఉపయోగించండి. ఇది ఉచితం, automatedగా ఉంటుంది, ప్రతి client ఇప్పటికే దీన్ని విశ్వసిస్తుంది. Let's Encrypt జారీ చేయలేని సందర్భాలకు self-signed certificate లేదా private CA ఉపయోగించండి: private IPs, .lan వంటి internal-only hostnames, air-gapped networks, అలాగే VPN వెనుక ఉద్దేశపూర్వకంగా దాచిన services. నిర్ణయం reachability మరియు namingపై ఆధారపడి ఉంటుంది, security strengthపై కాదు. Cryptography రెండింటిలోనూ ఒకటే.

/usr/local/share/ca-certificatesలో చేర్చిన తర్వాత కూడా నా సర్టిఫికేట్ ఎందుకు తిరస్కరించబడుతోంది?

మూడు విషయాలను తనిఖీ చేయండి. File పేరు .crtతో ముగియాలి. .pem extension ఉన్న fileను నిశ్శబ్దంగా దాటవేస్తారు, మరియు update-ca-certificates 0 added అని చూపిస్తుంది. Contents PEM textగా ఉండాలి. అది -----BEGIN CERTIFICATE-----తో ప్రారంభం కావాలి; DER binaryగా ఉండకూడదు. Application system storeను వాస్తవంగా ఉపయోగిస్తుందో కూడా తనిఖీ చేయండి. Linuxలో Chrome, Firefox, Python requests, Node.js, మరియు Java ఒక్కొక్కటి ప్రత్యేక trust storeను నిర్వహిస్తాయి. ప్రతి దానిలోనూ సర్టిఫికేట్‌ను విడిగా చేర్చాలి.

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