HAProxy में SSL Certificate को कैसे कॉन्फ़िगर करें

HAProxy एक TCP और HTTP लोड बैलेंसर है जो TLS को टर्मिनेट करता है, यानी यह एज पर ट्रैफ़िक को डिक्रिप्ट करता है और आपके बैकएंड सर्वरों को सामान्य HTTP भेजता है। इससे यह पूरे पथ में एकमात्र मशीन बन जाती है जिसे सर्टिफिकेट की ज़रूरत होती है, और यह उस सर्टिफिकेट को एक विशेष रूप में चाहता है: एक फाइल, जिसमें सर्टिफिकेट, कोई भी इंटरमीडिएट, और प्राइवेट की मौजूद हों।

यह गाइड पूरे पथ को कवर करती है: CSR जनरेट करना, PEM फाइल असेंबल करना, फ्रंटएंड और बैकएंड लिखना, कॉन्फ़िगरेशन की जाँच करना, और लाइव कनेक्शनों को गिराए बिना रीलोड करना। कमांड्स को HAProxy 3.4 के विरुद्ध चलाया गया था, जो वर्तमान लंबी अवधि तक समर्थित (long-term supported) ब्रांच है, जून 2026 में रिलीज़ हुई और Q2 2031 तक बनी रहेगी।

HAProxy क्या चाहता है: एक ही PEM फाइल

अधिकांश सर्वर सर्टिफिकेट, चेन और की को तीन अलग-अलग सेटिंग्स के रूप में लेते हैं। HAProxy एक ही लेता है। इसका कॉन्फ़िगरेशन मैनुअल crt कीवर्ड को इस रूप में वर्णित करता है कि यह “एक PEM फाइल है जिसमें आवश्यक सर्टिफिकेट और कोई भी संबंधित प्राइवेट कीज़ शामिल हैं”, जो PEM फाइलों को जोड़कर बनाई जाती है, और यह भी बताता है कि “यदि आपकी CA को इंटरमीडिएट सर्टिफिकेट की आवश्यकता है, तो इसे भी इस फाइल में जोड़ा जा सकता है”।

शुरू करने से पहले दो व्यवहारों को जानना उपयोगी है, क्योंकि ये बाद में काम बचाते हैं:

• की, सर्टिफिकेट के अंदर होने के बजाय उसके साथ भी रह सकती है। यदि फाइल में कोई प्राइवेट की नहीं है, तो HAProxy उसी पथ को .key जोड़कर खोजता है। इसलिए mydomain.pem के साथ mydomain.pem.key भी उसी तरह काम करता है जैसे एक संयुक्त फाइल।
• आप crt को एक डायरेक्टरी पर भी पॉइंट कर सकते हैं। HAProxy वहां मिलने वाली हर फाइल को लोड करता है और SNI का उपयोग करके प्रति रिक्वेस्ट सही सर्टिफिकेट चुनता है। इस तरह आप एक ही फ्रंटएंड से कई साइटें, हर एक के लिए अलग bind लाइन लिखे बिना, सर्व कर सकते हैं।

CSR और प्राइवेट की जनरेट करें

एक CSR वह एन्कोडेड रिक्वेस्ट है जो आप Certificate Authority को सौंपते हैं। इसे HAProxy मशीन पर, या किसी भी ऐसी जगह पर जनरेट करें जहाँ आप प्राइवेट की को सुरक्षित रख सकें, क्योंकि की आपकी तरफ से कभी बाहर नहीं जाती।

openssl req -new -newkey rsa:2048 -nodes 
  -keyout mydomain.key -out mydomain.csr 
  -subj "/C=US/ST=California/L=San Jose/O=Your Company/CN=mydomain.com" 
  -addext "subjectAltName=DNS:mydomain.com,DNS:www.mydomain.com"

-addext लाइन व्यावहारिक रूप से वैकल्पिक नहीं है। ब्राउज़रों ने वर्षों पहले Common Name के आधार पर होस्ट नामों का मिलान करना बंद कर दिया था और अब केवल Subject Alternative Name पढ़ते हैं, इसलिए केवल CN वाला CSR ऐसा सर्टिफिकेट देता है जो हर वर्तमान ब्राउज़र में विफल हो जाता है। सर्टिफिकेट को कवर करने वाले हर नाम को सूचीबद्ध करें, जिसमें बेयर डोमेन और यदि आप दोनों सर्व करते हैं तो www रूप भी शामिल है।

यदि आप प्रत्येक फील्ड के लिए प्रॉम्प्ट किया जाना पसंद करते हैं तो -subj और -addext विकल्पों को छोड़ दें। किसी भी तरह आपके पास दो फाइलें होंगी: सबमिट करने के लिए mydomain.csr, और रखने के लिए mydomain.key। इसे सबमिट करने से पहले पुष्टि करें कि CSR में वही है जो आप चाहते हैं, या तो हमारे CSR डिकोडर के साथ या स्थानीय रूप से:

openssl req -noout -text -verify -in mydomain.csr

जाँच करें कि SAN प्रविष्टियाँ सूचीबद्ध हैं और सिग्नेचर वेरिफाई होता है। यदि आप कमांड लाइन का बिल्कुल भी उपयोग नहीं करना चाहते हैं, तो हमारा CSR जनरेटर ब्राउज़र में वही जोड़ी बनाता है। अंतर्निहित कमांड्स की अधिक जानकारी हमारी OpenSSL कमांड्स की गाइड में है।

सर्टिफिकेट जारी करवाएँ

CSR को CA के पास सबमिट करें, वह सर्टिफिकेट प्रकार चुनें जो आप जो सुरक्षित कर रहे हैं उससे मेल खाता हो, और वेरिफिकेशन पूरा करें। एक सिंगल-डोमेन सर्टिफिकेट एक होस्ट नाम को कवर करता है, एक वाइल्डकार्ड हर फर्स्ट-लेवल सबडोमेन को कवर करता है, और एक मल्टी-डोमेन (SAN) सर्टिफिकेट असंबंधित नामों की एक सूची को कवर करता है। लोड बैलेंसर के पीछे, मल्टी-डोमेन सामान्य विकल्प है, क्योंकि एक HAProxy इंस्टेंस सामान्यतः कई साइटों के सामने होता है।

CA आपके सर्टिफिकेट और इंटरमीडिएट चेन वाला एक आर्काइव लौटाता है, सामान्यतः एक CA बंडल फाइल के रूप में। दोनों ही पहले से PEM फॉर्मेट में हैं, जो आपको चाहिए। रिन्यूअल की योजना अभी बनाएं, बाद में नहीं: क्योंकि 15 मार्च 2026 से एक सार्वजनिक रूप से भरोसेमंद TLS सर्टिफिकेट अधिकतम 200 दिनों तक ही वैध हो सकता है, मार्च 2027 में यह 100 दिन और मार्च 2029 में 47 दिन हो जाएगा, इसलिए मैनुअल रिप्लेसमेंट जल्द ही व्यावहारिक नहीं रहेगा।

वह PEM फाइल बनाएं जिसे HAProxy पढ़ेगा

सर्टिफिकेट के लिए एक डायरेक्टरी बनाएं और फाइल को वहीं असेंबल करें। शुरू से ही सब कुछ एक जगह रखें; इसे home डायरेक्टरी, /etc/haproxy और /etc/ssl में बांटना ही वह तरीका है जिससे लोग एक फाइल एडिट करते हैं जबकि HAProxy दूसरी पढ़ता है।

sudo mkdir -p /etc/haproxy/certs
sudo chmod 700 /etc/haproxy/certs

सर्टिफिकेट को जोड़ें, फिर इंटरमीडिएट्स को, फिर प्राइवेट की को। रीडायरेक्ट को root के रूप में चलना होगा, इसलिए sudo cat ... > /etc/haproxy/certs/... लिखने के बजाय tee में पाइप करें, क्योंकि पहला तरीका परमिशन एरर के साथ विफल हो जाता है — शेल sudo चलने से पहले ही आउटपुट फाइल को आपके अपने यूज़र के रूप में खोल देता है:

cat mydomain.crt intermediate.crt mydomain.key 
  | sudo tee /etc/haproxy/certs/mydomain.pem > /dev/null

उस फाइल में अब आपकी प्राइवेट की प्लेन टेक्स्ट में मौजूद है, इसलिए आगे बढ़ने से पहले इसे लॉक कर दें:

sudo chown root:root /etc/haproxy/certs/mydomain.pem
sudo chmod 600 /etc/haproxy/certs/mydomain.pem

यहाँ root-ओनली परमिशन्स सही हैं, कोई बाधा नहीं। HAProxy को सुपरयूज़र प्रिविलेज के साथ शुरू किया जाता है, जो इसके मैनुअल के अनुसार आवश्यक है ताकि यह बाद में अपने ही अप्रिविलेज्ड यूज़र में स्विच कर सके, और यह उस स्टार्टअप के दौरान ही सर्टिफिकेट पढ़ता है। परमिशन्स को इस तरह विस्तृत करने की ज़रूरत नहीं है कि haproxy यूज़र की को पढ़ सके, और आपको ऐसा करना भी नहीं चाहिए।

यदि आपने CSR किसी अलग मशीन पर बनाया है, तो पहले फाइलों को कॉपी करें और बाद में ट्रांज़िट डायरेक्टरी से कॉपियों को हटा दें:

scp mydomain.crt intermediate.crt mydomain.key sysadmin@haproxy-server:/home/sysadmin/

HAProxy को कॉन्फ़िगर करें

सर्वर पर ही एक टर्मिनल एडिटर, जैसे nano या vim, में /etc/haproxy/haproxy.cfg खोलें। इसे वर्कस्टेशन पर एडिट करने के बजाय वहीं एडिट करें, ताकि आप कभी भी ऐसी फाइल रीलोड न करें जो आपने टेस्ट की गई फाइल से अलग हो।

फ्रंटएंड

एक फ्रंटएंड प्लेन HTTP और HTTPS दोनों स्वीकार कर सकता है। रीडायरेक्ट के लिए पोर्ट 80 को बाइंड करें, सर्टिफिकेट के साथ पोर्ट 443 को बाइंड करें, और बाकी सब कुछ बैकएंड को भेजें:

frontend web_frontend
    mode http
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem alpn h2,http/1.1

    http-request redirect scheme https code 301 unless { ssl_fc }

    default_backend web_servers

alpn h2,http/1.1 HTTP/2 ऑफर करता है और HTTP/1.1 पर फॉलबैक करता है। रीडायरेक्ट तभी फायर होता है जब रिक्वेस्ट TLS पर नहीं आई हो, जिसकी जाँच ssl_fc करता है, इसलिए पोर्ट 443 पर आने वाली रिक्वेस्ट्स सीधे गुज़र जाती हैं।

हर TLS विकल्प को उस एक bind लाइन पर रखें

यहीं पर HAProxy कॉन्फ़िगरेशन सबसे अधिक गलत होते हैं, और यह चुपचाप विफल होता है। गाइड्स अक्सर TLS हार्डनिंग को एक दूसरे चरण के रूप में प्रस्तुत करते हैं, पोर्ट 443 के लिए एक नई bind लाइन दिखाते हुए जिसमें अतिरिक्त विकल्प होते हैं। यदि आप मौजूदा लाइन को एडिट करने के बजाय वह लाइन जोड़ते हैं, तो आपके पास एक ही पोर्ट के लिए दो bind लाइनें हो जाती हैं, और HAProxy इस पर कोई शिकायत नहीं करता। यह शुरू होता है, और अलग-अलग TLS सेटिंग्स के साथ पोर्ट 443 पर दो अलग लिसनिंग सॉकेट खोलता है। किसी दिए गए कनेक्शन का किस सॉकेट पर उतरना है, यह आपके नियंत्रण में नहीं है, इसलिए आपकी हार्डनिंग आपके लगभग आधे ट्रैफ़िक को ही कवर करती है।

कॉन्फ़िगरेशन चेक भी इसे नहीं पकड़ता, और इसका अपना डॉक्यूमेंटेशन बताता है कि क्यों: -c “केवल कॉन्फ़िगरेशन फाइलों की जाँच करता है और बाइंड करने की कोशिश करने से पहले बाहर निकल जाता है”। डुप्लिकेट लिसनर एक बाइंडिंग-टाइम कंडीशन है, इसलिए एक सिंटैक्स चेक इसे कभी नहीं देख पाएगी।

इसके बजाय ग्लोबल डिफॉल्ट्स सेट करें, ताकि फाइल में हर bind लाइन उन्हें इनहेरिट करे और डुप्लिकेट करने के लिए कुछ भी न हो:

global
    ssl-default-bind-options ssl-min-ver TLSv1.2 prefer-client-ciphers
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

उस ब्लॉक को कहीं भी कॉपी करने से पहले यह जानना उपयोगी है: ssl-min-ver पहले से ही डिफॉल्ट रूप से TLSv1.2 है, HAProxy के अपने शब्दों में। इसे TLSv1.2 पर सेट करने से कुछ भी नहीं बदलता और यह केवल आपके इरादे को दर्ज करता है, जो ठीक है, लेकिन यह वह सुरक्षा सुधार नहीं है जिस रूप में इसे अक्सर प्रस्तुत किया जाता है। दो सिफर सेटिंग्स असली काम करती हैं, और वे जानबूझकर अलग हैं: ssl-default-bind-ciphers TLS 1.2 और उससे नीचे पर लागू होता है, ssl-default-bind-ciphersuites TLS 1.3 पर लागू होता है। केवल पहले को सेट करें और आपके TLS 1.3 सूट अपनी डिफॉल्ट सेटिंग्स पर ही रहेंगे।

बैकएंड

हर सर्वर को एक असली एड्रेस दें। यह जितना दिखता है उससे ज्यादा महत्वपूर्ण है:

backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check

server web1 :80 check के रूप में लिखी गई एक सर्वर लाइन, जिसमें एड्रेस छोड़ दिया गया है, कोई एरर नहीं उठाती। HAProxy इसे स्वीकार करता है और गायब एड्रेस को 0.0.0.0 के रूप में रिज़ॉल्व करता है, जिसे इसका मैनुअल एक विशेष मान मानता है जिसका अर्थ है कि कनेक्शन को उसी IP एड्रेस पर फॉरवर्ड किया जाता है जिससे क्लाइंट कनेक्ट हुआ था। वह एड्रेस HAProxy स्वयं है, इसलिए बैकएंड चुपचाप HAProxy के अपने पोर्ट 80 की ओर पॉइंट करता है, जो वही फ्रंटएंड है जिसे आपने अभी कॉन्फ़िगर किया है। ट्रैफ़िक किसी एप्लिकेशन तक पहुंचने के बजाय रीडायरेक्ट में वापस लूप हो जाता है, और हेल्थ चेक स्वस्थ दिखते हैं क्योंकि वहां वास्तव में कुछ सुन रहा है। यदि एक लोड बैलेंसर हर HTTPS रिक्वेस्ट का जवाब स्वयं की ओर रीडायरेक्ट के साथ देता है, तो पहले सर्वर लाइनें जांचें।

चूंकि HAProxy TLS को टर्मिनेट करता है, बैकएंड्स को पोर्ट 80 पर प्लेन HTTP प्राप्त होता है और उन्हें अपने स्वयं के किसी सर्टिफिकेट की ज़रूरत नहीं होती। यदि पॉलिसी को उस लेग पर भी एन्क्रिप्शन की आवश्यकता है, तो सर्वर लाइनों पर ssl verify required और एक CA फाइल जोड़ें और उन्हें पोर्ट 443 की ओर पॉइंट करें।

ओरिजिनल स्कीम को बैकएंड में पास करें। चूंकि बैकएंड अब प्लेन HTTP प्राप्त करता है, कोई भी एप्लिकेशन जो एब्सोल्यूट URLs जनरेट करता है, जैसे WordPress, Django और Rails सभी करते हैं, वह उन्हें http:// के साथ जनरेट करेगा, जो मिक्स्ड कंटेंट या एप्लिकेशन द्वारा स्वयं बनाए गए रीडायरेक्ट लूप के रूप में सामने आता है। फ्रंटएंड में एक लाइन जोड़ें:

http-request set-header X-Forwarded-Proto https if { ssl_fc }

और बैकएंड में एक और, जो असली क्लाइंट IP एड्रेस भी पास करती है:

option forwardfor

अधिकांश फ्रेमवर्क्स को फिर इन हेडर्स पर भरोसा करने के लिए बताना पड़ता है; वह हिस्सा एप्लिकेशन में कॉन्फ़िगर किया जाता है, HAProxy में नहीं।

इसे लागू करने से पहले कॉन्फ़िगरेशन की जाँच करें

किसी अनवेरिफाइड फाइल पर लोड बैलेंसर को कभी रीस्टार्ट न करें। पहले वेलिडेट करें:

sudo haproxy -c -V -f /etc/haproxy/haproxy.cfg

-V के साथ यह सफलता पर Configuration file is valid प्रिंट करता है और एग्ज़िट स्टेटस शून्य लौटाता है। इसके बिना, सफलता खामोश रहती है। कोई भी चेतावनी रिपोर्ट की जाती है चाहे फाइल वैलिड हो या नहीं, इसलिए लाल टेक्स्ट की अनुपस्थिति पर भरोसा करने के बजाय आउटपुट पढ़ें।

रीस्टार्ट के बजाय रीलोड करें

sudo systemctl reload haproxy

यह अंतर लोड बैलेंसर पर वाकई महत्वपूर्ण है। एक रीलोड एक नई प्रोसेस शुरू करता है और पुरानी को “जो कर रहे हैं उसे पूरा करने और छोड़ देने” का संकेत देता है, इसलिए पहले से चल रही रिक्वेस्ट्स सामान्य रूप से पूरी होती हैं। एक रीस्टार्ट पुरानी प्रोसेस को “जो कर रहे थे उसे पूरा किए बिना तुरंत समाप्त होने” का संकेत देता है, जो लाइव कनेक्शनों को काट देता है, जिसमें अपलोड्स और लंबे समय तक चलने वाले API कॉल्स भी शामिल हैं। रीस्टार्ट का उपयोग केवल तब करें जब कोई रीलोड बदलाव को नहीं पकड़ सकता, जैसे ग्लोबल सेक्शन की प्रोसेस सेटिंग्स बदलने के बाद।

पुष्टि करें कि सर्विस वापस आ गई है और दोनों पोर्ट्स पर सुन रही है:

sudo systemctl status haproxy
sudo ss -tlnp | grep haproxy

यहाँ आपको प्रति पोर्ट ठीक एक लिसनिंग सॉकेट चाहिए। पोर्ट 443 पर दो का मतलब है कि आपके पास ऊपर वर्णित डुप्लिकेट bind लाइन है।

सत्यापित करें कि सर्टिफिकेट सर्व किया जा रहा है

जाँचें कि HAProxy वास्तव में क्या प्रस्तुत करता है, चेन सहित, स्वयं सर्वर से:

openssl s_client -connect mydomain.com:443 -servername mydomain.com < /dev/null

आउटपुट के शीर्ष पर Certificate chain सेक्शन पढ़ें। आपका सर्टिफिकेट depth 0 पर और इंटरमीडिएट depth 1 पर दिखना चाहिए। यदि depth 1 गायब है, तो इंटरमीडिएट कभी PEM फाइल में नहीं पहुंचा, और साइट कुछ ब्राउज़रों में काम करेगी जबकि दूसरों में विफल हो जाएगी। इसका आकलन करते समय Verify return code लाइन को अनदेखा करें: यह केवल चेन का फैसला रिपोर्ट करती है, और यह उन स्थितियों में भी सफल दिख सकती है जिनका आप जो टेस्ट कर रहे हैं उससे कोई संबंध नहीं है।

फिर बाहर से पुष्टि करें, जहाँ परिणाम वही दर्शाता है जो असली विज़िटर्स को मिलता है। हमारा SSL Checker सर्टिफिकेट, चेन और एक्सपायरी डेट रिपोर्ट करता है।

रिन्यूअल्स और ऑटोमेशन

PEM फाइल को बदलना ही पूरी रिन्यूअल प्रक्रिया है: इसे नए सर्टिफिकेट और उसी या एक नई की से फिर से बनाएं, फिर रीलोड करें। HAProxy कॉन्फ़िगरेशन में कुछ भी एक्सपायरी डेट का संदर्भ नहीं देता, इसलिए जब तक फाइल पथ वही रहता है, कोई कॉन्फ़िग एडिट की ज़रूरत नहीं है।

सर्टिफिकेट की लाइफटाइम कम होते जाने के साथ, अभी ऑटोमेशन सेट करना उचित है। HAProxy को वर्शन 3.2 में एक बिल्ट-इन ACME क्लाइंट मिला, जिसे एक acme सेक्शन के माध्यम से कॉन्फ़िगर किया जाता है। इसे फिलहाल एक प्रीव्यू के रूप में मानें, प्रोडक्शन इंफ्रास्ट्रक्चर के रूप में नहीं: यह 3.4 में अभी भी एक्सपेरिमेंटल के रूप में चिह्नित है और ग्लोबल सेक्शन में expose-experimental-directives की आवश्यकता है, यह केवल http-01, dns-01 और dns-persist-01 चैलेंज प्रकारों का समर्थन करता है, और इसके द्वारा जनरेट किए गए सर्टिफिकेट को डिस्क तक पहुंचने के लिए स्टैट्स सॉकेट से डंप करना पड़ता है। dns-persist-01 प्रकार, जो 3.4 में जोड़ा गया, एक स्टैटिक TXT रिकॉर्ड का उपयोग करता है जो एक बार सेट होता है और रिन्यूअल्स के बीच कभी नहीं बदलता, इसलिए इसे हर रिन्यूअल पर DNS प्रोवाइडर API तक राइट एक्सेस की आवश्यकता नहीं होती। स्थापित विकल्प यह है कि एक बाहरी ACME क्लाइंट चलाया जाए और उसके डिप्लॉय चरण से PEM फाइल को फिर से बनाया जाए और HAProxy को रीलोड किया जाए, जो वही पैटर्न है जो हमारी Apache और NGINX के लिए ACME गाइड में वर्णित है।

अक्सर पूछे जाने वाले प्रश्न

यदि सर्टिफिकेट इंस्टॉल हो गया है लेकिन ब्राउज़र फिर भी शिकायत करते हैं, तो हमारी सामान्य SSL त्रुटियों की गाइड्स सामान्य कारणों को कवर करती हैं, जो अक्सर एक अपूर्ण चेन या ऐसा नाम होता है जो सर्टिफिकेट में सूचीबद्ध नहीं है।