Ubuntu-வில் சொந்த CA சான்றிதழை சேர்ப்பது எப்படி?

Ubuntu-வின் trust store-ல் உங்கள் சொந்த CA-வைச் சேர்த்தல்

Ubuntu-வின் trust store-ல் உங்கள் சொந்த CA-வைச் சேர்க்க, root certificate-ஐ /usr/local/share/ca-certificates/ கோப்பகத்திற்குள் .crt என்று முடியும் பெயரில் நகலெடுக்கவும். பிறகு sudo update-ca-certificates கட்டளையை இயக்கவும். CA (certificate authority) என்பது மற்ற certificate-களை கையொப்பமிட அனுமதிக்கப்பட்ட ஒரு key pair ஆகும். உங்கள் root-ஐ கணினி நம்பத் தொடங்கியவுடன், அந்த root கையொப்பமிட்ட அனைத்து certificate-களும் ஏற்றுக்கொள்ளப்படும். இதனால் உங்கள் சொந்த சேவைகளுக்கு இடையிலான HTTPS சரிபார்ப்பு தோல்வியடைவது நின்றுவிடும்.

இந்த வழிகாட்டி openssl-ஐப் பயன்படுத்தி முழுச் சங்கிலியையும் (chain) ஆஃப்லைனில் உருவாக்குகிறது. நீங்கள் ஒரு root key மற்றும் root certificate-ஐ உருவாக்கி, ஒரு server-க்காக ஒரு leaf certificate-ஐ வழங்கி, பின் root-ஐ நிறுவி, அதே சரிபார்ப்பு கட்டளை எவ்வாறு விடையை மாற்றுகிறது என்பதைப் பார்ப்பீர்கள். இந்த வரிசைமுறை முக்கியமானது: நிறுவுவதற்கு முன்பும் பின்பும் சரிபார்ப்பதன் மூலமே, நிறுவல் எவ்வாறு முடிவை மாற்றியது என்பதை நீங்கள் அறிய முடியும்.

Ubuntu 24.04 இயல்பான image-ல் OpenSSL 3 மற்றும் ca-certificates தொகுப்பைக் கொண்டுள்ளது. எனவே, முதலில் எதையும் நிறுவ வேண்டியதில்லை (ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்டது).

எப்போது நீங்கள் சொந்தமாக CA-வை இயக்க வேண்டும்?

Let's Encrypt போன்ற பொதுவான CA-க்கு, பொது DNS-ல் ஒரு பெயர் மற்றும் அது அணுகக்கூடிய ஒரு server தேவை. அகநிலை (internal) பெயர்கள் இதற்குத் தகுதியற்றவை. ஒரு private network-ல் உள்ள database அல்லது tunnel-ல் இணைக்கப்பட்ட admin panel-க்கு பொதுச் சான்றிதழ் (public certificate) பெற முடியாது; சான்றிதழ் பெறுவதற்காக மட்டும் அவற்றை இணையத்தில் வெளிப்படுத்தவும் கூடாது.

Ubuntu-வில் self-signed certificate என்பது ஒரு host-க்கு மட்டுமே தீர்வாகும். ஒவ்வொரு client-ம் அந்த ஒரு சான்றிதழை நம்ப வேண்டும், அடுத்த host-க்கு மீண்டும் அதே வேலையைச் செய்ய வேண்டும். ஒரு private CA இந்த முடிவை ஒரு படி மேலே கொண்டு செல்கிறது. client-கள் root-ஐ ஒருமுறை நம்பினால் போதும், அதன் பிறகு அந்த root கையொப்பமிடும் அனைத்துச் சான்றிதழ்களும் நம்பகமானவை; இன்னும் உருவாக்கப்படாத host-களுக்கான சான்றிதழ்களும் இதில் அடங்கும்.

இதற்கான செலவு அதிகம். கட்டுப்பாடுகள் அனுமதிக்கும் எதிலும் root key கையொப்பமிட முடியும் என்பதால், ca.key-ஐ வாசிப்பவர் உங்கள் கணினிகள் ஏற்கும் சான்றிதழ்களை உருவாக்க முடியும். SSH key management-ல் ஒரு private key-ஐ எவ்வாறு பாதுகாப்பீர்களோ, அதேபோல் இதையும் பாதுகாக்கவும். ஒரு service-க்கு பொது DNS பெயர் இருந்தால், இதையெல்லாம் தவிர்த்துவிட்டு ஒரு பொது CA-வைப் பயன்படுத்தவும்: Certbot with nginx and Let's Encrypt என்பது குறைவான வேலை மற்றும் client பக்கத்தில் எதையும் நிறுவ வேண்டிய அவசியமில்லை.

CA key மற்றும் root certificate-ஐ உருவாக்குதல்

உங்கள் பயனர் கணக்கு மட்டுமே அணுகக்கூடிய ஒரு கோப்பகத்தில் (directory) வேலை செய்யுங்கள். Root key அந்த இடத்தை விட்டு வெளியேறக்கூடாது.

install -d -m 700 ~/ca
cd ~/ca
openssl genrsa -aes256 -out ca.key 4096
chmod 600 ca.key

-aes256 நீங்கள் தேர்ந்தெடுக்கும் ஒரு கடவுச்சொல் (passphrase) மூலம் key-ஐ குறியாக்கமுறைக்கு (encrypt) உட்படுத்துகிறது. இந்த key-ஐப் பயன்படுத்தி கையொப்பமிடும் ஒவ்வொரு கட்டளைக்கும் அந்தக் கடவுச்சொல் தேவைப்படும். -aes256-ஐத் தவிர்த்தால், key வட்டில் (disk) எவ்வித பாதுகாப்பும் இன்றி இருக்கும். அவ்வாறான நிலையில், ஒரு backup அல்லது மற்றொரு நிர்வாகி கணக்கு இருந்தால் போதும், உங்கள் கணினிகள் நம்பும் சான்றிதழ்களை (certificates) எவர் வேண்டுமானாலும் வழங்க முடியும்.

இப்போது root certificate-ஐ உருவாக்குவோம். இதை CA key தனக்காகவே கையொப்பமிடுகிறது.

openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/O=Example Internal/CN=Example Internal Root CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -addext "subjectKeyIdentifier=hash" \
  -addext "nameConstraints=critical,permitted;DNS:internal.example" \
  -out ca.crt

internal.example என்பதற்குப் பதிலாக நீங்கள் பயன்படுத்தும் பெயர் பின்னொட்டை (suffix) இடவும். கடைசி extension-ஐச் சேர்ப்பதற்கு முன் அடுத்த பகுதியை வாசிக்கவும்.

ஒவ்வொரு extension-ம் ஒரு குறிப்பிட்ட பணியைச் செய்கிறது.

• basicConstraints உடன் CA:TRUE சேர்ப்பதுதான் இதை ஒரு CA certificate-ஆக மாற்றுகிறது. இது இல்லையென்றால், கையொப்பம் சரியாக இருந்தாலும், இந்த key கையொப்பமிடும் எந்தவொரு சான்றிதழையும் client நிராகரித்துவிடும்.
• pathlen:0 என்பது, இந்த CA சான்றிதழ்களை மட்டுமே கையொப்பமிட முடியும் என்பதையும், இதற்கு கீழே வேறு எந்த CA-வும் இருக்க முடியாது என்பதையும் குறிக்கிறது.
• keyUsage என்பது, இந்த key-ஐ சான்றிதழ்கள் மற்றும் ரத்து செய்யப்பட்ட பட்டியல்களை (revocation lists) கையொப்பமிட மட்டுமே கட்டுப்படுத்துகிறது. இதனால், தவறுதலாக இந்த key-ஐ TLS server key-ஆகப் பயன்படுத்த முடியாது.
• subjectKeyIdentifier என்பது, root-க்கு ஒரு அடையாளத்தை (identifier) வழங்குகிறது. நூற்றுக்கணக்கான சான்றிதழ்கள் உள்ள ஒரு store-ல், சரியான issuer-ஐக் கண்டறிய client-க்கு இது உதவுகிறது.
• nameConstraints என்பது, இந்த CA எந்தெந்த பெயர்களுக்குச் சான்றளிக்கலாம் என்பதை வரையறுக்கிறது.

கட்டளை நீங்கள் எதிர்பார்த்தபடி செயல்பட்டதா என்பதை உறுதிப்படுத்த, உருவாக்கிய கோப்பை மீண்டும் வாசித்துப் பார்க்கவும்.

openssl x509 -noout -subject -issuer -serial -dates -in ca.crt
openssl x509 -noout -text -in ca.crt

Root certificate தனக்குத்தானே கையொப்பமிடுவதால், Subject மற்றும் issuer ஆகிய இரண்டும் ஒரே சரத்தை (string) காட்டும். Serial எண் மற்றும் இரண்டு தேதிகள் நீங்கள் உருவாக்கிய கோப்பிலிருந்து பெறப்பட்டவை. எனவே, பிற வழிகாட்டிகளில் உள்ளவற்றை நகலெடுக்காமல், இந்த வெளியீட்டிலிருந்து அவற்றைப் பெற்றுக்கொள்ளுங்கள்.

உங்கள் CA கையொப்பமிட அனுமதிக்கப்பட்டவற்றை கட்டுப்படுத்துதல்

நீங்கள் வேறுவிதமாகக் குறிப்பிடாதவரை, system store-ல் உள்ள ஒரு root, இணையத்தில் உள்ள அனைத்து பெயர்களுக்கும் நம்பகமானதாகக் கருதப்படுகிறது. ஒரு server-ல் உள்ள ஒரு கோப்பில் இவ்வளவு பெரிய அதிகாரத்தை வைத்திருப்பது ஆபத்தானது. nameConstraints இதை குறைக்கிறது. root-ல் permitted;DNS:internal.example இருக்கும்போது, internal.example-க்கு வெளியே உள்ள ஒரு பெயருக்காக இந்த CA-விலிருந்து வரும் chain, கையொப்பம் சரியாக இருந்தாலும் நிராகரிக்கப்படும்.

அதை நம்புவதற்குப் பதிலாகச் சோதித்துப் பாருங்கள்.

openssl req -new -newkey rsa:2048 -nodes -keyout /tmp/outside.key -out /tmp/outside.csr \
  -subj "/CN=www.example.com"
openssl x509 -req -in /tmp/outside.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 30 -sha256 \
  -extfile <(printf 'subjectAltName=DNS:www.example.com\n') -out /tmp/outside.crt
openssl verify -CAfile ca.crt /tmp/outside.crt
echo $?

உங்கள் CA எதைக் கேட்கிறீர்களோ அதற்கு கையொப்பமிடுவதால், certificate வழங்கப்படுகிறது. சரிபார்ப்பு (verification) நிலையில்தான் இது தோல்வியடைகிறது: exit status பூஜ்ஜியமற்றதாக இருக்கும் மற்றும் OpenSSL அது சந்தித்த தடையைக் (constraint) குறிப்பிடும். இதுவே இந்த extension-ன் மதிப்பு. ஒரு CA key திருடப்பட்டாலும், அது subtree-க்கு வெளியே உள்ள ஒரு பெயருக்குச் செல்லுபடியாகும் certificate-ஐ உருவாக்க முடியாது. நீங்கள் முடித்ததும் rm /tmp/outside.* மூலம் எஞ்சியவற்றை நீக்கவும்.

ஒரு தடையை அமல்படுத்துவதற்கு முன் தெரிந்துகொள்ள வேண்டிய நான்கு விஷயங்கள். இது critical எனக் குறிக்கப்பட்டுள்ளது, எனவே இந்த extension-ஐப் புரிந்துகொள்ளாத ஒரு client, அதைத் தவிர்க்காமல் chain-ஐ நிராகரிக்க வேண்டும். இது பாதுகாப்பான அணுகுமுறை என்றாலும், பழைய TLS library-களுக்கு இது ஆச்சரியமாக இருக்கலாம். DNS பெயர்களுக்கான permitted subtree, IP address SAN-களைக் கட்டுப்படுத்தாது, ஏனெனில் subtree குறிப்பிடப்படாத பெயர் வகை கட்டுப்பாடற்றதாகவே இருக்கும். எனவே உங்கள் certificate-களில் IP address-கள் இருந்தால், அதே extension-ல் permitted;IP:10.0.0.0/255.255.0.0-ஐச் சேர்க்கவும். subtree நீங்கள் எதிர்காலத்தில் வழங்கப்போகும் அனைத்து பெயர்களையும் உள்ளடக்கியிருக்க வேண்டும், இதில் short hostname-களும் அடங்கும். எனவே, app என்ற bare name-க்கான certificate மேலே உள்ள உதாரணத்தின்படி தோல்வியடையும். மேலும், இந்தத் தடை root-ல் பதிக்கப்பட்டுள்ளது, எனவே உங்கள் முடிவை மாற்றினால், புதிய root certificate-ஐ உருவாக்கி ஒவ்வொரு client-லும் புதிதாக நிறுவ வேண்டியிருக்கும்.

உங்கள் CA மூலம் கையொப்பமிடப்பட்ட leaf certificate-ஐ உருவாக்குதல்

Leaf certificate என்பது clients-க்கு server வழங்கும் சான்றிதழ் ஆகும். முதலில் அதற்கான சொந்த key மற்றும் CSR (certificate signing request)-ஐ உருவாக்கவும். இதில் public key மற்றும் கோரப்பட்ட பெயர் இருக்கும். கோருபவரிடம் private key இருப்பதை உறுதிப்படுத்த, இது leaf key மூலம் கையொப்பமிடப்படும்.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.internal.example"
chmod 600 app.key

முக்கியமான பெயர்கள் CSR-ல் அல்லாமல், extension file-ல் இருக்க வேண்டும். Clients, hostname-ஐ subjectAltName (SAN)-உடன் ஒப்பிட்டுப் பார்க்கும்; common name-ஐ முழுமையாகப் புறக்கணிக்கும். எனவே, CN மட்டும் இருந்து SAN இல்லாத சான்றிதழ், தற்போதைய அனைத்து clients-களிலும் hostname சரிபார்ப்பில் தோல்வியடையும்.

basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.internal.example, DNS:api.internal.example
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

அதை app.ext எனச் சேமித்து, பின் CA மூலம் அந்த request-ஐ கையொப்பமிடவும்.

openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 397 -sha256 -extfile app.ext -out app.crt

-CAcreateserial, ca.srl என்ற கோப்பை CA-க்கு அருகில் உருவாக்கும். இது அடுத்த serial number-ஐக் கொண்டிருக்கும், இதனால் இந்த CA-விலிருந்து வழங்கப்படும் எந்த இரு சான்றிதழ்களும் ஒரே எண்ணைப் பகிராது. அந்தக் கோப்பை CA directory-யிலேயே வைத்திருக்கவும். -days 397 என்பது ஒரு விருப்பத்தேர்வு, கருவியின் வரம்பு அல்ல. பொது CA-வை விட, தனியார் CA-வில் சான்றிதழின் ஆயுட்காலம் குறைவாக இருப்பது முக்கியம். ஏனெனில், தனியார் CA-வில் revocation வசதி இல்லை: நீங்கள் உருவாக்காத வரை CRL அல்லது OCSP responder இருக்காது. எனவே, ஒரு leaf key கசிந்தால், சான்றிதழ் காலாவதியாகும் வரை அதைப் பயன்படுத்த முடியும்.

Trust store-க்குச் செல்லும் முன் முடிவைச் சரிபார்க்கவும்.

openssl x509 -noout -subject -issuer -serial -dates -in app.crt
openssl x509 -noout -ext subjectAltName -in app.crt

Issuer வரியில் இப்போது leaf-க்கு பதிலாக CA-வின் பெயர் இருக்கும். SAN வரியில் இந்தச் சான்றிதழ் செல்லுபடியாகும் பெயர்கள் பட்டியலிடப்பட்டிருக்கும். Client அந்தப் பட்டியலை மட்டுமே சரிபார்க்கும்.

எதையும் நிறுவும் முன், ஒரு explicit -CAfile மூலம் சரிபார்க்கவும்

openssl verify -CAfile ca.crt app.crt
echo $?

இது ஒரு குறுகிய கேள்வியை மட்டுமே கேட்கிறது: app.crt-ல் உள்ள சான்றிதழ், ca.crt-ல் உள்ள சான்றிதழுடன் சங்கிலித் தொடராக (chain) இணைந்துள்ளதா? நீங்கள் OpenSSL-க்கு கட்டளை வரியிலேயே root சான்றிதழை வழங்கியதால், இந்த இயந்திரம் எதை நம்புகிறது என்பது பற்றி இது எதையும் கூறாது. இங்கே தோல்வி ஏற்பட்டால், அது சான்றிதழ்களில் உள்ள சிக்கலாகும்; எனவே தொடரும் முன் அதைச் சரிசெய்யவும்.

இப்போது இயந்திரத்திடம் கேளுங்கள்.

openssl verify app.crt
echo $?

எந்தவொரு -CAfile-ம் இல்லாதபோது, OpenSSL அதன் உள்ளமைக்கப்பட்ட (built-in) சான்றிதழ் கோப்பகத்திற்குத் திரும்பும். openssl version -d உங்கள் build பயன்படுத்தும் அடிப்படை கோப்பகத்தைக் காட்டும். Ubuntu-வில், அதன் கீழ் உள்ள certs கோப்பகம் /etc/ssl/certs எனத் தீர்மானிக்கப்படும். உங்கள் root சான்றிதழ் இன்னும் அங்கு இல்லை, எனவே சரிபார்ப்பு தோல்வியடையும்: சங்கிலித் தொடர், store-ல் இல்லாத ஒரு issuer-ஐ அடைகிறது, மேலும் தேடுவதற்கு வேறு இடமும் இல்லை. வெளியேறும் நிலையை (exit status) கவனிக்கவும். இதுவே இன்னும் இரண்டு படிகளுக்குப் பிறகு மாறப்போகும் விஷயமாகும்.

ஒரு உண்மையான client, openssl verify-ஐ விடச் சிறந்த சோதனையைச் செய்யும், ஏனெனில் அது சங்கிலித் தொடருடன் சேர்த்து hostname-ஐயும் சரிபார்க்கும். சான்றிதழை வழங்கி (serve), அதை fetch செய்யவும்.

openssl s_server -accept 8443 -cert app.crt -key app.key -www &
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

--resolve, app.internal.example-ஐக் கோரும் அதே வேளையில் இணைப்பை 127.0.0.1-க்கு அனுப்புகிறது. எனவே SAN பொருந்துகிறது, இப்போது எஞ்சியிருக்கும் ஒரே கேள்வி நம்பகத்தன்மை (trust) மட்டுமே. curl தோல்வியடைந்து, சங்கிலித் தொடரை ஏன் சரிபார்க்க முடியவில்லை என்பதற்கான காரணத்தை அச்சிடும். கூடுதல் விவரங்களுக்கு -v-ஐச் சேர்க்கவும். சோதனை server-ஐ இயங்க விடவும்.

root-ஐ /usr/local/share/ca-certificates கோப்பகத்தில் நிறுவுதல்

sudo cp ca.crt /usr/local/share/ca-certificates/example-internal-root.crt
sudo chmod 644 /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates

இது செயல்படுவதைத் தீர்மானிக்கும் விவரங்கள்:

• கோப்பின் பெயர் கண்டிப்பாக .crt என்று முடிய வேண்டும். update-ca-certificates கையேடு பக்கத்தின்படி, /usr/local/share/ca-certificates-க்குக் கீழே உள்ள .crt நீட்டிப்பு கொண்ட சான்றிதழ்கள் சேர்க்கப்பட்டு, மறைமுகமாக நம்பகமானவையாகக் கருதப்படும். root.pem அல்லது root.cer என்று பெயரிடப்பட்ட கோப்புகள் எவ்வித அறிவிப்பும் இன்றி தவிர்க்கப்படும்.
• உள்ளடக்கமானது PEM வடிவில் இருக்க வேண்டும்; அதாவது, BEGIN CERTIFICATE மற்றும் END CERTIFICATE வரிகளுக்கு இடையில் உள்ள base64 தொகுதியாக இருக்க வேண்டும். .crt என்று பெயர் மாற்றப்பட்ட DER கோப்பு இன்னும் binary வடிவிலேயே இருக்கும், அது வாசிக்கப்படாது. அதை openssl x509 -inform DER -in ca.der -out ca.crt மூலம் மாற்றவும்.
• root சான்றிதழ் மட்டுமே இங்கே இருக்க வேண்டும். CA private key மற்றும் leaf certificate ஆகியவற்றுக்கு trust store-ல் இடமில்லை.

update-ca-certificates எத்தனை சான்றிதழ்கள் சேர்க்கப்பட்டன மற்றும் நீக்கப்பட்டன என்பதைக் காட்டும். எதுவும் சேர்க்கப்படவில்லை என்றால், கோப்பின் நீட்டிப்பு அல்லது வடிவம் தவறாக இருப்பதுதான் காரணம்.

அந்தச் செய்தியை மட்டும் நம்பாமல், கணினியின் தரப்பிலிருந்து மாற்றத்தை உறுதிப்படுத்தவும்.

ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in /usr/local/share/ca-certificates/example-internal-root.crt).0
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt

முதல் கட்டளை உங்கள் சான்றிதழின் subject hash-ஐக் கொண்டு ஒரு கோப்புப் பெயரை உருவாக்கி அதை பட்டியலிடும். update-ca-certificates அந்த symlink-ஐ உருவாக்கியிருக்கும், அது நீங்கள் நிறுவிய கோப்பைச் சுட்டிக்காட்டும். இரண்டாவது கட்டளை, ஒற்றைக் கோப்பு தொகுப்பில் (single-file bundle) உள்ள சான்றிதழ்களின் எண்ணிக்கையைக் கணக்கிடும். நிறுவுவதற்கு முன்பும் இதை இயக்கினால், எண்ணிக்கை ஒன்றால் அதிகரிப்பதை நீங்கள் கவனிக்கலாம்.

இந்த root-ஐ மற்ற கணினிகளுக்கு நகலெடுக்கும்போது, நிறுவுவதற்கு முன்பு நகல் சரியாக வந்துள்ளதா என்று சரிபார்க்கவும். ஒரு root certificate தவறாக இருப்பது கணினிக்கு மிகவும் ஆபத்தானது, எனவே இதைப் பதிவிறக்கம் செய்யும் மற்ற கோப்புகளைப் போலவே checksum மூலம் சரிபார்த்து பயன்படுத்தவும்.

system store-ஐக் கொண்டு மீண்டும் சரிபார்க்கவும்

openssl verify app.crt
echo $?
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

அதே commands, அதே certificate files, ஆனால் வேறு பதில். app.crt-ல் எந்த மாற்றமும் இல்லை, நீங்கள் முன்னதாகத் தொடங்கிய அதே server தான் இது. ஒரே வித்தியாசம் என்னவென்றால், root certificate இப்போது அந்த clients தேடும் store-ல் உள்ளது, எனவே chain முழுமையடைகிறது. இதுவே நினைவில் கொள்ள வேண்டிய நுட்பம்: verification என்பது client ஏற்கனவே நம்பும் ஒரு issuer-ஐத் தேடும் செயல்முறை; ஒரு CA-வை நிறுவுவது என்பது, அந்த issuer-ஐ client தேடும் இடத்திற்குக் கொண்டு செல்லும் வழியாகும்.

kill %1-ஐப் பயன்படுத்தி test server-ஐ நிறுத்தவும்.

/etc/ssl/certs கோப்பகத்தில் ஏன் உங்கள் கோப்புகளை வைக்கக்கூடாது

/etc/ssl/certs என்பது உருவாக்கப்பட்ட வெளியீடு ஆகும். update-ca-certificates உண்மையான certificate கோப்புகளுக்கான symlink-களை உருவாக்கி, அவற்றுடன் இணைக்கப்பட்ட bundle கோப்பான /etc/ssl/certs/ca-certificates.crt-ஐயும் உருவாக்குகிறது.

நீங்கள் கைமுறையாக அந்த கோப்பகத்தில் நகலெடுக்கும் certificate-ஐ எந்த மென்பொருளும் கண்டறியாது. OpenSSL-ன் directory lookup, certificate-ன் subject hash பெயரில் உள்ள கோப்புகளை மட்டுமே திறக்கும்; எனவே myca.crt என்று பெயரிடப்பட்ட கோப்பு அதற்குத் தெரியாது. Ubuntu-வில் உள்ள curl, bundle கோப்பைப் படிக்கிறது. இந்த bundle பதிவுசெய்யப்பட்ட ஆதாரங்களிலிருந்து மீண்டும் உருவாக்கப்படுவதால், உங்கள் கோப்பு அந்தப் பாதையில் இருக்காது. நீங்கள் update-ca-certificates --fresh கட்டளையை இயக்கினால், கோப்பகத்தில் உள்ள symlink-கள் நீக்கப்பட்டு மீண்டும் உருவாக்கப்படும்; அப்போது நீங்கள் கைமுறையாக உருவாக்கிய இணைப்புகளும் நீக்கப்படும்.

இந்த அமைப்பின் மற்றொரு பகுதி /usr/share/ca-certificates ஆகும். இது ca-certificates தொகுப்புக்கு (package) சொந்தமானது மற்றும் /etc/ca-certificates.conf-ல் பட்டியலிடப்பட்டுள்ளது. தொகுப்பு மேம்படுத்தப்படும்போது (package update) இது மீண்டும் எழுதப்படும். /usr/local/share/ca-certificates என்பது உள்ளூர் நிர்வாகிக்காக ஒதுக்கப்பட்ட கோப்பகம் ஆகும். எனவே, மீதமுள்ள கோப்புகளை நிர்வகிக்கும் தொகுப்பு மேம்படுத்தப்பட்டாலும், உங்கள் CA கோப்பு அழியாமல் பாதுகாப்பாக இருக்கும்.

எந்தெந்த நிரல்கள் system trust store-ஐப் புறக்கணிக்கின்றன

OpenSSL-ஐப் பயன்படுத்தும் அல்லது /etc/ssl/certs-ஐ வாசிக்கும் அனைத்து நிரல்களையும் root certificate நிறுவுதல் சரிசெய்கிறது. இதில் curl, wget, git, Python-ன் standard ssl module மற்றும் Linux-ல் system கோப்புகளை வாசிக்கும் Go நிரல்கள் அடங்கும். சொந்தமாக certificate பட்டியலைக் கொண்டுள்ள runtimes-க்கு இது பொருந்தாது; வெற்றிகரமாக நிறுவிய பிறகும் ஏற்படும் குழப்பங்களுக்கு இதுவே முக்கிய காரணமாகும்.

• Node.js ஒரு compiled-in பட்டியலைப் பயன்படுத்துகிறது. நிரல் தொடங்குவதற்கு முன்பே environment-ல் NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crt-ஐ அமைப்பதன் மூலம் உங்கள் root-ஐ அதற்குச் சுட்டிக்காட்டலாம், ஏனெனில் Node இந்த variable-ஐ தொடக்கத்தில் ஒருமுறை மட்டுமே வாசிக்கும். தற்போதைய Node releases-ல் system store-ஐ வாசிக்கும் வசதியும் உள்ளது; உங்கள் பதிப்பில் இந்த வசதி உள்ளதா என்பதை அறிய node --help | grep -i system-ca-ஐ இயக்கவும்.
• Python-ன் requests library certifi bundle-ஐப் பயன்படுத்துகிறது. அந்த process-க்கு REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt-ஐ அமைக்கவும் அல்லது call-க்கு verify="/etc/ssl/certs/ca-certificates.crt"-ஐ அனுப்பவும். இதே காரணத்திற்காக pip, --cert-ஐ எடுத்துக்கொள்கிறது.
• Java ஒரு keystore-ஐ வாசிக்கிறது. Ubuntu-வில் ca-certificates-java package, /etc/ca-certificates/update.d/-ன் கீழ் ஒரு hook-ஐ நிறுவுகிறது, எனவே அந்த package இருக்கும்போது update-ca-certificates, Java keystore-ஐயும் புதுப்பிக்கும். அது இல்லையெனில், keytool -importcert மூலம் root-ஐ import செய்யவும்.
• Firefox தனக்கென ஒரு store-ஐ வைத்துள்ளது, அது ஒருபோதும் /etc/ssl/certs-ஐப் பார்ப்பதில்லை. அதன் certificate அமைப்புகள் வழியாக import செய்யவும். Linux-ல் Chromium ஒரு per-user NSS database-ஐ வாசிக்கிறது, இதை நீங்கள் libnss3-tools package-ல் உள்ள certutil மூலம் திருத்தலாம்.
• Containers சொந்தமாக filesystem-ஐக் கொண்டுள்ளன, எனவே host-ன் store அவற்றுக்குள் எந்த மாற்றத்தையும் ஏற்படுத்தாது. root-ஐ image-க்குள் நகலெடுத்து, build செய்யும்போது update-ca-certificates-ஐ இயக்கவும். உங்கள் services Docker Compose on a VPS-ன் கீழ் இயங்கினால், அதற்கேற்ப திட்டமிடுங்கள்.

சுத்தமாக நிறுவிய பிறகும் ஒரு நிரல் certificate-ஐ ஏற்க மறுத்தால், வேறு எதையும் மாற்றுவதற்கு முன் அது எந்தெந்தக் கோப்புகளைத் திறக்கிறது என்பதைக் கண்டறியவும். strace -f -e trace=openat <command> 2>&1 | grep -i cert ஒரு நேரடியான கருவி, இது ஒரே இயக்கத்தில் உங்கள் கேள்விக்கான பதிலைத் தரும்.

CA-வை நீண்ட காலத்திற்குப் பயன்படுத்தக்கூடிய நிலையில் வைத்திருத்தல்

ஒரு leaf certificate-ஐ மீண்டும் வெளியிடுவது என்பது, அதே app.ext கோப்பைப் பயன்படுத்தி CSR மற்றும் கையொப்பமிடும் (signing) செயல்முறையை மீண்டும் செய்வதாகும். நீங்கள் நம்பும் root மாறாததால், client-கள் எந்த நடவடிக்கையும் எடுக்க வேண்டியதில்லை. ca.srl மற்றும் ஒவ்வொரு .ext கோப்பையும் CA directory-யிலேயே வைத்திருங்கள். அப்போதுதான், அடுத்த முறை certificate வெளியிடும்போது, நினைவகத்திலிருந்து மீண்டும் உருவாக்காமல், ஏற்கனவே வேலை செய்த command-ஐ மீண்டும் பயன்படுத்த முடியும்.

ca.key மற்றும் ca.crt ஆகியவற்றை machine-க்கு வெளியே பாதுகாப்பான இடத்தில், encrypted நிலையில் backup எடுங்கள். key-ஐ இழந்துவிட்டால், உங்களால் புதிய எதையும் வெளியிட முடியாது: நீங்கள் இரண்டாவது CA-வை உருவாக்கி, முதல் CA எங்கு நிறுவப்பட்டதோ அங்கெல்லாம் புதிய root-ஐ நிறுவ வேண்டியிருக்கும். root certificate-ஐப் பெற்ற ஒவ்வொரு machine மற்றும் application store-ன் பட்டியலை எழுதி வையுங்கள். அந்தப் பட்டியல் இருந்தால் மட்டுமே, எதிர்காலத்தில் certificate-களை மாற்றவோ (rotation) அல்லது நீக்கவோ முடியும்.

root certificate-ன் காலாவதி தேதி நெருங்கும்போது, அதற்கு மாற்றாக புதிய ஒன்றை முன்கூட்டியே உருவாக்கி, இரண்டு root-களையும் அருகருகே நிறுவுங்கள். ஒரு store-ல் இரண்டு root-கள் இருப்பது தவறல்ல; client ஏதேனும் ஒன்றை ஏற்றுக்கொள்கிறது. புதிய root-ஐப் பயன்படுத்தி leaf certificate-களை மீண்டும் வெளியிடுங்கள். அதன் பிறகு, பழைய root-ஐச் சார்ந்திருக்கும் சேவைகள் எதுவும் இல்லை என்பதை உறுதிசெய்துவிட்டு, அதை நீக்கிவிடலாம்.

Trust store-லிருந்து CA-வை நீக்குதல்

sudo rm /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates --fresh

--fresh கட்டளையானது /etc/ssl/certs-ல் உள்ள symlink-களை நீக்கிவிட்டு, மீதமுள்ள source-களைக் கொண்டு அவற்றை மீண்டும் உருவாக்குகிறது. எனவே, நீக்கப்பட்ட root, directory மற்றும் bundle ஆகிய இரண்டிலிருந்தும் அகற்றப்படுகிறது. நீங்கள் நிறுவியதை உறுதிப்படுத்திய அதே முறையில், நீக்கப்பட்டதையும் உறுதிப்படுத்தவும்.

openssl verify app.crt
echo $?
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt
ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in ~/ca/ca.crt).0

சரிபார்ப்பு மீண்டும் தோல்வியடையும், certificate எண்ணிக்கை பழைய நிலைக்குத் திரும்பும், மேலும் hash symlink நீக்கப்பட்டிருக்கும்.

அந்தக் கட்டளை system store-ஐ மட்டுமே மாற்றும். மற்ற இடங்களில் செய்த நிறுவல்களை நீங்களே கைமுறையாகச் சரிசெய்ய வேண்டும்: NODE_EXTRA_CA_CERTS-ஐ காலி செய்யவும், ஏதேனும் Java keystore-லிருந்து alias-ஐ நீக்கவும், ஒவ்வொரு browser profile-லிருந்தும் root-ஐ அகற்றவும், மற்றும் அதை உள்ளடக்கிய எந்தவொரு container image-ஐயும் மீண்டும் உருவாக்கவும். ஒரு root-ஐ நீக்குவது, அது கையொப்பமிட்ட certificate-களை செல்லாததாக்காது. அதை இன்னும் நம்பும் ஒவ்வொரு கணினியிலும் அவை செல்லுபடியாகும். இதனால்தான் ஒரு private CA எங்கு நிறுவப்பட்டது என்பதற்கான பட்டியல் அவசியமாகிறது. முழுமையாக நீக்க முடியாத ஒரு CA நிரந்தரமான பாதுகாப்பு ஓட்டையாகிவிடும். எனவே, நிறுவிய அன்றே ஒரு கணினியில் நீக்கும் முறையைச் சோதித்துப் பாருங்கள், அப்போதுதான் பட்டியல் சிறியதாக இருக்கும்.

FAQ

Ubuntu-வில் CA certificate-ஐ எங்கே வைக்க வேண்டும்?

/usr/local/share/ca-certificates/-ல், .crt-ல் முடியும் கோப்புப் பெயருடன் PEM உள்ளடக்கத்தை வைக்கவும், பிறகு sudo update-ca-certificates-ஐ இயக்கவும். அந்த directory உள்ளூர் நிர்வாகிக்காக ஒதுக்கப்பட்டது, எனவே package மேம்படுத்தல்கள் அதை மாற்றாது. /usr/share/ca-certificates என்பது ca-certificates package-க்கு உரியது, /etc/ssl/certs என்பது இரண்டிலிருந்தும் உருவாக்கப்படுகிறது, எனவே அவற்றில் வைக்கப்படும் கோப்பு மேலெழுதப்படும் அல்லது புறக்கணிக்கப்படும்.

update-ca-certificates செய்த பிறகும் curl ஏன் certificate-ஐ நிராகரிக்கிறது?

காரணங்களை வரிசையாகச் சரிபார்க்கவும். கோப்பு .crt-ல் முடியாமல் இருக்கலாம், அல்லது PEM-க்கு பதிலாக DER-ஆக இருக்கலாம்; அவ்வாறெனில் update-ca-certificates அதைத் தவிர்த்துவிடும். Certificate-ல் hostname-க்கு பொருந்தும் subjectAltName இல்லாமல் இருக்கலாம், இது trust தோல்வியல்ல, hostname தோல்வி; openssl x509 -noout -ext subjectAltName -in app.crt மூலம் சரிபார்க்கவும். Intermediate certificate தேவைப்படும்போது, server leaf certificate-ஐ மட்டும் அனுப்பலாம். CURL_CA_BUNDLE அல்லது --cacert மூலம் curl வேறொரு bundle-ஐக் குறிக்கலாம். நீண்ட நேரம் இயங்கும் service-களை restart செய்ய வேண்டும், ஏனெனில் பெரும்பாலான நிரல்கள் தொடங்கும்போதே trust store-ஐ ஒருமுறை மட்டுமே வாசிக்கும்.

System trust store-ல் Firefox, Chrome, Node மற்றும் Java அடங்குமா?

இல்லை. curl, wget, git, Python-ன் standard ssl module மற்றும் Go நிரல்கள் system கோப்புகளை வாசிக்கும், எனவே update-ca-certificates இயங்கியவுடன் அவை வேலை செய்யும். Firefox தனக்கென ஒரு store-ஐ வைத்துள்ளது. Linux-ல் Chromium ஒரு பயனர் சார்ந்த NSS database-ஐப் பயன்படுத்துகிறது, இதை libnss3-tools package-ல் உள்ள certutil மூலம் திருத்தலாம். Node.js-க்கு உங்கள் root கோப்பைக் குறிக்கும் NODE_EXTRA_CA_CERTS தேவை. Java ஒரு keystore-ஐ வாசிக்கும், இதை ca-certificates-java package நிறுவப்பட்டிருக்கும்போது மட்டுமே update-ca-certificates புதுப்பிக்கும். Python-ன் requests, certifi-ஐப் பயன்படுத்துகிறது மற்றும் அதற்கு REQUESTS_CA_BUNDLE தேவை.

Ubuntu-வின் trust store-லிருந்து CA-வை எப்படி நீக்குவது?

/usr/local/share/ca-certificates/-லிருந்து கோப்பை நீக்கிவிட்டு sudo update-ca-certificates --fresh-ஐ இயக்கவும். --fresh விருப்பம் /etc/ssl/certs-ல் உள்ள symlink-களை நீக்கிவிட்டு மீண்டும் உருவாக்கும், எனவே certificate ஒரே நேரத்தில் hash symlink-களிலிருந்தும் ca-certificates.crt bundle-லிருந்தும் நீக்கப்படும். அந்த CA கையொப்பமிட்ட certificate-ஐ வைத்து openssl verify-ஐ இயக்கி, exit status-ஐப் பார்த்து உறுதிப்படுத்தவும். நீங்கள் சேர்த்த மற்ற அனைத்து store-களிலும் நீக்குதலை மீண்டும் செய்யவும், ஏனெனில் அந்த command எதையும் பாதிக்காது.

பொதுத் தளத்திற்கு Let's Encrypt-க்கு பதிலாக private CA-வைப் பயன்படுத்தலாமா?

இல்லை. பார்வையாளரின் browser உங்கள் root-ஐப் பார்த்ததில்லை, எனவே அது முழுப் பக்க எச்சரிக்கையைக் காட்டும், மேலும் உங்கள் கட்டுப்பாட்டில் இல்லாத கணினிகளில் உங்கள் root-ஐ நிறுவ முடியாது. Private CA என்பது உங்கள் கணினிகள் மட்டும் அடையாளம் காணும் பெயர்களுக்கும், நீங்கள் நிர்வகிக்கும் client-களுக்கும் மட்டுமே. அந்நியர்கள் பார்வையிடும் எதற்கும், பொது CA-விடமிருந்து certificate-ஐப் பெறவும்.