SSD Nodes Learn
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-07-25

Ubuntu 24.04 சுய-கையொப்ப TLS சான்றிதழ் உருவாக்கம்

Chrome ஏற்கும் self-signed TLS cert உருவாக்க SAN உடன் ஒரு openssl கட்டளை. nginx/Apache இணைப்பு, curl -k இல்லாமல் trust செய்வது விளக்கம்.

நீங்கள் உருவாக்க உள்ளது

நவீன உலாவிகளும் கிளையன்டுகளும் ஏற்றுக்கொள்ளும் ஒரு சுய-கையொப்பமிடப்பட்ட TLS சான்றிதழ் — சரியான subjectAltName, முறையான key அனுமதிகள், nginx அல்லது Apache உடன் இணைக்கப்பட்டது — மேலும் கிட்டத்தட்ட ஒவ்வொரு வழிகாட்டியும் தவறவிடும் ஒரு பகுதி: எச்சரிக்கைகளை கடந்து செல்வதையும் curl -k ஐ ஸ்கிரிப்ட்களில் நிரந்தரமாக எழுதுவதையும் விட்டுவிட்டு, உங்கள் கிளையன்டுகளை அதை சரியாக நம்ப வைப்பது. இறுதியில், ஒரு உள் சேவை ஆறாக மாறும்போது பயன்படுத்தக்கூடிய ஐந்து கட்டளைகள் கொண்ட தனிப்பட்ட CA.

முதலில், முடிவெடுப்பது அவசியம். ஏனெனில் சுய-கையொப்பமிடப்பட்ட சான்றிதழ் பயன்படுத்தப்படுவதை விட மிகக் குறைவான சூழ்நிலைகளிலேயே இது சரியான கருவி. உங்கள் சேவை பொது இணையத்தில் உண்மையான DNS பெயரின் கீழ் அணுகக்கூடியதாக இருந்தால், படிப்பதை நிறுத்திவிட்டு nginx இல் certbot மூலம் இலவச Let's Encrypt சான்றிதழைப் பெறுங்கள் அல்லது Apache க்கான நிகராக்கத்தை பயன்படுத்துங்கள். அதற்கு கட்டணம் இல்லை, தானாகவே புதுப்பித்துக்கொள்ளும், மேலும் உலகளாவிய அனைத்து உலாவிகளும் ஏற்கனவே அதை நம்புகின்றன. பொதுத் தளத்தில் சுய-கையொப்பமிடப்பட்ட சான்றிதழ் பயன்படுத்துவது, பாதுகாப்பு எச்சரிக்கைகளை கடந்து செல்ல உங்கள் பயனர்களுக்கு பழக்கத்தை ஏற்படுத்துகிறது. இது வெற்று HTTP ஐ விட மோசமான பழக்கம்.

பொது இணையம் என்பது கதையில் இல்லாதபோது சுய-கையொப்பமிடப்பட்டதே சரியான கருவி: உங்கள் VPS இல் WireGuard tunnel முகவரியுடன் பிணைக்கப்பட்ட நிர்வாக பேனல், தனிப்பட்ட நெட்வொர்க்கில் உள்ள staging பாக்ஸ், backend களுக்கு இடையேயான service-to-service போக்குவரத்து, home-lab சாதனம், அல்லது Webmin தனக்காக port 10000 இல் உருவாக்கும் placeholder சான்றிதழை மாற்றுவது. Let's Encrypt ஆனது 10.8.0.1 அல்லது git.internal.lan க்கு சான்றிதழ் வழங்க முடியாது — எந்தப் பொது CA வும் தனிப்பட்ட IP அல்லது கற்பனையான TLD ஐ சான்றிதழில் சேர்க்காது. அந்தப் பெயர்களுக்கு, நீங்களே CA ஆக இருக்கிறீர்கள்.

கீழே உள்ள அனைத்தும் புதிய Ubuntu 24.04 பாக்ஸில் இயங்குகிறது. இதில் OpenSSL 3.0.x உள்ளது (உறுதிப்படுத்த openssl version). இதற்கு இணைய இணைப்பு தேவையில்லை. அனைத்தும் air-gapped சூழலிலும் இயங்கும்.

பழைய ஒரு-வரி கட்டளை ஏன் 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.

trust-store-ஐ எவ்வளவு கையாடினாலும் இந்தப் பிழையை சரிசெய்ய முடியாது, ஏனென்றால் அந்த சான்றிதழ் உண்மையில் எதையும் பெயரிடவில்லை. நீங்கள் இப்போது NET::ERR_CERT_COMMON_NAME_INVALID-ஐ பார்த்துக்கொண்டிருந்தால், உங்கள் சான்றிதழுக்கு SAN இல்லை (அல்லது தவறானது உள்ளது) மற்றும் நீங்கள் ஒரு புதியதை உருவாக்க வேண்டும். அதிர்ஷ்டவசமாக இந்தத் தீர்வு ஒரே ஒரு கட்டளையில் உள்ளது.

உலாவிகள் ஏற்கும் சான்றிதழை உருவாக்குதல்: ஒரே ஒரு கட்டளை

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 என்பது nginx-ஐ ஒவ்வொரு boot-லும் உள்ளீட்டிற்காக காத்திருக்கச் செய்யும். எனவே, server key-க்கு இது தேவை.
  • -days 730 — இரண்டு ஆண்டுகள்; இந்த எண்ணைப் பற்றி expiry பகுதியில் மேலும் விவரம்.
  • -subj interactive கேள்விகளுக்கு நேரடியாக பதிலளிக்கிறது. CN இப்போது வெறும் காட்சி அம்சம், ஆனால் அதை முதன்மை பெயராக அமைக்கவும்; சில கருவிகள் அதை காட்டும்.
  • -addext "subjectAltName=..." முக்கியமான flag. Clients தட்டச்சு செய்யும் ஒவ்வொரு பெயரையும் ஒவ்வொரு IP-ஐயும் பட்டியலிடுங்கள்: hostnames-க்கு DNS: entries (DNS:*.internal.lan போன்ற wildcards பயன்படுத்தலாம்), addresses-க்கு IP: entries. யாராவது https://10.8.0.1-க்கு browse செய்தால், IP:10.8.0.1 entry அங்கே இருக்க வேண்டும் — DNS-மட்டுமே உள்ள SAN அவர்களுக்கு மீண்டும் NET::ERR_CERT_COMMON_NAME_INVALID தரும்.

எதையும் இணைப்பதற்கு முன் 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 என்று அச்சிட்டால், சான்றிதழில் 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 daemon — chown-ஐ அந்தச் சேவை பயனருக்கு மாற்றவும். இதற்கும் 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 என அச்சிட்டால், சான்றிதழ் மற்றும் key ஆகியவை இரண்டு வெவ்வேறு உருவாக்க இயக்கங்களைச் சேர்ந்தவை — 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-ஐ அறியாது. அது அங்கீகரிக்க முடியாத server-உடன் பேச மறுக்கிறது. அடுத்த பிரிவுதான் உண்மையான தீர்வு — இந்த நேரத்தில் இணையத்தில் பாதி பேர் செய்வது இதுவல்ல.

வாடிக்கைகளை சான்றிதழை நம்ப வைப்பது — மற்றும் தவிர்க்க வேண்டிய எதிர்மறை வடிவங்கள்

முதலில் தவறான தீர்வுகள், அவற்றின் உண்மையான பெயர்களால் குறிப்பிடப்படுகின்றன. ஒரு ஸ்கிரிப்டில் புதைக்கப்பட்ட curl -k (அல்லது --insecure, Python requests-ல் verify=False, Node-ல் NODE_TLS_REJECT_UNAUTHORIZED=0 — இவை எதுவும் உங்கள் சான்றிதழை நம்பக்கூடியதாக ஆக்காது. அவை சான்றிதழ் சரிபார்ப்பை முடக்குகின்றன. எனவே வாடிக்கை எந்தச் சான்றிதழையும் வழங்கும் எந்த சேவையகத்துடனும் தயக்கமின்றி பேசும். இதில் பாதையில் நுழைந்த தாக்குபவர் ஒருவர் வைத்திருக்கும் சான்றிதழும் அடங்கும். நீங்கள் TLS-ன் சுமையைத் தக்கவைத்துக்கொண்டு, அதன் நோக்கமான அங்கீகாரத்தை இழக்கிறீர்கள். இதை விட மோசமாக, இந்தக் கொடிகள் பரவுகின்றன: ஒரு cron job-ல் ஒட்டப்படுகின்றன, பின்னர் ஒரு deploy ஸ்கிரிப்டில், பின்னர் production குறியீட்டில், யாருக்கும் எந்த இணைப்புகள் தற்காலிகமாக இருக்க வேண்டும் என்று நினைவிருக்காத அளவுக்கு. ஒரு verify=False அதை உருவாக்கிய பிழைதிருத்த அமர்வைக் கடந்து நீடித்தால், வடிவமைப்பு தவறானது.

சரியான தீர்வு ஒவ்வொரு வாடிக்கை OS-க்கும் இந்தச் சான்றிதழ் ஒரு நம்பக்கூடிய root என்று கற்பிப்பது. 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 கொண்டு மாற்றவும். Self-signed சான்றிதழை அதே சான்றிதழை root ஆகச் சேர்ப்பது வேலை செய்கிறது. ஏனெனில் ஒரு self-signed சான்றிதழ் அதன் சொந்த root ஆகவே இருக்கிறது.

அதற்குப் பிறகு, curl, wget, git, apt, மற்றும் கணினி bundle-க்கு எதிராக OpenSSL-ஐப் பயன்படுத்தும் வேறு எதுவும் எந்தக் கொடியும் இல்லாமல் சேவையகத்தை நம்புகிறது. சில வாடிக்கைகள் தங்கள் சொந்த trust store-களைக் கொண்டிருக்கின்றன. அவற்றுக்கு தனிப்பட்ட கையாளுதல் தேவை:

  • Linux-ல் Chrome/Chromium கணினி store-ஐ அல்லாமல் ஒரு NSS தரவுத்தளத்தைப் படிக்கிறது: sudo apt install libnss3-tools, பின்னர் ஒவ்வொரு பயனருக்கும் certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt.
  • Firefox-க்கு அதன் சொந்த store உள்ளது: Settings → Privacy & Security → Certificates → Import, அல்லது கணினி store-ஐப் படிக்க about:config-ல் security.enterprise_roots.enabled-ஐ true-க்கு மாற்றவும்.
  • Python requests தன் சொந்த CA bundle-ஐ (certifi) கொண்டு வருகிறது. கணினி store-ஐ புறக்கணிக்கிறது: verify="/usr/local/share/ca-certificates/git.internal.crt"-ஐ அனுப்பவும் அல்லது 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 வாடிக்கைகளில், .crt-ஐ இருமுறை சொடுக்கவும். அதை Trusted Root Certification Authorities-ல் நிறுவவும்; macOS-ல், அதை Keychain Access-ல் System keychain-ல் சேர்த்து 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 ஐ அது இப்போது இருக்கும் மதிப்புமிக்க பொருளாகப் பாதுகாக்கவும்: mode 600. கையொப்பமிடும் சர்வர்களில் ஒன்றல்லாத வேறொரு கணினியில் இதை வைத்திருப்பது சிறந்தது. ஏனெனில் இதை வைத்திருப்பவர் உங்கள் கிளையன்ட்கள் நம்பும் எந்தப் பெயருக்கும் சான்றிதழை உருவாக்கலாம்.

காலாவதி மற்றும் சுழற்சி

பொது CA சான்றிதழ்களின் ஆயுட்காலம் குறைந்து வருகிறது. CA/Browser Forum மார்ச் 2026 இல் புதிதாக வழங்கப்படும் பொது நம்பகமான சான்றிதழ்களின் காலவரையை 398 நாட்களிலிருந்து 200 நாட்களாகக் குறைத்தது. 2027 இல் இது 100 நாட்களாகவும், மார்ச் 2029 க்குள் 47 நாட்களாகவும் மாறும். ஆனால் இந்த விதிகள் பொது நம்பகமான CA-களுக்கு மட்டுமே பொருந்தும். உங்கள் தனியார் CA இவற்றால் கட்டுப்படுத்தப்படாது. கைமுறையாக நிறுவப்பட்ட root-களுக்கு உலாவிகள் இந்த விதிகளைச் செயல்படுத்தாது. ஒரு நடைமுறைக் கட்டுப்பாடு உண்மையில் பொருந்தும்: யார் வழங்கியது என்பதைப் பொருட்படுத்தாமல் 825 நாட்களுக்கு மேல் செல்லுபடியாகும் TLS சேவையக சான்றிதழ்களை Apple தளங்கள் நிராகரிக்கின்றன. எனவே iPhone அல்லது Mac கள் இணைக்கும் என்றால், leaf சான்றிதழ்களை இரண்டு ஆண்டுகள் அல்லது அதற்கும் குறைவாக வைத்திருங்கள். -days 730 எல்லா இடங்களிலும் இந்த வரம்பைத் தாண்டுகிறது. பத்தாண்டு கால root-உடன் இரண்டாண்டு கால leaf-கள் என்பது ஒரு வசதியான உள் அமைப்பாகும்.

நீண்ட கால சான்றிதழ்கள் ஒரே ஒரு வகையில் தோல்வியடைகின்றன: யாரும் நினைவில் வைக்காத ஒரு தேதியில், அமைதியாக, ஒரே நேரத்தில். உங்களிடம் உள்ளதை சரிபார்க்கவும்:

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-and-sign கட்டளைகளை மீண்டும் இயக்கவும், கோப்புகளை மாற்றவும், web சேவையகத்தை மீளேற்றவும். root மாறவில்லை, எனவே எந்தக் கிளையண்டும் எதையும் கவனிக்காது.

பிழை நிலைகள், நீங்கள் காணும் சரங்களுடன்

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-க்கு தவறான வகை கோப்பை கொடுத்தீர்கள்: சான்றிதழ் எதிர்பார்த்த இடத்தில் 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 உடன் உறுதிப்படுத்தவும்; பொருந்தும் hash-கள் என்றால் பொருந்தும் ஜோடி. அவை வேறுபட்டால், இரண்டையும் ஒன்றாக மீண்டும் உருவாக்கவும்.

FAQ

சுய-கையொப்பமிடப்பட்ட சான்றிதழை உருவாக்கிய பிறகும் Chrome ஏன் "Not secure" எனக் காட்டுகிறது?

பிழை NET::ERR_CERT_AUTHORITY_INVALID என்றால், சான்றிதழ் சரியாக உள்ளது — Chrome அதை இன்னும் நம்ப காரணம் இல்லை. கிளையன்டின் நம்பிக்கை ஸ்டோரில் அதை (அல்லது உங்கள் தனிப்பட்ட CA root-ஐ) நிறுவவும். 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 நாட்கள்) பொதுவாக நம்பப்படும் CA-களுக்கே பொருந்தும், தனிப்பட்ட நம்பிக்கைக்கு அல்ல. நடைமுறையில், சர்வர் சான்றிதழ்களை 825 நாட்களுக்கு மட்டுப்படுத்தவும், ஏனெனில் வழங்குநர் யார் என்பதைப் பொருட்படுத்தாமல் Apple சாதனங்கள் அதை விட நீண்ட எதையும் நிராகரிக்கின்றன. பத்தாண்டுகள் செல்லுபடியாகும் தனிப்பட்ட root-உடன் இரண்டாண்டு (-days 730) leaf சான்றிதழ்களைப் பயன்படுத்துவது ஒரு பகுத்தறிவான இயல்புநிலை; புதுப்பித்தலை நாட்காட்டியில் குறித்து வைக்கவும், ஏனெனில் காலாவதியான உள் சான்றிதழ் யாரும் நினைவில் வைக்காத ஒரு தேதியன்று அனைத்தையும் அமைதியாகச் செயலிழக்கச் செய்யும்.

நான் சுய-கையொப்பமிடப்பட்ட சான்றிதழையா அல்லது Let's Encrypt-ஐயா பயன்படுத்த வேண்டும்?

சேவைக்குப் பொது DNS பெயர் உள்ளது மற்றும் இணையத்திலிருந்து அணுகக்கூடியதாக இருந்தால், எப்போதும் Let's Encrypt — இலவசம், தானியக்கமானது, ஒவ்வொரு கிளையன்டாலும் ஏற்கனவே நம்பப்படுகிறது. சுய-கையொப்பமிடப்பட்டது (அல்லது தனிப்பட்ட CA) Let's Encrypt வழங்க முடியாதவற்றுக்கே: தனிப்பட்ட IP-கள், .lan போன்ற உள்-மட்டுமே-பயன்படுத்தக்கூடிய ஹோஸ்ட்பெயர்கள், air-gapped நெட்வொர்க்குகள், மற்றும் 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