بسبب العمليات المختلفة ، سمع الجميع تقريبًا الآن عن شيء مثل استبدال الواردات. على وجه الخصوص ، يتم الآن استبدال منتج MS Exchange المستورد بنشاط بروسي أصلي بدون مسمار واحد * Communiate Pro. إذا وجد زملائي الوقت ، أعتقد أنهم يستطيعون أن يخبروا الكثير عن التجمعات ، وأعباء العمل والهجرة ، لكنني أريد أن أخبركم بدم بارد ، ولكن قصة أقل شمولًا بكثير حول السمات الوطنية لتجديد الشهادات في هذا المنتج الرائع.
في الواقع ، خلفية موجزة. لدي جهاز كمبيوتر محمول صغير في خزانة كان حتى وقت قريب خادم البريد يرن في مجموعة من Windows + hMailServer. بطبيعة الحال ، بفضل استبدال الاستيراد ، أردت التعرف على Communiate Pro بشكل أقرب ، لحسن الحظ ، إنه متواضع جدًا في المتطلبات وهو مجاني
في بعض المقاييس :
نقدم الإصدار الكامل من CommuniGate Pro مجانًا لخمسة مستخدمين لأغراض الاختبار وللاستخدام في المشروعات الصغيرة (الشركات).
يمكن بدء التعارف
في قسم نبذة عنا . من الواضح جدًا أنه في عام 1997 تم الوصول إلى المرحلة الأولى من "الإعتماد الأول" ، حيث تعلم المسوقون Stalker، Inc كتابة كلمة "الإصدار" فقط بحلول عام 2004 ، وما زالوا غير قادرين على صنع مواد تسويق باللغة الروسية للموقع الروسي.
لم يتسبب تثبيت المنتج (قمت بتثبيته على CentOS 7) في حدوث أي صعوبات ، واغتنام هذه الفرصة ، ووضعت CertBot هناك ، وثبتت الشهادات من Let's Encrypt ، وبشكل عام ، بدأ كل شيء.
بعد 3 أشهر ، انتهت صلاحية الشهادات كما هو مخطط لها ، وحان الوقت لتغييرها.
ثم اكتشفت أن Windows جلب بديلًا غير متوقع جدًا لعميل Telnet:
كان التجديد الرئيسي باستخدام أدوات CertBot مملاً ، وقد سررت ، ربما ، بخادم dns1.yandex.ru ، الذي أعطى لمدة ساعة إما التحدي القديم أو المحدث _acme-Challenge ، الذي تمكنت من إنشاء شهادات فقط في المحاولة الثالثة .
ثم بدأ السحر.
ليس لدى خادم Communiate القدرة على استبدال زوج المفاتيح بأخرى جديدة من خلال الواجهة ، يجب عليك أولاً حذف زوج المفاتيح القديم:
بصفتي مشرف مضيف localhost واعي ، قمت بتشغيل المصادقة فقط عبر SSL ونسيتها بأمان ، لذلك بعد حذف زوج المفاتيح ، رفض الخادم الاتصال معي:
أطفأت الخادم بجنون العظمة بإضافة هذا السطر إلى ملف /var/CommuniGate/Accounts/postmaster.macnt/account.settings:
RequireAPOP = NO;ولكن ، بالطبع ، بقيت الرواسب. بطبيعة الحال ، أردت أن أجعل
زرًا بنفسي هو النص البرمجي لاستبدال زوج المفاتيح مع تشغيل واحد من هذا البرنامج النصي نفسه ، وعدم المشي في الدوائر وفقًا لإعدادات المستخدم.
أدوات الأتمتة في Communiate موجودة في
أربع واجهات : اتصال نصي عبر اتصال TCP (PWD) ، وحدة لؤلؤة CLI.pm (CG / PL) ، طلبات ويب بسيطة و XIMSS.
لأسباب مختلفة (الكسل في الغالب ، بالطبع) ، اخترت طلبات الويب.
منذ البداية ، حدث خطأ ما:
[root@mx ~]
كما اتضح ، قرأت الوثائق بشكل غير دقيق ، كان علي القيام بذلك على النحو التالي:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
ثم حدث خطأ ما مرة أخرى:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings&domainName=test' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
لقد كنت في حيرة من هذا التحول في الأحداث ،
وبدعم من البائع .
كإعلان.
نعم ، لديهم غرفة دردشة. والخبراء يجيبون على ذلك. حتى بدون اشتراك الشركات.
كما اتضح ، فإن طلب http لا يفهم المعلمات المسماة. الموضعي فقط ، المتشددين فقط:
[root@mx ~]
نطاق الاختبار ، بما يتفق تمامًا مع اسمه ، هو نطاق اختبار ، لذلك لا توجد إعدادات فيه.
ثم قدمت كيف سأقوم بتضمين شهادة في عنوان URL ، وقررت أنني بحاجة إلى القيام بشيء حيال ذلك. على سبيل المثال ، استخدم طلب POST لشخص سليم بدلاً من طلب GET للمدخن لنقل البيانات:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
حسنًا ، كل شيء يسير حسب الخطة حتى الآن.
دعونا تشفير يحتفظ بكنوزها في الدليل /etc/letsencrypt/live/domain.my/ من هناك وسنحصل عليها.
أعلى قليلاً في طلب getdomainsettings ، رأيت أن المفتاح الخاص يكمن في حقل PrivateSecureKey ، وما هو أكثر من ذلك ، أنه يوجد هناك مع رأس وتذييل للعض ، ويتم دمج كل شيء آخر في سطر واحد. دعونا نحاول استيراده.
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings test {PrivateSecureKey=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'`];}" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title> domain.my</title> <link rel="stylesheet" href="/SkinFiles/domain.my/Pronto/style.css" type="text/css" /> <meta http-equiv="x-dns-prefetch-control" content="off" /> <meta name="referrer" content="no-referrer" /> </head> <body background="/SkinFiles/domain.my/Pronto/bodybgcolor.gif"> <form method="post" enctype="multipart/form-data"> <input type="hidden" name="FormCharset" value="utf-8" /> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr><td height="25"> </td></tr> <tr valign="middle"><td align="center" bgcolor="#ffcccc" class="externalError">private key data is corrupted</td></tr> </table> </form> </body> </html> [root@mx ~]#
آه ... حسنًا ... لم أتوقع هذا.
اعتقدت أنه كان سيرتبوت ، بدلاً من مفتاح خاص ، قمت بشيء غريب ، سحبت محتويات الملف:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
وإدراجه عبر واجهة الويب:
فجأة سارت الأمور على ما يرام:
قمت بحذف المفتاح وحاولت استيراده مرة أخرى باستخدام طلب HTTP. لم تحدث معجزة ، وتبين أن
بيانات المفتاح الخاص لا تزال
تالفة .
في حيرة ، ذهبت مرة أخرى لزيارة
أرنب الدعم الفني. قال الدعم الفني أنك بحاجة إلى عض رأس وتذييل الصفحة من ملف المفتاح الخاص ، ودمج النتيجة في سطر واحد. عندما سألت إذا فعلت كل شيء بشكل صحيح مع هذا الأمر:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
رد ضابط الدعم بأنه ليس متخصصًا في grep ولا يعرف.
في عملية الحوار ، وجدت أنه إذا قمت بسحب المفتاح القديم مع طلب getdomainsettings ، فإن طلب HTTP يستورده بشكل طبيعي ، فقد قررت أن grep الخاص بي | يعض tr شيئًا غير ضروري ، ويقول وداعًا لغرفة الدردشة في Stalker.
ومع ذلك ، لم يكن الأمر بهذه البساطة. بعد تنظيف المفتاح الخاص يدويًا ، اكتشفت أنه لم يتم استيراده على أي حال.
هنا تجولت في طريق مسدود نهائي.
بعد أن عانيت من هذه الظاهرة ، قررت أن أبصق وأقوم بكل شيء يدويًا ، واستوردت المفتاح الخاص من خلال واجهة الويب ... وأخيرًا قمت بطلب getdomainsettings. وفجأة اتضح أن كونيغيت لم يعد لي ما أطعمته. علاوة على ذلك ، كان مفتاح Let's Encrypt الخاص بعد التنظيف بطول 1624 حرفًا ، وما أظهره Communiate كان طوله 1592 فقط.
لم أكن مستعدًا لمثل هذا الدور وتسلقت إلى opensl. أصابت الطلقة الأولى الهدف:
[root@mx ~]# openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem writing RSA key -----BEGIN RSA PRIVATE KEY----- , , -----END RSA PRIVATE KEY----- [root@mx ~]#
مرحبا ، لقد أنجزت المهمة.
لم نكن نحتاج إلى رقصات بشهادات ، بل يعضون رأسًا مع تذييل ويتم دمج بقايا الطعام في سطر واحد.
الإجمالي ، النتيجة النهائية تبدو لي هكذا:
curl --user postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings domain.my {SecureCertificate=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/cert.pem | tr -d '\n'`];PrivateSecureKey=[`openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem 2> /dev/null | grep -v '\-\-' | tr -d '\n'`];CAChain=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/chain.pem | tr -d '\n'`];}"
نظرًا لأن unix-shell ليست بيئتي الأصلية ، سأقدر بشكل كبير التحسينات.
حسنًا ، ولا تعرف أبدًا ، فجأة سيحتاجني شخص ما ، لم أستطع البحث في هذا.
* لم يتم العثور بالفعل على مسامير في Communiate Pro