Certbot: मैं ACMEv2 और वाइल्डकार्ड प्रमाणपत्रों की पुनर्प्राप्ति को कैसे सक्षम करूं?

आपको DNS-01 चुनौती का उपयोग करना चाहिए। इसका मतलब है कि आपके पास अपने सर्वर से डीएनएस ज़ोन को संशोधित और प्रकाशित और अपडेट करने का एक तरीका होना चाहिए।

क्या आप कृपया मुझे इसके लिए झंडा बता सकते हैं?

यह सिर्फ एक झंडा नहीं है, बल्कि दस्तावेज़ में सब कुछ उपलब्ध है। वे वहां सूचीबद्ध कई DNS प्रदाताओं के लिए कुछ प्लगइन्स हैं, यदि आपका नहीं है तो आप इसके लिए समर्थन मांगने के लिए यहां एक फीचर अनुरोध खोल सकते हैं (उदाहरण के लिए गंदी जैसी चीजों के लिए पहले से ही कुछ खुले हैं, इसलिए खोलने से पहले खोज का उपयोग करना सुनिश्चित करें। एक नया)।

हम नहीं, आपको वास्तव में certbot >= 0.22 की आवश्यकता है, आपकी पहली पोस्ट में इसे याद करने के लिए खेद है।

ठीक है.... मैं इसे कैसे स्थापित करूं? क्या मुझे स्रोत से संकलन करना है?

आप या तो इसके पीपीए में प्रकाशित होने की प्रतीक्षा कर सकते हैं, पीआईपी के माध्यम से स्थापित कर सकते हैं या कुछ इसी तरह या वास्तव में स्रोत से बना सकते हैं।

क्या मैं तुम हो, मैं इसके बजाय आधिकारिक पैकेज के अपडेट होने की प्रतीक्षा करूंगा। यह आपको डीएनएस चुनौती को ठीक से स्थापित करने के लिए कुछ समय देगा, जिसे आप पहले से ही वाइल्डकार्ड के बिना कोशिश कर सकते हैं कि सब कुछ काम करता है, और फिर जब अपडेट उपलब्ध होगा (जिसमें अधिक समय नहीं लगना चाहिए), आप इसके लिए तैयार होंगे अपना वाइल्डकार्ड प्रमाणपत्र प्राप्त करें।

हाँ, आप स्रोतों से सर्टिफिकेट का उपयोग कर सकते हैं

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

TXT रिकॉर्ड जोड़ें एंटर दबाएं। आपको एक और रिकॉर्ड मिलेगा। इसे भी जोड़ें।

फिर दूसरी टर्मिनल विंडो में जांचें कि क्या रिकॉर्ड तैनात किए गए थे:

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

अगर ठीक है तो वापस जाएं और एंटर दबाएं

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

अद्यतन: गिस्ट पर स्थापना, स्थापना और प्रमाणपत्रों को नवीनीकृत करने के चरणों के साथ संपूर्ण

इतनी अच्छी तरह से उत्तर देने के लिए धन्यवाद @ArchangeGabriel! हम उबंटू के लिए अपने पैकेज अपडेट करने पर काम कर रहे हैं, उम्मीद है कि वे जल्द ही बाहर हो जाएंगे।

@ohemorange आपका स्वागत है! ईमानदारी से, मुझे डर था कि हम वाइल्डकार्ड प्रमाणपत्र प्राप्त करने की कोशिश कर रहे लोगों की आमद देखेंगे, जबकि DNS-01 चुनौती क्या है, इसके बारे में कोई जानकारी नहीं है, लेकिन जाहिर तौर पर ऐसा नहीं हुआ (अभी तक कम से कम)।

अच्छा एक @talyguryn , @talyguryn पर अनुवर्ती कार्रवाई के रूप में

वाइल्डकार्ड के साथ एपेक्स पर एक सर्टिफिकेट बनाते समय आपको __दो__ चुनौतियां मिलेंगी।

-d "example.com, *.example.com" _का उपयोग करके मुझे शीर्ष पर एक प्रमाणपत्र और शीर्ष पर वाइल्डकार्ड दें_

आपको _दो बार चुनौती दी जाएगी, एक बार example.com और फिर से *.example.com

तो यह मत सोचो कि दूसरी चुनौती पर यह विफल हो गया है.. और आपको मूल्य बदलने की जरूरत है। बस डीएनएस में अतिरिक्त चुनौती जोड़ें। प्रसार की प्रतीक्षा करें और जारी रखें,

संभवत: आउटपुट को बदला जाना चाहिए ताकि यह देखना आसान हो कि किस डोमेन को चुनौती दी गई है?

डॉक्स: https://sinkcup.github.io/letsencrypt-wildcard-certificate

@AubreyHewes , मुझे एक ही समस्या है। मुझे नहीं पता कि example.com और *.example.com दोनों के लिए एकल प्रमाणपत्र कैसे जारी किया जाए। दुर्भाग्य से, सर्टिफिकेट के लिए आवश्यक है कि मैं TXT रिकॉर्ड को दो बार संशोधित करूं। यह किसी एक डोमेन के लिए सत्यापन विफल होने का कारण बनता है। क्या इसके चारों ओर एक रास्ता है?

@ नाथन-एल्डन आपको एक ही समय में दोनों TXT रिकॉर्ड सेट करने होंगे। दूसरा जोड़ते समय पहले वाले को न हटाएं।

@ नाथन-एल्डेन
आपको दो चुनौतियाँ मिलती हैं .. यह _लगता है_ जैसे सर्टबॉट चाहता है कि आप उसी TXT को फिर से संशोधित करें। लेकिन दूसरा मान दूसरे डोमेन के लिए है, इसलिए दूसरे डोमेन के लिए एक नया TXT रिकॉर्ड जोड़ें।

अर्थात
यदि -d "example.com,*.example.com" का उपयोग कर रहे हैं तो पहली चुनौती example.com इसलिए इसके लिए एक TXT जोड़ें। प्रसार के बाद जारी रखें।
दूसरी चुनौती *.example.com इसलिए इसके लिए एक TXT जोड़ें। प्रसार के बाद जारी रखें।

मुझे डॉकर संस्करण का उपयोग करने का अच्छा अनुभव था। एक साइड नोट के रूप में, TXT प्रविष्टि के लिए TTL को 1 मिनट की तरह सेट करना सुनिश्चित करें ताकि आपको दूसरी प्रविष्टि के प्रचार के लिए एक घंटे तक प्रतीक्षा न करनी पड़े।

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

आश्चर्य है। हमें dns-01 आवश्यकता क्यों है। क्या आप सिर्फ पोर्ट 80 ( http चुनौती का कोई भी रूप) पर एक सर्वर नहीं बना सकते हैं और जांच कर सकते हैं कि मैं एन यादृच्छिक उप डोमेन उत्पन्न करके और कनेक्ट करके वाइल्डकार्ड डोमेन का मालिक हूं?

@AubreyHewes , मुझे पता चला है कि आपको DNS में केवल एक चुनौती/रिकॉर्ड की आवश्यकता है - बस सही अनुमान लगाना है।

मेरे पास चार डोमेन और उनके वाइल्डकार्ड के लिए एक प्रमाणपत्र है। प्रत्येक डोमेन में केवल एक TXT _acme-challenge होता है। यह काफी असंगत है क्योंकि तीन डोमेन सर्टिफिकेट आउटपुट में पहली चुनौती के साथ काम करते हैं और हर बार जब मैं इसे चलाता हूं तो मान समान होते हैं।

चौथा डोमेन आउटपुट में पहले रिकॉर्ड के साथ काम नहीं करता है, लेकिन दूसरे के साथ काम करता है और हर बार जब मैं सर्टिफिकेट चलाता हूं तो यह बदल जाता है।

मैं इस आदेश का उपयोग करता हूं:

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

मैंने इसे परीक्षण और त्रुटि से किया - मुझे नहीं पता था कि आपके पास अलग-अलग मूल्यों के साथ दो समान DNS रिकॉर्ड हो सकते हैं :-) अगली बार मैं कोशिश करूँगा।

@robertvalik example.com और *.example.com सहित दो अलग-अलग सत्यापन के लिए समान TXT रिकॉर्ड मान का उपयोग करना संभव नहीं है।

आइए एन्क्रिप्ट करें एक प्राधिकरण को कुछ समय के लिए पुन: उपयोग करने की अनुमति देता है, वर्तमान में 30 दिन। यदि आपके खाते ने हाल ही में कुछ सत्यापित किया है, तो वह दोबारा सत्यापन किए बिना अधिक प्रमाणपत्र जारी कर सकता है। हालांकि, Certbot की सीमाओं (#5342) के कारण, Certbot आपसे वही TXT रिकॉर्ड फिर से सेट करने के लिए कहता है, भले ही इसे दोबारा चेक नहीं किया जाएगा।

तो क्या हुआ होगा कि नामों में से एक के लिए पहले से ही एक वैध प्राधिकरण था, इसलिए यह तथ्य कि आवश्यक DNS रिकॉर्ड अब मौजूद नहीं था, कोई मायने नहीं रखता था।

@ Francoism90 कई कारणों से एक वाइल्डकार्ड डोमेन चाह सकता है, कोई कुछ स्थिर सबडोमेन की सेवा कर सकता है, अन्य, संभावित अनंत सबडोमेन (उदाहरण के लिए एक सेवा के रूप में सॉफ़्टवेयर) की सेवा कर रहा है। बाद के मामले में (मेरे मामले में) पहले से ही DNS फ़ाइल में एक वाइल्डकार्ड है, और वास्तव में किसी भी यादृच्छिक उपडोमेन को ठीक से हल करना चाहिए। मैं सोच रहा हूं कि इस परिदृश्य के लिए http चुनौती का एक रूप प्रदान किया जा सकता है या नहीं। आपके कड़ी मेहनत के लिए धन्यवाद!

मुझे जारी कर प्रमाण पत्र बनाने में सफलता मिली

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

अब मैं बस सोच रहा हूं कि मैं प्रमाणपत्रों को कैसे नवीनीकृत कर सकता हूं

<> certbot renew
<> certbot-renew
<> certbot-auto renew

मैं उलझन में हूं, मैंने ./certbot-auto renew की कोशिश की क्योंकि मैंने अनुरोध करते समय उसी कमांड का उपयोग किया था, लेकिन मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि यह सही तरीका है या नहीं।

क्या हम वाइल्डकार्ड प्रमाणीकरण को स्वचालित कर सकते हैं?

@ ufo911 बिल्कुल। उदाहरण के लिए, Certbot के RFC 2136 प्लगइन का उपयोग करना:

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

या एक्मे-डीएनएस मैनुअल ऑथ हुक :

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

यदि आपको सहायता की आवश्यकता है, तो आप Let's Encrypt फोरम पर एक विषय पोस्ट कर सकते हैं।

@mnordhoff
क्या प्रत्येक नवीनीकरण पर DNS TXT रिकॉर्ड का लाइव होना आवश्यक है?

@ ufo911 बेशक, एक नवीनीकरण पिछले पैरामीटरों का पुन: उपयोग करने के लिए केवल एक प्रमाणपत्र अनुरोध है।

@ArchangeGabriel Stange यह मुझे बता रहा है कि यह मुझे नए TXT-रिकॉर्ड सेट करने के लिए कहता है:

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

क्या यह सामान्य है? नए टोकन क्यों बनाए जा रहे हैं?

क्षमा करें यदि मैं स्पष्ट नहीं था, हाँ प्रत्येक अनुरोध पर एक नया TXT रिकॉर्ड है। क्योंकि यह एक चुनौती-प्रतिक्रिया सत्यापन है, और चुनौती का पुन: उपयोग करना एक बहुत बुरा विचार होगा।

तो वास्तव में आप प्रमाण पत्र प्राप्त करते ही TXT रिकॉर्ड को हटा सकते हैं, लेकिन हर बार नवीनीकरण करने पर प्रकाशित करने के लिए एक नया TXT रिकॉर्ड होता है (और एक बार सफल होने पर हटा दें)।

@ArchangeGabriel हम्म, यह मत सोचो कि यह मेरे लिए एक विकल्प है। एक नया TXT-रिकॉर्ड बनाने में 24 घंटे का समय लग सकता है और यदि कुछ गलत होता है, तो आपके पास बहुत अधिक डाउनटाइम होगा।

मैं इसके बजाय सामान्य तरीके का उपयोग करूंगा। :)

ज़रूर, DNS चुनौती सबसे आसान नहीं है। लेकिन वाइल्डकार्ड के लिए, कम से कम वर्तमान में कोई अन्य संभावना नहीं है। मुझे नहीं पता कि उदाहरण के लिए वाइल्डकार्ड स्पेस में एक यादृच्छिक उपडोमेन नाम को चुनौती भेजकर इसे बदला जा सकता है (उदाहरण के लिए यदि आप *.domain.com मांगते हैं, तो यह somerandomstring.domain.com पर चुनौती प्रतिक्रिया को पढ़ने का प्रयास करेगा। *.domain.com स्थान पर नियंत्रण है)। इस तरह DNS में आपका वाइल्डकार्ड पुनर्निर्देशन पर्याप्त होगा।

@ArchangeGabriel यह एक अच्छा विकल्प होगा, लेकिन क्या इस मामले में DNS सत्यापन की अभी भी आवश्यकता होगी? क्या यह सुरक्षित वाइल्डकार्ड सेटअप के लिए आवश्यक कुछ प्रदान करता है?

नहीं, मेरा विचार डीएनएस चुनौती के विकल्प की पेशकश करना होगा।

वाइल्डकार्ड सेटअप के लिए, आपको सभी उप डोमेन पर नियंत्रण साबित करना होगा। ऐसा करने का एकमात्र स्पष्ट तरीका संबंधित DNS ज़ोन के तकनीकी स्वामित्व को साबित करना है।

अब मैं सोच रहा हूं कि क्या अन्य प्रकार की चुनौतियों की तरह कोई और तरीका हो सकता है। यादृच्छिक उपडोमेन पूछना यह साबित करेगा कि वाइल्डकार्ड पुनर्निर्देशन पर आपका नियंत्रण है। मुझे नहीं पता कि आईईटीएफ के लिए यह पर्याप्त होगा या नहीं, मुझे लगता है कि उन्होंने इसके बारे में सोचा है और कुछ मुद्दे होने चाहिए।

उदाहरण के लिए मैं सोच रहा हूं कि क्या यह मामला संभव है:
- somespecificsub.domain.com किसी दिए गए IP की ओर इशारा करता है;
- *.domain.com और domain.com दूसरे IP की ओर इशारा करते हैं।

उस स्थिति में, आप मुख्य डोमेन और somespecificsub.domain.com को छोड़कर किसी भी उप डोमेन के अनुरोधों का जवाब दे सकते हैं। और मुझे लगता है कि आपको *.domain.com प्रमाणपत्र देना सही नहीं होगा। तो अगर यह संभव है, तो हमें कुछ अतिरिक्त सेटअप की आवश्यकता होगी। एक स्थायी TXT रिकॉर्ड की तरह यह बताता है कि यह वाइल्डकार्ड चुनौती प्रतिक्रिया के लिए यादृच्छिक उपडोमेन सत्यापन करने के लिए अधिकृत है। इस तरह DNS कॉन्फ़िगरेशन केवल आग और भूल जाएगा, और आप वाइल्डकार्ड को अधिक आसानी से मान्य कर सकते हैं।

वैसे भी, मुझे नहीं पता कि इस पर किसके साथ चर्चा की जानी चाहिए और किस बिंदु पर उन्होंने इस सेटअप पर विचार किया है, न ही वाइल्डकार्ड को सुरक्षित रूप से वितरित करने के लिए सटीक आवश्यक मानदंड क्या हैं। मुझे लगता है कि मुझे इसके लिए सिर्फ आरएफसी पढ़ना चाहिए, लेकिन मेरे पास इसके लिए समय नहीं है।