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

Ubuntu 24.04 లో self-signed certificate సరైన పద్ధతి

Chrome ఆమోదించే self-signed TLS cert ని openssl తో SAN తో తయారు చేయండి. nginx/Apache లో అనుసంధానించి, curl -k లేకుండా విశ్వసించేలా చేయడం ఇక్కడ ఉంది.

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

ఆధునిక బ్రౌజర్‌లు మరియు క్లయింట్‌లు నిజంగా ఆమోదించే స్వయం-సంతకం చేయబడిన TLS సర్టిఫికేట్ — సరైన subjectAltName, సమంజసమైన కీ అనుమతులు, nginx లేదా Apache లోకి అనుసంధానించబడినది — అలాగే దాదాపు ప్రతి గైడ్ దాటవేసే భాగం: హెచ్చరికల ద్వారా క్లిక్ చేయడం మరియు స్క్రిప్ట్‌లలో శాశ్వతంగా curl -k హార్డ్-కోడ్ చేయడం కాకుండా, మీ క్లయింట్‌లు దాన్ని సరిగ్గా విశ్వసించేలా చేయడం. చివర్లో, ఒక అంతర్గత సేవ ఆరుగా మారినప్పుడు ఉపయోగించడానికి ఐదు-కమాండ్‌ల ప్రైవేట్ CA.

ముందుగా, నిర్ణయం — ఎందుకంటే స్వయం-సంతకం చేయబడిన సర్టిఫికేట్ అనేది దాని వాస్తవ వినియోగం కంటే చాలా తక్కువసార్లు మాత్రమే సరైన పద్ధతి. ఒక సేవ ప్రజా ఇంటర్నెట్‌లో నిజమైన DNS పేరు కింద చేరుకోగలిగితే, చదవడం ఆపండి మరియు nginx పై certbot తో ఉచిత Let's Encrypt సర్టిఫికేట్ లేదా Apache కి సమానమైనది పొందండి. అది ఏమీ ఖర్చు చేయదు, స్వయంగా నవీకరించుకుంటుంది, మరియు ప్రపంచంలోని ప్రతి బ్రౌజర్ ఇప్పటికే దాన్ని విశ్వసిస్తుంది. ప్రజా సైట్‌పై స్వయం-సంతకం చేయబడిన సర్టిఫికేట్ మీ వినియోగదారులను భద్రతా హెచ్చరికల ద్వారా క్లిక్ చేయడానికి అలవాటు చేస్తుంది, ఇది సాధారణ HTTP కంటే చెత్త అలవాటు.

ప్రజా ఇంటర్నెట్ పరిధిలో లేనప్పుడు స్వయం-సంతకం సరైన పద్ధతి: మీ VPS పై WireGuard టనెల్ చిరునామాకు బంధించబడిన అడ్మిన్ ప్యానెల్, ప్రైవేట్ నెట్‌వర్క్‌లో ఒక స్టేజింగ్ బాక్స్, బ్యాకెండ్‌ల మధ్య సేవ-నుండి-సేవ ట్రాఫిక్, హోమ్-ల్యాబ్ అప్లయిన్స్, లేదా Webmin పోర్ట్ 10000 పై తనకోసం సృష్టించే ప్లేస్‌హోల్డర్ సర్టిఫికేట్ భర్తీ చేయడం. Let's Encrypt ఏమిటైనా 10.8.0.1 లేదా git.internal.lan కోసం జారీ చేయలేదు — ప్రైవేట్ IP ని లేదా కల్పిత TLD ని సర్టిఫికేట్‌లో ఏ పబ్లిక్ CA పెట్టదు. ఆ పేర్ల కోసం, మీరే 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

ఇది కొన్ని ఇంటరాక్టివ్ ప్రశ్నలను అడుగుతుంది. మీ హోస్ట్‌నేమ్‌ను Common Name ఫీల్డ్‌లో ఉంచుతుంది. మరియు subjectAltName ఎక్స్‌టెన్షన్ లేని సర్టిఫికెట్‌ను ఉత్పత్తి చేస్తుంది. ఆ సర్టిఫికెట్ వెంటనే విఫలమవుతుంది. Chrome వెర్షన్ 58లో, ఏప్రిల్ 2017లో Common Name చదడం ఆపివేసింది — RFC 2818 సంవత్సరం 2000లోనే CN మ్యాచింగ్‌ను ఇప్పటికే రద్దు చేసింది — మరియు Firefox, Safari, curl, మరియు Python కూడా అదే విధంగా ప్రవర్తిస్తాయి. ఒక సర్టిఫికెట్ దాని సర్వర్‌ను SAN ఎక్స్‌టెన్షన్ ద్వారా గుర్తిస్తుంది లేదా అస్సలు గుర్తించదు. మరియు బ్రౌజర్ మీకు సరిగ్గా ఈ మాటల్లో చెబుతుంది:

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 లేదు (లేదా తప్పు 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 మోడ్ 600 వాటికి పనిచేస్తుంది. ఒక సేవ తన స్వంత వినియోగదారుగా నడుస్తూ కీని స్వయంగా లోడ్ చేసుకుంటే — ఒక Node యాప్, Gitea, లేదా Python డెమాన్ వంటిది — దాన్ని ఆ సేవా వినియోగదారుకి chown చేయండి, మళ్లీ మోడ్ 600 లోనే ఉంచండి. మీరు ఎప్పుడూ చేయకూడనిది: మోడ్ 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 అనేది రీలోడ్ ఏదైనా చేయడానికి ముందు syntax is ok మరియు test is successful లను ప్రింట్ చేయాలి. దాని బదులుగా అది SSL_CTX_use_PrivateKey_file() failed ... key values mismatch ప్రింట్ చేస్తే, ఆ సర్టిఫికేట్ మరియు కీ రెండు వేర్వేరు జనరేషన్ రన్‌లకు చెందినవే — వైఫల్య-రకాల విభాగాన్ని చూడండి.

దీన్ని Apache లోకి అనుసంధానించండి

sudo a2enmod ssl proxy proxy_http

ఇక్కడ కేవలం ssl మాత్రమే సరిపోదు: దిగువ వhost 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 పనిలో అతికించబడతాయి, తర్వాత deploy స్క్రిప్ట్‌లో, పిమ్మట ప్రొడక్షన్ కోడ్‌లో చేరుతాయి. చివరికి ఏ కనెక్షన్లు తాత్కాలికంగా ఉండాలని అనుకున్నారో ఎవరికీ గుర్తుండదు. ఒక 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 కీచైన్‌కి జోడించి దానిని Always Trustగా గుర్తించండి.

అనేక సేవలకు ఒక రూట్: ఒక చిన్న ప్రైవేట్ CA

ఒక్కో సర్టిఫికేట్‌కు ఒక్కో ట్రస్ట్ ఇన్‌స్టాల్ చేయడం వెంటనే సాగదు: ఆరు సేవలు, నాలుగు క్లయింట్ మెషీన్లు అంటే ఇరవై నాలుగు ట్రస్ట్ ఇన్‌స్టాల్‌లు. ప్రతి కొత్త సేవ మరిన్ని జోడిస్తుంది. పరిష్కారం ఒక ప్రైవేట్ CA. క్లయింట్‌లు ఒక్క రూట్‌ను నమ్ముతాయి. మీరు ప్రతి సేవ సర్టిఫికేట్‌ను దానితో సంతకం చేస్తారు.

సులభమైన ఎంపిక mkcert. అది Ubuntu 24.04 రెపోలలో ఉంది. update-ca-certificates వదిలివేసే NSS స్టోర్‌లను (Chrome, Firefox) ఇది నిర్వహిస్తుంది:

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 సర్వర్ సర్టిఫికెట్‌లను తిరస్కరిస్తాయి. కాబట్టి iPhones లేదా Macs కనెక్ట్ అవుతాయి అంటే, లీఫ్ సర్టిఫికెట్‌లను రెండు సంవత్సరాలు లేదా అంతకంటే తక్కువగా ఉంచండి. -days 730 అన్ని చోట్లా ఆ ప్రమాణాన్ని దాటుతుంది. పదేళ్ల రూట్‌తో రెండేళ్ల లీఫ్‌లు అనేది ఒక సౌకర్యవంతమైన అంతర్గత నిర్మాణం.

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

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

పునరుద్ధరణను వాస్తవ క్యాలెండర్‌లో పెట్టండి. లేదా 30 రోజుల ముందుగానే cron మిమ్మల్ని గుర్తు చేయనివ్వండి — గడువు ఆ సెకన్లలోపల ఉంటే openssl x509 -checkend 2592000 -in cert.crt సున్నా కంటే ఎక్కువ విలువతో నిష్క్రమిస్తుంది. మీరు ఇప్పటికే స్టేటస్ పర్యవేక్షణ కోసం Uptime Kuma నడుపుతుంటే, దాని HTTPS మానిటర్‌లు దగ్గరకు వస్తున్న సర్టిఫికెట్ గడువును ఉచితంగా సూచిస్తాయి.

ప్రైవేట్ CAతో భ్రమణం చాలా సాధారణంగా ఉంటుంది: CSR మరియు సైన్ కమాండ్‌లను మళ్లీ అమలు చేయండి, ఫైళ్లను మార్చండి, వెబ్ సర్వర్‌ను రీలోడ్ చేయండి. రూట్ మారలేదు, కాబట్టి ఏ క్లయింట్‌కు కూడా ఏమీ కనిపించదు.

వైఫల్య రకాలు, మీరు చూసే స్ట్రింగ్‌లతో

NET::ERR_CERT_AUTHORITY_INVALID — మీరు ట్రస్ట్‌ను ఇన్‌స్టాల్ చేయడానికి ముందు ఊహించిన స్థితి, సర్టిఫికేట్‌లో లోపం కాదు. మీరు రూట్‌ను ఇన్‌స్టాల్ చేసిన తర్వాత కూడా ఇది కొనసాగితే: 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కి వెళ్ళాడు. ట్రస్ట్-స్టోర్ మార్పులు దీన్ని పరిష్కరించలేవు; లేని ఎంట్రీతో మళ్లీ జారీ చేయండి.

curl: (60) SSL certificate problem: self-signed certificate — curl సర్టిఫికేట్‌ను ట్రస్ట్ చేయదు. వేరియంట్ self-signed certificate in certificate chain అనేది మీ ప్రైవేట్ CA ద్వారా సంతకం చేయబడిన సర్టిఫికేట్‌కు అదే అర్థం. ఒకసారి పరిష్కారం: curl --cacert lab-ca.crt https://...; శాశ్వత పరిష్కారం: ట్రస్ట్ స్టోర్. -k కాదు.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (లేదా Expecting: CERTIFICATE REQUEST, లేదా no start line) — PEM గందరగోళం. మీరు OpenSSLకు తప్పు రకం ఫైల్‌ను అందించారు: సర్టిఫికేట్ కావలసిన చోట కీ లేదా 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) — సర్టిఫికేట్ మరియు కీ కలిసి చెందవు, సాధారణంగా జనరేషన్ కమాండ్ రెండుసార్లు అమలు చేయబడింది మరియు ఫైళ్లు కలిసిపోయాయి కాబట్టి. 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=..."తో తిరిగి జారీ చేయాలి.

-k లేకుండా curl ను సెల్ఫ్-సైన్డ్ సర్టిఫికేట్‌ను నమ్మేలా నేను ఎలా చేస్తాను?

సర్టిఫికేట్‌ను (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) పబ్లిక్‌గా విశ్వసనీయ CAsకు వర్తిస్తాయి, ప్రైవేట్ ట్రస్ట్‌కు కాదు. ఆచరణలో, సర్వర్ సర్టిఫికేట్‌లను 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