Karena berbagai proses, sekarang hampir semua orang telah mendengar hal seperti substitusi impor. Khususnya, sekarang produk MS Exchange yang diimpor sedang digantikan secara aktif oleh Rusia asli tanpa satu paku * Communigate Pro. Jika kolega saya menemukan waktu, saya pikir mereka dapat memberi tahu banyak tentang kelompok, beban kerja, dan migrasi, tetapi saya ingin memberi tahu Anda satu hal yang mengerikan, tetapi kisah yang jauh lebih tidak luas tentang fitur nasional untuk memperbarui sertifikat dalam produk yang luar biasa ini.
Sebenarnya, latar belakang yang singkat. Saya punya laptop kecil di lemari yang sampai saat ini server mail berdengung di sekelompok Windows + hMailServer. Secara alami, berdasarkan substitusi impor, saya ingin mengenal Communigate Pro lebih dekat, untungnya, persyaratannya sangat sederhana dan gratis
pada beberapa skala :
Kami menyediakan versi lengkap dari CommuniGate Pro secara gratis untuk lima pengguna untuk tujuan pengujian dan untuk digunakan dalam proyek kecil (perusahaan).
Kenalan dapat dimulai
di bagian Tentang Kami . Sangat jelas terlihat di sana bahwa pada tahun 1997 tonggak "ketergantungan pertama" tercapai, para pemasar Stalker, Inc belajar untuk menulis kata "Rilis" hanya pada tahun 2004, dan mereka masih belum dapat membuat materi pemasaran berbahasa Rusia untuk situs Rusia.
Menginstal produk (saya menginstalnya pada CentOS 7) tidak menyebabkan kesulitan, mengambil kesempatan ini, saya meletakkan CertBot di sana, mengacaukan sertifikat dari Let's Encrypt dan, secara umum, semuanya dimulai.
Setelah 3 bulan, sertifikat berakhir seperti yang direncanakan dan sudah waktunya untuk mengubahnya.
Kemudian saya menemukan bahwa Windows membawa pengganti yang sangat tidak terduga untuk klien Telnet:
Regenerasi kunci menggunakan alat CertBot membosankan, saya senang, mungkin, dengan server dns1.yandex.ru, yang selama satu jam memberikan tantangan tac-record _acme-outdated yang lama atau yang diperbarui, karena itu saya dapat menghasilkan sertifikat hanya pada upaya ketiga .
Dan kemudian keajaiban dimulai.
Server Communigate tidak memiliki kemampuan untuk mengganti pasangan kunci dengan pasangan kunci baru melalui antarmuka, Anda harus terlebih dahulu menghapus pasangan kunci lama:
Sebagai admin host localhost yang sadar, saya mengaktifkan otentikasi hanya melalui ssl dan dengan aman melupakannya, jadi setelah menghapus pasangan kunci, server menolak untuk berkomunikasi dengan saya:
Saya memadamkan server paranoid dengan menambahkan baris ini ke file /var/CommuniGate/Accounts/postmaster.macnt/account.settings:
RequireAPOP = NO;tapi, endapan, tentu saja, tetap ada. Secara alami, saya ingin membuat
tombol untuk saya sendiri skrip untuk mengganti pasangan kunci dengan satu skrip ini berjalan sendiri, dan tidak berjalan berputar-putar sesuai dengan pengaturan pengguna.
Alat otomatisasi di Communigate hadir dalam sebanyak
empat antarmuka : komunikasi teks melalui koneksi TCP (PWD), modul mutiara CLI.pm (CG / PL), permintaan web sederhana dan XIMSS.
Untuk berbagai alasan (kebanyakan kemalasan, tentu saja), saya memilih permintaan web.
Sejak awal, ada yang salah:
[root@mx ~]
Ternyata, saya membaca dokumentasi dengan hati-hati, saya harus melakukannya seperti ini:
[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=();}
Kemudian ada yang tidak beres lagi:
[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=();}
Saya bingung dengan pergantian peristiwa ini dan berbalik
mendukung vendor .
Sebagai iklan.
Ya, mereka memiliki ruang obrolan. Dan para ahli bahkan menjawab di dalamnya. Bahkan tanpa berlangganan perusahaan.
Ternyata, permintaan http tidak mengerti parameter yang disebutkan. Hanya posisi, hanya hardcore:
[root@mx ~]
Domain uji, sesuai sepenuhnya dengan namanya, adalah domain uji, jadi tidak ada pengaturan di dalamnya.
Lalu saya memperkenalkan bagaimana saya akan menanamkan sertifikat di URL, dan memutuskan bahwa saya perlu melakukan sesuatu tentang itu. Misalnya, gunakan permintaan POST dari orang sehat alih-alih permintaan GET perokok untuk transfer data:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
Nah, sejauh ini semuanya berjalan sesuai rencana.
Let's Encrypt menyimpan hartanya di direktori /etc/letsencrypt/live/domain.my/ dari sana dan kita akan mendapatkannya.
Sedikit lebih tinggi dalam permintaan getdomainsettings, saya melihat bahwa kunci pribadi terletak di bidang PrivateSecureKey, dan terlebih lagi, itu terletak di sana dengan header dan footer yang digigit, dan yang lainnya digabung menjadi satu baris. Mari kita coba impor.
[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 ~]#
Uh ... Baiklah ... Saya tidak mengharapkan ini.
Saya pikir itu adalah certbot, alih-alih kunci pribadi, saya menyelipkan sesuatu yang aneh, mengeluarkan isi file:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
dan dimasukkan melalui antarmuka web:
Tiba-tiba, semuanya berjalan dengan baik:
Saya menghapus kunci dan mencoba mengimpornya lagi dengan permintaan HTTP. Tidak ada keajaiban yang terjadi,
data kunci pribadi ternyata masih
rusak .
Bingung, saya kembali mengunjungi
kelinci dukungan teknis. Dukungan teknis mengatakan bahwa Anda perlu menggigit header dan footer dari file kunci pribadi, dan menggabungkan hasilnya dalam satu baris. Ketika saya bertanya apakah saya melakukan semuanya dengan benar dengan perintah ini:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
Petugas pendukung menjawab bahwa dia bukan ahli grep dan tidak tahu.
Dalam proses dialog, saya menemukan bahwa jika saya mengeluarkan kunci lama dengan permintaan getdomainsettings, permintaan HTTP mengimpornya secara normal, saya memutuskan bahwa grep | tr menggigit sesuatu yang berlebihan, dan mengucapkan selamat tinggal pada ruang obrolan Stalker.
Namun, itu tidak sesederhana itu. Setelah membersihkan kunci pribadi secara manual, saya menemukan bahwa itu tidak diimpor.
Di sini saya berjalan ke jalan buntu terakhir.
Setelah menderita dengan fenomena ini, saya memutuskan untuk meludah dan melakukan semuanya secara manual, mengimpor kunci pribadi melalui antarmuka web ... Dan akhirnya saya membuat permintaan getdomainsettings. Tiba-tiba, ternyata Communigate tidak mengembalikan kepada saya apa yang telah saya berikan kepadanya. Selain itu, kunci pribadi Let's Encrypt setelah pembersihan panjangnya 1624 karakter, dan yang ditunjukkan Communigate kepada saya hanya 1.592.
Saya tidak siap untuk belokan seperti itu dan naik ke openssl. Tembakan pertama mengenai target:
[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 ~]#
Hore, misi tercapai.
Kami tidak membutuhkan tarian dengan sertifikat, mereka hanya menggigit header dengan footer dan sisanya digabungkan dalam satu baris.
Total, hasil akhirnya terlihat seperti ini untuk saya:
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'`];}"
Karena unix-shell bukan lingkungan asli saya, saya akan sangat menghargai optimasinya.
Ya, dan Anda tidak pernah tahu, tiba-tiba seseorang membutuhkan saya, saya tidak bisa menggunakan google ini.
* Kuku di Communigate Pro benar-benar tidak ditemukan