Ubuntu-வில் Self-signed TLS certificate உருவாக்குவது

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

நவீன உலாவிகளும் (browsers) கிளையண்டுகளும் ஏற்றுக்கொள்ளக்கூடிய ஒரு self-signed TLS certificate, சரியான subjectAltName, முறையான key permissions, மற்றும் அதை Nginx அல்லது Apache-ல் இணைத்தல். மேலும், பெரும்பாலான வழிகாட்டிகளில் விடுபடும் ஒரு முக்கியமான பகுதி: பாதுகாப்பு எச்சரிக்கைகளைத் தவிர்ப்பதற்குப் பதிலாக, உங்கள் கிளையண்டுகளை அதை முறையாக நம்பச் செய்வது மற்றும் ஸ்கிரிப்டுகளில் curl -k-ஐ நிரந்தரமாக hard-code செய்வதைத் தவிர்ப்பது. இறுதியில், ஒரு internal service ஆறு சேவைகளாக வளரும்போது பயன்படுத்தக்கூடிய ஐந்து கட்டளைகளைக் கொண்ட ஒரு private CA-வை உருவாக்குவோம்.

முதலில் ஒரு தெளிவான முடிவு தேவை, ஏனெனில் self-signed certificate-ஐப் பயன்படுத்துவது பெரும்பாலும் தவறான அணுகுமுறையாகவே உள்ளது. ஒரு சேவை உண்மையான DNS பெயருடன் பொது இணையத்தில் (public internet) அணுகக்கூடியதாக இருந்தால், இதைப் படிப்பதை நிறுத்திவிட்டு, Nginx-ல் certbot மூலம் இலவச Let's Encrypt certificate அல்லது Apache-க்கான அதே போன்ற முறையைப் பெறுங்கள். இது இலவசமானது, தானாகவே புதுப்பிக்கப்படும், மேலும் உலகின் அனைத்து உலாவிகளும் இதை ஏற்கனவே நம்புகின்றன. பொது இணையதளத்தில் self-signed certificate-ஐப் பயன்படுத்துவது, பயனர்களை பாதுகாப்பு எச்சரிக்கைகளை அலட்சியப்படுத்தப் பழக்குகிறது; இது plain HTTP-ஐப் பயன்படுத்துவதை விட மோசமான பழக்கமாகும்.

பொது இணையம் சம்பந்தப்படாத சூழலில் மட்டுமே self-signed certificate சரியான கருவியாகும்: உங்கள் VPS-ல் உள்ள WireGuard tunnel முகவரியுடன் இணைக்கப்பட்ட admin panel, ஒரு private network-ல் உள்ள staging box, backends-க்கு இடையிலான service-to-service traffic, ஒரு home-lab appliance, அல்லது Webmin தனது 10000 போர்ட்டில் உருவாக்கும் placeholder certificate-க்கு மாற்றாக இதைப் பயன்படுத்தலாம். Let's Encrypt-ஆல் 10.8.0.1 அல்லது git.internal.lan-க்கு certificate வழங்க முடியாது; எந்தவொரு பொது CA-வும் ஒரு private IP அல்லது கற்பனையான TLD-ஐ certificate-ல் சேர்க்காது. அந்தப் பெயர்களுக்கு, நீங்களே 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

இது தொடர்ச்சியான ஊடாடும் (interactive) கேள்விகளைக் கேட்கிறது, உங்கள் hostname-ஐ Common Name புலத்தில் வைக்கிறது, மேலும் subjectAltName நீட்டிப்பு (extension) இல்லாத ஒரு சான்றிதழை உருவாக்குகிறது. அந்தச் சான்றிதழ் பயன்பாட்டிற்கு வரும்போதே செல்லாததாகிவிடுகிறது. Chrome தனது 58-வது பதிப்பில் (ஏப்ரல் 2017-ல்) Common Name-ஐப் படிப்பதை நிறுத்திவிட்டது. RFC 2818 ஏற்கனவே 2000-ம் ஆண்டிலேயே CN பொருத்துதலை (matching) கைவிட்டுவிட்டது. Firefox, Safari, curl மற்றும் Python ஆகியவையும் இதே முறையையே பின்பற்றுகின்றன. ஒரு சான்றிதழ் தனது server-ஐ SAN நீட்டிப்பு மூலமாகவே அடையாளம் காண வேண்டும், இல்லையெனில் அது அடையாளம் காணப்படாது. உலாவிகள் (browsers) உங்களுக்கு இதைத்தான் தெளிவாகக் கூறுகின்றன:

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 இல்லை (அல்லது தவறான SAN உள்ளது) என்று அர்த்தம். நீங்கள் புதிய ஒன்றை உருவாக்க வேண்டும். அதிர்ஷ்டவசமாக, இதைச் சரிசெய்ய ஒரே ஒரு கட்டளை போதும்.

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

OpenSSL 1.1.1 பதிப்பில் -addext flag அறிமுகப்படுத்தப்பட்டது. இதனால், பழைய வழிகாட்டிகளில் பயன்படுத்தப்பட்ட சிக்கலான config-file முறைகள் இன்றி, 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"

ஒவ்வொரு flag-ன் செயல்பாடும்:

• -x509 என்பது signing request-க்கு பதிலாக, நேரடியாக self-signed சான்றிதழை உருவாக்குகிறது.
• -newkey rsa:4096 என்பது புதிய key-ஐ உருவாக்குகிறது. RSA 4096 எந்தவொரு பழைய client-க்கும் சிக்கலை ஏற்படுத்தாது; நவீனமான இணைப்புகள் மட்டுமே இருந்தால், -newkey ec -pkeyopt ec_paramgen_curve:P-256 சிறியதாகவும் வேகமாகவும் இருக்கும்.
• -noenc என்பது பழைய -nodes-க்கு மாற்றாக OpenSSL 3.x-ல் பயன்படுத்தப்படுகிறது: இது key-க்கு passphrase தேவையில்லை என்று குறிக்கிறது. இரண்டுமே வேலை செய்யும். Passphrase இருந்தால், ஒவ்வொரு முறை boot செய்யும்போதும் nginx உள்ளீட்டிற்காகக் காத்திருக்கும், எனவே server key-க்கு இதுவே சிறந்தது.
• -days 730, இரண்டு ஆண்டுகள்; இந்த கால அளவு குறித்த கூடுதல் விவரங்கள் expiry பகுதியில் உள்ளன.
• -subj என்பது கேட்கப்படும் கேள்விகளுக்குத் தானாகவே பதிலளிக்கிறது. CN இப்போது பெயரளவில் மட்டுமே இருந்தாலும், முதன்மைப் பெயரை அமைப்பது நல்லது; சில கருவிகள் இதைக் காட்டுகின்றன.
• -addext "subjectAltName=..." என்பது மிக முக்கியமான flag. வாடிக்கையாளர்கள் பயன்படுத்தும் ஒவ்வொரு பெயர் மற்றும் ஒவ்வொரு IP முகவரியையும் இதில் பட்டியலிட வேண்டும்: hostnames-க்கு DNS: பதிவுகள் (DNS:*.internal.lan போன்ற wildcards பயன்படுத்தலாம்), முகவரிகளுக்கு IP: பதிவுகள். யாராவது https://10.8.0.1 மூலம் இணைந்தால், IP:10.8.0.1 பதிவு கட்டாயம் இருக்க வேண்டும், இல்லையெனில் DNS-only 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 இல்லை என்று அர்த்தம். உலாவிகள் இதை நிராகரிக்கும், எனவே தொடர்வதற்கு முன் மீண்டும் உருவாக்கவும்.

தனிப்பட்ட சாவியைப் பாதுகாத்தல் (Lock down the key)

ஒரு server-ல் உள்ள அனைத்து பயனர்களும் வாசிக்கக்கூடிய வகையில் இருக்கும் 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-ஐக் குறைப்பதற்கு முன்பாக root பயனராகச் சான்றிதழ்களை வாசிக்கின்றன. எனவே, அவற்றுக்கு root:root mode 600 போதுமானது. ஒருவேளை, அந்தச் சாவி ஒரு குறிப்பிட்ட பயனரின் கீழ் இயங்கும் service-க்காக (உதாரணமாக: Node app, 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

nginx -t கட்டளையை இயக்கும்போது, reload செய்வதற்கு முன்பாக syntax is ok மற்றும் test is successful ஆகியவற்றை அது அச்சிட வேண்டும். அதற்குப் பதிலாக SSL_CTX_use_PrivateKey_file() failed ... key values mismatch என்று காட்டினால், அந்த certificate மற்றும் key ஆகிய இரண்டும் வெவ்வேறு நேரங்களில் உருவாக்கப்பட்டவை என்று பொருள்; failure-modes பகுதியைச் சரிபார்க்கவும்.

Apache-உடன் இணைத்தல்

sudo a2enmod ssl proxy proxy_http

ssl மட்டும் இதற்குப் போதாது: கீழே உள்ள vhost, ProxyPass-ஐப் பயன்படுத்துகிறது. mod_proxy மற்றும் mod_proxy_http இல்லையென்றால், configuration சோதனை 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 சரியாகச் செயல்படுவதைக் குறிக்கிறது: உங்கள் certificate-ஐப் பற்றி curl-க்குத் தெரியாது. எனவே, தன்னால் அங்கீகரிக்க முடியாத ஒரு server-உடன் தொடர்புகொள்ள அது மறுக்கிறது. அடுத்த பகுதிதான் இதற்கான உண்மையான தீர்வு. இணையத்தில் தற்போது பரவலாகப் பின்பற்றப்படும் தவறான வழிமுறை இதுவல்ல.

கிளையண்டுகளை நம்பச் செய்தல் மற்றும் தவிர்க்க வேண்டிய தவறான முறைகள்

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

சரியான தீர்வு, இந்தச் சான்றிதழ் ஒரு நம்பகமான ரூட் (trusted root) என்பதை ஒவ்வொரு கிளையண்ட் 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 நீட்டிப்பு (extension) இருந்தால் அது அமைதியாகப் புறக்கணிக்கப்படும், மேலும் எந்தப் பிழைச் செய்தியும் இன்றி 0 added பிழை ஏற்படும். மேலும், உள்ளடக்கங்கள் PEM வடிவில் இருக்க வேண்டும்; கோப்பு -----BEGIN CERTIFICATE----- என்று தொடங்க வேண்டும்; DER பைனரி கோப்பை முதலில் openssl x509 -inform der -in file.der -out file.crt மூலம் மாற்றவும். சுய-கையொப்பமிடப்பட்ட (self-signed) சான்றிதழை ரூட்டாகச் சேர்ப்பது வேலை செய்யும், ஏனெனில் அத்தகைய சான்றிதழ் அதன் சொந்த ரூட்டாகவே செயல்படுகிறது.

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

• Linux-ல் Chrome/Chromium: இது system store-ஐப் பயன்படுத்தாது, NSS database-ஐப் படிக்கும்: 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 என்பதற்குச் செல்லவும், அல்லது 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"-ஐ அனுப்பவும் அல்லது 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 என மாற்றவும்.

பல சேவைகளுக்கான ஒரே root: ஒரு சிறிய private CA

ஒவ்வொரு சான்றிதழுக்கும் தனித்தனியாக நம்பிக்கை (trust) வைப்பது உடனடியாகச் சிக்கலாகிவிடும்: ஆறு சேவைகள் மற்றும் நான்கு client கணினிகள் எனில், மொத்தம் இருபத்தி நான்கு முறை trust நிறுவப்பட வேண்டும்; ஒவ்வொரு புதிய சேவையும் இந்த எண்ணிக்கையை அதிகரிக்கும். இதற்குத் தீர்வாக ஒரு private CA-வை உருவாக்கலாம். client-கள் ஒரே root-ஐ நம்பினால் போதும், அதன் மூலம் ஒவ்வொரு சேவையின் சான்றிதழையும் நீங்கள் கையொப்பமிடலாம்.

இதற்கான எளிமையான வழி 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-களிலும் அதைப் பதிவு செய்யும்; மூன்றாவது கட்டளை git.internal.lan+2.pem மற்றும் git.internal.lan+2-key.pem ஆகியவற்றை உருவாக்கும், இவற்றை மேலே உள்ள nginx அல்லது Apache துணுக்குகளில் (snippets) நேரடியாகப் பயன்படுத்தலாம். இதன் வடிவமைப்பு ஒரு மேம்பாட்டு இயந்திரத்தை (development machine) அடிப்படையாகக் கொண்டது. root key-யானது -install இயக்கப்பட்ட கணினியிலேயே இருக்கும். எனவே, இது ஒரு dev laptop-க்குச் சிறந்தது, ஆனால் server தொகுப்புகளுக்கு (server fleet) இது பொருத்தமானதல்ல.

server-களுக்கு, plain 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-லிருந்து அனைத்து extensions-களையும் நீக்கிவிடும், நீங்கள் கவனமாகச் சேர்த்த 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-ஐ மேலே உள்ள trust-store படிகள் மூலம் client-களுக்கு விநியோகிக்கவும், இதை ஒவ்வொரு இயந்திரத்திற்கும் ஒருமுறை செய்தால் போதும். lab-ca.key-ஐ மிகக் கவனமாகப் பாதுகாக்கவும்; இது இப்போது மிக முக்கியமான ஒன்றாக மாறிவிட்டது. இதன் அனுமதியை (mode) 600 என வைக்கவும். இது கையொப்பமிடும் server-களில் ஒன்றாக இல்லாமல், தனிப்பட்ட ஒரு கணினியில் இருப்பது சிறந்தது. ஏனெனில், இதை வைத்திருப்பவர் உங்கள் client-கள் நம்பக்கூடிய எந்தப் பெயருக்கும் சான்றிதழை உருவாக்க முடியும்.

காலாவதி மற்றும் சுழற்சி (Expiry and rotation)

பொது CA certificate-களின் ஆயுட்காலம் குறைந்து வருகிறது. மார்ச் 2026-ல், CA/Browser Forum புதிதாக வெளியிடப்படும் பொது நம்பிக்கைக்குரிய certificate-களின் கால அளவை 200 நாட்களாகக் குறைத்தது (முன்பு 398 நாட்கள்). இது 2027-ல் 100 நாட்களாகவும், மார்ச் 2029-க்குள் 47 நாட்களாகவும் குறையும். ஆனால், இந்த விதிகள் பொது நம்பிக்கைக்குரிய (publicly trusted) CA-களுக்கு மட்டுமே பொருந்தும். உங்கள் private CA-க்கு இந்த விதிகள் கட்டுப்படாது; மேலும், கைமுறையாக நிறுவப்பட்ட root certificate-களுக்கு உலாவிகள் (browsers) இந்த கட்டுப்பாடுகளை விதிப்பதில்லை. நடைமுறையில் ஒரு முக்கிய கட்டுப்பாடு உள்ளது: Apple தளங்கள் 825 நாட்களுக்கு மேல் செல்லுபடியாகும் எந்தவொரு TLS server certificate-ஐயும் நிராகரித்துவிடும். எனவே, iPhones அல்லது Macs இணைக்கப்பட வேண்டுமானால், leaf certificate-களின் கால அளவை இரண்டு ஆண்டுகள் அல்லது அதற்கும் குறைவாக வைத்திருங்கள். -days 730 இந்த வரம்பை எல்லா இடங்களிலும் பூர்த்தி செய்கிறது; பத்து ஆண்டுகள் செல்லுபடியாகும் root மற்றும் இரண்டு ஆண்டுகள் செல்லுபடியாகும் leaf certificate-கள் உள்நாட்டு பயன்பாட்டிற்கு ஏற்ற அமைப்பாகும்.

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

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

புதுப்பித்தலை ஒரு காலெண்டரில் குறித்து வையுங்கள், அல்லது 30 நாட்களுக்கு முன்பே உங்களுக்கு நினைவூட்ட cron-ஐப் பயன்படுத்துங்கள். காலாவதி காலம் குறிப்பிட்ட வினாடிகளுக்குள் வரும்போது openssl x509 -checkend 2592000 -in cert.crt non-zero exit code-ஐ வழங்கும். நீங்கள் ஏற்கனவே நிலை கண்காணிப்பிற்கான Uptime Kuma-ஐப் பயன்படுத்துகிறீர்கள் என்றால், அதன் HTTPS monitors மூலம் certificate காலாவதியாவதை இலவசமாகவே கண்காணிக்கலாம்.

Private CA மூலம் certificate-களைச் சுழற்சி செய்வது (rotation) எளிதானது: CSR-and-sign கட்டளைகளை மீண்டும் இயக்குங்கள், கோப்புகளை மாற்றவும், web server-ஐ reload செய்யவும். Root certificate மாறாததால், எந்தவொரு client-க்கும் எந்த மாற்றமும் தெரியாது.

தோல்வி நிலைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)

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 மூலம் கைரேகைகளை (fingerprints) ஒப்பிட்டுப் பார்க்கவும்.

NET::ERR_CERT_COMMON_NAME_INVALID, சான்றிதழில் SAN இல்லை, அல்லது முகவரிப் பட்டியில் உள்ள பெயரை SAN உள்ளடக்கவில்லை. பொதுவான உதாரணம்: SAN-ல் DNS:git.internal.lan என்று உள்ளது, ஆனால் பயனர் https://10.8.0.1-க்குச் சென்றுள்ளார். டிரஸ்ட் ஸ்டோர் (trust-store) மாற்றங்களால் இதைச் சரிசெய்ய முடியாது; விடுபட்ட உள்ளீட்டுடன் சான்றிதழை மீண்டும் வழங்கவும் (reissue).

curl: (60) SSL certificate problem: self-signed certificate, curl சான்றிதழை நம்பவில்லை. உங்கள் தனிப்பட்ட CA-வால் கையொப்பமிடப்பட்ட சான்றிதழுக்கு self-signed certificate in certificate chain என்ற மாறுபாடும் இதையே குறிக்கிறது. தற்காலிகத் தீர்வு: 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-யும் ஒன்றுக்கொன்று தொடர்புடையவை அல்ல, பொதுவாக உருவாக்கும் கட்டளை (generation command) இருமுறை இயக்கப்பட்டதால் கோப்புகள் மாறியிருக்கலாம். openssl x509 -in git.internal.crt -noout -pubkey | sha256sum மற்றும் openssl pkey -in git.internal.key -pubout | sha256sum மூலம் உறுதிப்படுத்தவும்; ஹேஷ்கள் (hashes) ஒன்றாக இருந்தால் அவை சரியான ஜோடி. அவை வேறுபட்டால், இரண்டையும் சேர்த்து மீண்டும் உருவாக்கவும்.

FAQ

நான் self-signed certificate உருவாக்கிய பிறகும் Chrome ஏன் "Not secure" என்று காட்டுகிறது?

பிழை NET::ERR_CERT_AUTHORITY_INVALID ஆக இருந்தால், certificate சரியாக உள்ளது, ஆனால் Chrome அதை நம்புவதற்கு எந்த காரணமும் இல்லை. அதை client-ன் trust store-ல் நிறுவவும் (அல்லது உங்கள் private CA root-ஐ சேர்க்கவும்). Linux-ல் Chrome, system store-க்கு பதிலாக certutil வழியாக NSS database-ஐப் பயன்படுத்துகிறது என்பதை நினைவில் கொள்ளவும். பிழை NET::ERR_CERT_COMMON_NAME_INVALID ஆக இருந்தால், certificate-ல் URL-க்கு இணையான Subject Alternative Name இல்லை என்று அர்த்தம்; அதை -addext "subjectAltName=..." பயன்படுத்தி மீண்டும் உருவாக்க வேண்டும்.

-k பயன்படுத்தாமல் curl-ஐ எப்படி self-signed certificate-ஐ நம்ப வைக்கலாம்?

Certificate-ஐ (PEM format, .crt extension) /usr/local/share/ca-certificates/-க்குள் நகலெடுத்து sudo update-ca-certificates-ஐ இயக்கவும்; வெளியீடு 1 added என்று இருக்க வேண்டும். அதன் பிறகு, curl அதை ஒரு பொதுவான certificate போலவே சரிபார்க்கும். system-ஐ மாற்றாமல் ஒருமுறை மட்டும் சரிபார்க்க, curl --cacert /path/to/cert.crt அந்த கோப்பை மட்டும் பயன்படுத்தும்; -k சரிபார்ப்பை முழுமையாக முடக்கும், இதை எந்த script-லும் பயன்படுத்தக்கூடாது.

ஒரு self-signed certificate எவ்வளவு காலம் செல்லுபடியாகும்?

தொழில்நுட்ப ரீதியாக நீங்கள் விரும்பும் காலம் வரை வைத்திருக்கலாம். CA/Browser Forum வரம்புகள் (தற்போது 200 நாட்கள், 2029-ல் 47 நாட்கள்) பொதுவான CA-களுக்கு மட்டுமே பொருந்தும், private trust-க்கு அல்ல. நடைமுறையில், server certificate-களை 825 நாட்களுக்குள் கட்டுப்படுத்துங்கள், ஏனெனில் Apple சாதனங்கள் அதற்கு மேல் உள்ள எதையும் நிராகரித்துவிடும். பத்து ஆண்டு கால private root மற்றும் இரண்டு ஆண்டு (-days 730) leaf certificate-கள் ஒரு சரியான தேர்வு; புதுப்பித்தலை calendar-ல் குறித்து வையுங்கள், ஏனெனில் காலாவதியான internal cert யாரும் எதிர்பாராத நேரத்தில் சேவைகளை முடக்கிவிடும்.

நான் self-signed certificate பயன்படுத்த வேண்டுமா அல்லது Let's Encrypt பயன்படுத்த வேண்டுமா?

சேவைக்கு public DNS பெயர் இருந்து, அது இணையத்திலிருந்து அணுகக்கூடியதாக இருந்தால், எப்போதும் Let's Encrypt-ஐப் பயன்படுத்துங்கள்; இது இலவசம், தானியங்கி முறையில் இயங்கக்கூடியது மற்றும் அனைத்து client-களாலும் நம்பகமானது. Let's Encrypt வழங்க முடியாத private IP-கள், internal-only hostnames (உதாரணமாக .lan), air-gapped networks மற்றும் VPN-க்கு பின்னால் மறைக்கப்பட்ட சேவைகளுக்கு மட்டுமே self-signed (அல்லது private CA) பயன்படுத்த வேண்டும். இந்த முடிவு அணுகல் மற்றும் பெயரிடுதலைப் பொறுத்தது, பாதுகாப்பு வலிமையைப் பொறுத்ததல்ல; இரண்டிலும் cryptography ஒன்றுதான்.

/usr/local/share/ca-certificates-ல் சேர்த்த பிறகும் எனது certificate ஏன் நிராகரிக்கப்படுகிறது?

மூன்று விஷயங்களைச் சரிபார்க்கவும். கோப்பு .crt என்று முடிய வேண்டும்; .pem extension இருந்தால் அது கவனிக்கப்படாது மற்றும் update-ca-certificates பிழையை 0 added என்று காட்டும். கோப்பின் உள்ளடக்கம் DER binary-ஆக இல்லாமல், -----BEGIN CERTIFICATE----- என்று தொடங்கும் PEM text-ஆக இருக்க வேண்டும். மேலும், அந்த application system store-ஐப் பயன்படுத்துகிறதா என்பதை உறுதிப்படுத்தவும்; Linux-ல் Chrome, Firefox, Python requests, Node.js மற்றும் Java ஆகியவை தனித்தனி trust store-களைக் கொண்டுள்ளன, அவற்றில் certificate-ஐத் தனித்தனியாகச் சேர்க்க வேண்டும்.