مرحبًا مرة أخرى ، عزيزي القارئ. تم الإعلان عن فتح الفصل الثاني من مغامرات Let's Encrypt في لوحة
ISPmanager . في
مقالة سابقة ، ناقشنا البرنامج المساعد لـ ACME v01. في هذا ، سنتحدث عن تطورها من وجهة نظر منطق العمل مع المستخدم ، وبالطبع حول بروتوكول ACME v02 مع دعم شهادات أحرف البدل.
العناية المفرطة
في محاولة لإحاطة المستخدم بحذر ، يمكنك الذهاب بعيدًا. حتى الآن لن يتمكن من العمل مع الوظائف على الإطلاق. والجزء الأول من قصتنا هو حول ذلك.
أثناء تطوير الوحدة ، أردنا إنقاذ العميل من التحضير الطويل لمسألة الشهادة. تم تقديم تقييدين لهذا: سمحوا بطلب SSL فقط لنطاقات الويب المسجلة في اللوحة وفقط لأسماء النطاقات المستعارة التي تعرفها اللجنة.
بدا كل من القيود منطقية. لم يسمح الأول بطلب شهادات للنطاقات غير الموجودة وإنتاج كيانات "ميتة" - شهادات لن يتم إصدارها ، لأنه لا يوجد مكان لوضع الرموز المميزة للتحقق. كما ألغى الثاني الكيانات غير الضرورية ، ولم يسمح حتى الآن بطلب شهادات لـ "*." - الأسماء المستعارة - في ذلك الوقت لم يدعم
LE ببساطة مثل هذه الشهادات.
كان كل شيء على ما يرام حتى يوم واحد ظهرت ميزة للتحقق من المجال من خلال سجلات DNS والقدرة على طلب شهادة لمجال بريد في
LE . بعد ذلك ، عند طلب نطاق بريد ، قررنا إضافة ما يلي إلى الأسماء المستعارة: "mail" ، "pop" ، "smtp" - بعد كل شيء ، غالبًا ما تكون الشهادات مرتبطة بها. في النهاية ، اتضح أنه سيئ: كان هناك مستخدمون قاموا في البداية بتهيئة خوادم بريدهم على أسماء مستعارة مختلفة تمامًا. نظرًا لقيودنا في الطلب ، لم يتمكنوا من إضافة الأسماء المطلوبة.
لحسن الحظ ، أدركنا الخطأ وصححناه بسرعة ، مما سمح للمستخدمين بتحديد البيانات اللازمة عند طلب شهادة. لا يزال ، في بعض الأحيان هناك مخاوف كثيرة :).
البدل
الآن لنتحدث عن التبديل إلى
ACME v02 ، لأنه فقط في هذا الإصدار من بروتوكول
LE ظهر دعم شهادات أحرف البدل. لنبدأ بدليل جديد أو بالأحرى دليل معدل:
curl -o- 'https://acme-v02.api.letsencrypt.org/directory' { "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "mIU2Y2m2FsA": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert" }
الاختلاف الأول والأكثر وضوحًا هو أن المفاتيح مختلفة :). في رأيي ، أصبحت أكثر بديهية. الاختلاف الثاني هو عنوان URL منفصل للحصول على Replay-Nonce. يتم ذلك الآن على هذا النحو:
curl -LD - 'https://acme-v02.api.letsencrypt.org/acme/new-nonce' HTTP/1.1 204 No Content Server: nginx Replay-Nonce: QQgdAERh1MLQ6LHC0SVmB9OJXBcEWnwGB53CP0V4JlQ X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 Expires: Sat, 02 Jun 2018 09:49:47 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Sat, 02 Jun 2018 09:49:47 GMT Connection: keep-alive
نونس ، بالطبع ، سيكون مفيدًا لنا أكثر من مرة.
الآن دعونا نتحدث عن التغييرات غير الواضحة التي ينطوي عليها الانتقال إلى ACME v02.
في هذه الحالة فقط ، دعني أذكرك كيف كان طلب POST القديم يبحث عن التواصل مع الإصدار الأول من
ACME :
{ "header": jws,
الآن ستكون بنية البيانات العامة مختلفة:
{ "protected": Base64Url(protected), "payload": Base64Url(payload),
كما ترى ، تم إلغاء حقل الرأس. لم تتغير المرحلة التحضيرية ، لفرح "عشاق التشفير" مثلي على الإطلاق: سنحتاج إلى نفس مفاتيح rsa و
JWK و
JWS (المزيد عن هذا
في الجزء الأول ).
التسجيل
لتسجيل مستخدم ، ما عليك سوى قبول اتفاقية المستخدم وإرسال طلب "newAccount" من الدليل.
payload = {"termsOfServiceAgreed": true}
وتجميع المحمية الصحيحة:
{ "alg" : "RS256", "jwk" : jwk, \\ JSON Web Key “url” : url, \\ “nonce” : Replay-Nonce \\ }
نحن نشكل نص الطلب ونرسله و ... خذ وقتنا! معالجة رؤوس الاستجابة من
ACME بعناية
وحذر . نجد رأسًا يسمى
الموقع وحفظ محتوياته. هذا هو ما يسمى
KID - مفتاح تعريف المستخدم المسجل حديثًا. ستحتاج جميع الطلبات اللاحقة إلى احتواء هذه القيمة في الحماية بدلاً من
JWK .
كن حذرًا : إذا تابعت إرسال الطلبات وفقًا للمخطط القديم ، فلن تكون الإجابة سوى رسائل الخطأ.
هنا لدينا حماية اللاحقة:
{ "alg" : "RS256", "kid" : kid, \\ “url” : url, \\ “nonce” : Replay-Nonce \\ }
طلب الشهادة
نحن جاهزون لإرسال طلب إلى الدليل ["newOrder"]. نضيف إلى الحمولة جميع الأسماء المستعارة لنطاق الويب الخاص بنا والتي سنقوم بإصدار شهادة لها:
payload ={ "identifiers":[ { "type":"dns", "value":"name1" }, ... { "type":"dns", "value":"nameN" } ] }
ضع في اعتبارك أنه إذا كنت تريد إصدار شهادة حرف بدل ، فيجب أن تحتوي الأسماء فقط على الاسم الرئيسي و "*" - اسم مستعار. سيؤدي وجود أي أسماء أخرى إلى حدوث خطأ في الإصدار.
في الرد ، نحصل على JSON يحتوي على طرق لتأكيد ملكية المجال وعنوان URL الذي سيتم استخدامه لإكمال إصدار الشهادة.
{ "status":"pending", "expires":"2018-06-08T08:05:49.437251947Z", "identifiers":[ { "type":"dns", "value":"name1" }, { "type":"dns", "value":"www.name1" } ], "authorizations":[
علاوة على ذلك نتلقى تعليمات مفصلة عن الشيكات:
curl -o- 'https://acme-v02.api.letsencrypt.org/acme/authz/Xp0a_...' { "identifier":{ "type":"dns", "value":"name1" }, "status":"pending", "expires":"2018-06-08T08:05:49Z", "challenges":[ { "type":"http-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756205", "token":"Me_cKM2Stu3iyCJQWEssho8Kj2nvRKuSJvIPF5tRyko" }, { "type":"dns-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756206", "token":"p-0xyySPQClTXVlgTxwJUvVOQtdHmNPpFht95bWrq8s" } ] }
لا تختلف عملية التأكيد عما تم تنفيذه لـ
ACME v01 .
يرجى ملاحظة ما يلي: للحصول على شهادة حرف بدل ، يجب تحديد تأكيد "dns-01".
الحصول على شهادة
بعد إجراء التأكيد ، يبقى استدعاء عنوان URL
النهائي . من الممكن حدوث تأخيرات طفيفة ، لذا يجب إجراء طلب GET لهذا العنوان حتى نحصل على ما يلي في الرد:
{ "status": "valid",
ستحتوي الشهادة بالفعل على سلسلة ، لذا فهي جاهزة تمامًا للعمل.
مقارنةً بالإصدار الأول ، أصبح الإصدار الثاني من
ACME أكثر سهولة وفهمًا. أصبح دمج الكتابة أسهل ، نظرًا لأن "التشفير" نفسه لم يتغير. سأراقب باهتمام تطوير هذه الأداة المدهشة وسأعود بالتأكيد هنا بمعلومات جديدة في حالة حدوث أي تغييرات مهمة ومفيدة.