Certbot: يجب أن تسمح قائمة بذاتها للمنافذ البديلة بالالتزام (ولكن ليس المصادقة عليها)

أعتقد أن العميل لديه بالفعل الوظيفة التي تريدها ، ومع ذلك ، لم يتم تقديمها بطريقة سهلة الاستخدام للغاية حيث تم استخدامها بشكل أساسي للاختبار. العميل لديه العلامات التالية:

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

تسمح لك هذه العلامات بتحديد المنافذ التي يقوم العميل بإعداد تحديات التحقق من صحة المجال لها. بشكل عام ، يجب أن يكون --tls-sni-01 هو المنفذ الذي قمت بتوجيه حركة المرور الواردة إليه 443 و --http-01-port هو المنفذ الذي قمت بتوجيه حركة المرور الواردة إليه من المنفذ 80.

لن تحتاج إلى استخدام كلتا العلامتين ، ومع ذلك ، يقوم كل من مستقل بشكل افتراضي بتنفيذ تحديات تزيد عن 443. يمكنك التحكم في هذا السلوك باستخدام العلامة التالية:

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

آمل أن يساعد هذا!

شكرا ، سأحاول هذا غدا.

إذا نجح هذا الأمر ، فينبغي حقًا استخدامه كمثال. من الأسهل بكثير إعادة تشغيل الخادم لتمكين / تعطيل الوكيل لتمرير هذه المنافذ بدلاً من أخذ كل شيء في وضع عدم الاتصال للتعامل مع عملية التحقق ،

في 22 آذار (مارس) 2016 ، الساعة 3:16 مساءً ، كتب bmw [email protected] :

أعتقد أن العميل لديه بالفعل الوظيفة التي تريدها ، ومع ذلك ، لم يتم تقديمها بطريقة سهلة الاستخدام للغاية حيث تم استخدامها بشكل أساسي للاختبار. العميل لديه العلامات التالية:

- TLS-sni-01 منفذ TLS_SNI_01_PORT
رقم المنفذ لأداء تحدي tls-sni-01. بولدر
في وضع الاختبار الافتراضي إلى 5001. (الافتراضي: 443)
-http-01 منفذ HTTP01_PORT
المنفذ المستخدم في تحدي SimpleHttp. (افتراضي: 80)
تسمح لك هذه العلامات بتحديد المنافذ التي يقوم العميل بإعداد تحديات التحقق من صحة المجال لها. بشكل عام ، يجب أن يكون --tls-sni-01 هو المنفذ الذي قمت بتوجيه حركة مرور المنفذ الوارد 443 إليه و-http-01-port يجب أن يكون المنفذ الذي قمت بتوجيه حركة مرور المنفذ الوارد 80 إليه.

لن تحتاج إلى استخدام كلتا العلامتين ، ومع ذلك ، يقوم كل من مستقل بشكل افتراضي بتنفيذ تحديات تزيد عن 443. يمكنك التحكم في هذا السلوك باستخدام العلامة التالية:

- التحديات المدعومة بشكل قياسي STANDALONE_SUPPORTED_CHALLENGES
التحديات المدعومة. يفضل بالترتيب الذي هم عليه
المدرجة. (افتراضي: tls-sni-01، http-01)
آمل أن يساعد هذا!

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub

jvanasco يستخدم معظم الأشخاص المكون الإضافي webroot لحالة الاستخدام هذه ولكن نعم ، قد يكون مثال تمرير الوكيل nginx جيدًا. لا تتردد في عمل علاقات عامة تضيف واحدة إلى المستندات ؛ هذه حالة استخدام متخصصة بدرجة كافية بحيث من المحتمل أن تحصل على قسم جديد في أسفل هذا الملف:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

ومع ذلك ، يمكنك الارتباط به من قسم Standalone الحالي:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

لم نتلق أي رد بشأن هذا الأمر ، لذا أغلق هذا الموضوع. الرجاء التعليق على الصراخ في وجهي إذا كنت تريد مني إعادة فتح.

يبدو أن هذا لا يعمل. @بي إم دبليو

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

أرى أن المصادقة تأتي عبر المنفذ 80 ، لكن خادم python2 بدأ في 8484.

Nginx على المنفذ 80

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

تعديل:
أرى أن كلا من --tls-sni-01-port 5001 --http-01-port 5002 كلاهما مطلوب!

يحرر:
ما زلت غير أكثر حكمة بشأن كيفية قيام الخادم المستقل بتدوير الخادم والمصادقة عليه

هناك أيضًا مشكلات تتعلق بتجاهل --tls-sni-01-port :

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

لاحظ أن الطلب ذهب بالفعل إلى :443 ؛ لدي بالفعل خدمة HTTPS تعمل على :443 وتقدم شهادة مختلفة. هذا ، مع ذلك ، يعمل مع renew .

لديك أيضًا مشكلة مع --tls-sni-01-port :

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

لا يسمح لك --http-01-port / --tls-sni-01-port بتحديد المنفذ الذي سيتصل به Let's Encrypt بخادمك عليه. سيستخدم دائمًا 80/443 على التوالي. كل هذه العلامات تسمح لك بالقيام به هو التحكم في المنافذ التي يستمع إليها Certbot من أجل المكونات الإضافية مثل المنفصلة. يكون هذا مفيدًا إذا كنت تقوم بتوجيه كل حركة مرور المنفذ 80 إلى المنفذ 8080 على سبيل المثال.

نعم ، فقط تنبيه ، يجب أن يكون لديك منفذ 80 يمكن الوصول إليه على عنوان IP العام.

هناك شيء مفقود جدًا في الوثائق ، يعني أيضًا أن Let's Encrypt غير مناسب للغرض لأقلية لا تستطيع التحكم في حركة المرور الواردة على 80 (على الأرجح الصين / بعض مزودي خدمة الإنترنت ، وجدران حماية الشركة)

لقد قرأت من خلال العديد من المنشورات حول هذا الموضوع ، يبدو أن القدرة على الاستماع على 80 يعتبر مقياسًا لكسب الأمان / الثقة لأنه منفذ متميز في مربع Nix.

على الرغم من أنه يبدو أننا لا نتعرف على استخدام التشفير للشهادات خارج خوادم الويب .. على سبيل المثال خادم بريد إلكتروني وما إلى ذلك ، فقد أرغب فقط في تشغيل سريع على المنفذ 7722 لتطبيق عقدة للتعامل مع المصادقة ثم إيقاف التشغيل لأنني لا أفعل ذلك. ر تشغيل خادم ويب .. ولكن الذهاب الرقم.

يعني أيضًا أنك إذا كنت تستخدم الأتمتة مثل Chef على سبيل المثال ، فأنت بحاجة إلى تكوين شهادات موقعة ذاتيًا لتتمكن من تشغيل nginx نظرًا لأن التكوين سيحتوي على SSL يجب أن يحتوي على شهادة صالحة على الأقل.

هناك خيار آخر على الرغم من أنك إذا قمت بتشغيل SSL فقط وهو أن يكون لديك خادم ويب مختلف يخدم 80 حتى يتمكن من ضمان تنزيل الشهادة قبل محاولة nginx للإقلاع. (إعداد مزعج)

يتم الآن توزيع الشيف الخاص بي من خلال ما يلي:

1. قم بتثبيت شهادة موقعة ذاتيًا.
2. التمهيد nginx (مع الشهادة الذاتية)
3. قم بتشغيل سيرت
4. رابط رمزي يشهد لموقعي
5. إعادة تحميل nginx

مرسل من الايفون الخاص بي

في 15 سبتمبر 2016 ، في تمام الساعة 23:18 ، كتب براد وارن [email protected] :

--http-01-port / - لا يسمح لك منفذ tls-sni-01-port بتحديد أي منفذ سوف يتصل Let's Encrypt بخادمك عليه. سيستخدم دائمًا 80/443 على التوالي. كل هذه العلامات تسمح لك بالقيام به هو التحكم في المنافذ التي يستمع إليها Certbot من أجل المكونات الإضافية مثل المنفصلة. يكون هذا مفيدًا إذا كنت تقوم بتوجيه كل حركة مرور المنفذ 80 إلى المنفذ 8080 على سبيل المثال.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

يستمع خادم الويب الخاص بي إلى منفذ واحد فقط لاتصالات SSL وهو ليس الافتراضي 443. وذلك لأن خادم الويب وراء خدمة VPN التي تسمح بإعادة توجيه المنفذ ، ولكنها لا تسمح بإعادة توجيه المنفذ إلى المنفذ 80 أو 443.

أحاول تكوين Let's Encrypt على هذا الخادم ولكن في السجلات يمكنني رؤية عميل acme يحاول الاتصال على المنفذ 80 (الذي لا يمكن الوصول إليه) ويفشل.

الخطأ الذي أحصل عليه هو حالة "تعذر الاتصال" 400.

قيمة "addressResolved" صحيحة ، فقط قيمة "port" تساوي 80 وأن جميع عناوين url غير صحيحة ، لأنه يجب تحديد المنفذ المخصص لها ، على سبيل المثال subdomain.domain. tld: 1234 حيث 1234 هو المنفذ المخصص لي.

هل هناك طريقة لجعله يعمل مع الإعداد الخاص بي؟

من gsdevme لدي انطباع بأنه يجب أن يكون المنفذ 80 متاحًا للجميع ...

_يجب أن يكون لديك منفذ 80 يمكن الوصول إليه علنًا لكي يتحقق خادم ACME منه.

_ هذا الحل هو فقط لتشغيل الخادم على منفذ بديل داخليًا ، والتوصيل من المنفذ 80 إلى المنفذ البديل.

_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._
_ إذا لم يكن لديك منفذ 80 يمكن الوصول إليه ، فيجب عليك استخدام التحقق من DNS._

شكرا على الرد jvanasco. سيء للغاية لا يمكنني تحديد المنافذ المخصصة. التحقق من DNS ليس خيارًا ، لأن موفر DNS الديناميكي http://freedns.afraid.org/ ليس لديه واجهة لتغيير سجلات TXT تلقائيًا.

jvanasco على الرغم من أنني أعلم أنك محق تمامًا في ردك ، فسيكون من الرائع أن نهدأ قليلاً قبل الإجابة: D

هل هناك تقدير للوقت عندما يكون هذا قابلاً للتكوين؟ لأنني متأكد من أن هناك الكثير من الأشخاص يقومون بتشغيل خوادم الويب على المنافذ المخصصة.

إنه غير قابل للتكوين حسب اختيار التصميم

مرسل من الايفون الخاص بي

في 14 فبراير 2017 ، الساعة 16:16 ، كتب nvaert1986 [email protected] :

هل هناك تقدير للوقت عندما يكون هذا قابلاً للتكوين؟ لأنني متأكد من أن هناك الكثير من الأشخاص يقومون بتشغيل خوادم الويب على المنافذ المخصصة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

نفس المشكلة هنا ، ولكن لغرض عامل ميناء.

مشكلة :
لا أرغب في حزم أمر certbot باستخدام أمر بدء خادم الويب الخاص بي لأنه سيفشل دائمًا في البيئات غير المنتجة.
لذلك أرغب في إنشاء صورة معينة تحتوي على برنامج certbot والذي:

• اطلب الشهادة
• ضع الشهادة داخل وحدة تخزين مشتركة مع خادم الويب الخاص بي

لكن هذا الحل لن يعمل إلا إذا أوقفت حاوية خادم الويب الخاصة بي ، والتي كانت مرتبطة بالفعل بالمنفذين 80 و 443.

المحلول :
لديها القدرة على تغيير منافذ certbot. سيسمح ذلك لكل من حاوية خادم الويب و certbot بالعمل بالتوازي.

قد يؤدي استخدام التحقق من DNS إلى حل حالة الاستخدام.

مرسل من الايفون الخاص بي

في 26 فبراير 2017 ، الساعة 23:32 ، كتب NilsRenaud [email protected] :

نفس المشكلة هنا ، ولكن لغرض عامل ميناء.

مشكلة :
لا أرغب في حزم أمر certbot باستخدام أمر بدء خادم الويب الخاص بي لأنه سيفشل دائمًا في البيئات غير المنتجة.
لذلك أرغب في إنشاء صورة معينة تحتوي على برنامج certbot والذي:

اطلب الشهادة
ضع الشهادة داخل وحدة تخزين مشتركة مع خادم الويب الخاص بي
لكن هذا الحل لن يعمل إلا إذا أوقفت حاوية خادم الويب الخاصة بي ، والتي كانت مرتبطة بالفعل بالمنفذين 80 و 443.

المحلول :
لديها القدرة على تغيير منافذ certbot. سيسمح ذلك لكل من حاوية خادم الويب و certbot بالعمل بالتوازي.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

قد يكون ذلك ولكن وضع التحقق هذا غير ممكن مع الوضع المستقل: /
(من: https://certbot.eff.org/docs/using.html#plugins)

يبدو أن الأرضية الوسطية المعقولة دون المساومة على الأمان هي السماح باكتشاف المنفذ عبر سجل DNS SRV. يمكن لـ Letsencrypt الاستعلام عن سجل مثل

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

على المجال وإعادة توجيه طلبات التحقق إلى مجموعة العنوان / المنفذ الناتجة. هذا له نفس فوائد التحقق من DNS ولكن دون عيب طلب التحديثات الديناميكية.

قد يعني هذا أيضًا أنه يمكن للمستخدمين بسهولة مركزية إدارة شهاداتهم إذا رغبوا في ذلك ، من خلال الرجوع إلى خادم شهادات مركزي.

كيف يسمح السماح لمنافذ بديلة بتعطيل الأمان؟

يمكن أن تساعدك هذه الأداة المساعدة FOSS في أتمتة عمليات التثبيت المباشرة وغير المباشرة لشهادات ACME للمضيفين المشغولين بمنفذ TCP / 443 ، أو لم يتم إعادة توجيه منفذ TCP / 443 إليهم:

https://www.actiu.net/sesele/

أين توجد الوثائق المتعلقة بكيفية عمل SeSeLe للسماح بالاستخدام
منافذ مختلفة عن 443 ؟.

في 26 تشرين الأول (أكتوبر) 2017 الساعة 1:21 ظهرًا ، كتب "نارسيس جارسيا" [email protected] :

يمكن أن تساعدك أداة البرمجيات الحرة والمفتوحة المصدر هذه على أتمتة عمليات التثبيت المباشرة وغير المباشرة لملفات
شهادات ACME للمضيفين المشغولين بمنفذ TCP / 443 أو ليس لديهم TCP / 443
المنفذ المرسل إليهم:

https://www.actiu.net/sesele/

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

من فضلك ، انتقل إلى مشكلة منتدى SeSeLe للسماح بتنسيق التوثيق بشكل أفضل. (الإجابة مكتوبة في وثائق SeSeLe الآن)

ربما يمكن إعادة النظر في هذه القضية؟ لا يوجد حتى الآن حل للقضية الأساسية. نعم ، يمكنك ربط المنفذ المستقل بمنفذ مختلف ولكن هذا غير مجدي لأن athority ستظل متصلة بـ 80/443.

إذا كان لديك خادم يعمل بالفعل على 80/443 ربما يكون قيد الإنتاج ، فأنت في بعض الأحيان لا تستطيع ببساطة تحرير هذه المنافذ. قد يكون وضع ملفات التحدي يدويًا مشكلة (الخوادم التي تعمل في Docker).

سيكون الحل الحقيقي هنا هو تحديد مجموعة من المنافذ أعلى (10000+) حيث ستحاول السلطة الاتصال كبديل احتياطي أو شيء من هذا القبيل. ربما هناك تداعيات أمنية ، وليس خبير.

ما هو الدافع وراء ربط LE بمنافذ 80/443 فقط؟ أهذا
قيود موثقة رسميا؟

هل يمكن لأي شخص أن يوجهني إلى المستندات الصحيحة؟

في 30 تشرين الثاني (نوفمبر) 2017 ، 6:31 صباحًا ، كتب "cen1" [email protected] :

ربما يمكن إعادة النظر في هذه القضية؟ لا يوجد حتى الآن حل ل
القضية الأساسية. نعم ، يمكنك ربط قائمة بذاتها بمنفذ مختلف ولكن ذلك
غير مجدية لأن اللاذقية ستظل متصلة بـ 80/443.

إذا كان لديك خادم يعمل بالفعل على 80/443 ربما في الإنتاج ، أنت
في بعض الأحيان لا تستطيع ببساطة تحرير تلك المنافذ. وضع يدويا
يمكن أن تكون ملفات التحدي مشكلة أيضًا (الخوادم التي تعمل في Docker).

سيكون الحل الحقيقي هنا هو تحديد مجموعة من المنافذ أعلى (10
000+) حيث ستحاول السلطة الاتصال كبديل أو شيء من هذا القبيل
مثل هذا. ربما هناك تداعيات أمنية ، وليس خبير.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

ما هو الدافع وراء ربط LE بمنافذ 80/443 فقط؟
هل هذا قيد موثق رسميًا؟

هل يمكن لأي شخص أن يوجهني إلى المستندات الصحيحة؟

إنه مطلب حالي لمنتدى CA / B موصوف هنا:
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

والشرح بمزيد من التفصيل هنا: https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

كما أفهم من لغتي الإنجليزية الضعيفة ، فقد ناقشوا في CA / Browser Forum في سبتمبر 2017 إمكانية إضافة منافذ TCP 25 ، 115 ، 22.
يبدو أنه تمت الموافقة على الاقتراح ويجب أن يكون ساري المفعول في تشرين الثاني (نوفمبر) المقبل.

ملاحظة من المستقبل إذا جاء شخص ما إلى هنا من Google (مثلي):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

إذا كنت تستخدم nginx ، فيمكنك استخدام وحدة nginx مع certbot certonly --nginx ، فهي تنقر على خادم nginx الحالي بدون أي تكوين.

العلم --http-01-port ليس أمرًا بديهيًا حقًا ، كما لم أتمكن من العثور عليه بمساعدة الأمر واضطررت إلى البحث في Google عن العلم --http-01-port . سيكون من الجيد أن يكون لديك العلم المذكور في المساعدة.