由于各种过程，现在几乎每个人都听说过进口替代之类的事情。 尤其是现在，导入的MS Exchange产品正被俄语本地化所取代，而没有任何问题* Communigate Pro。 如果我的同事有时间，我想他们可以提供很多有关群集，装载和迁移的信息，但是我想告诉您的是一阵令人毛骨悚然的事情，而关于这个新产品的证书更新的国家特征的报道要少得多。
实际上是一个简短的背景。 我在壁橱里有一台小型笔记本电脑，直到最近邮件服务器一直在Windows + hMailServer中嗡嗡作响。 自然，借助于导入替换，我想更紧密地了解Communigate Pro，它的要求非常适中，并且
在一定程度上是免费的：
我们免费为五个用户提供完整版的CommuniGate Pro，用于测试目的和在小型项目（公司）中使用。
可以
在“关于我们”部分开始认识。 在那里很明显地可以看到，在1997年达到了“首次发布”的里程碑，营销商Stalker，Inc学会了直到2004年才写上“发布”一词，但他们仍然无法为俄语站点制作俄语的营销材料。
安装产品（我在CentOS 7上安装了产品）并没有造成任何困难，借此机会，我把CertBot放在了那里，搞砸了Let's Encrypt的证书，总的来说，一切都开始了。
3个月后，证书按计划到期，是时候进行更改了。
然后，我发现Windows为Telnet客户端带来了非常意外的替代：
使用CertBot工具进行密钥更新很无聊，也许令dns1.yandex.ru服务器感到高兴，该服务器发出了一个小时的时间，发出了过时的或更新的tac记录_acme-challenge，因为我只能在第三次尝试时才生成证书。
然后魔术开始了。
Communigate服务器无法通过接口用新的密钥对替换密钥对，您必须首先删除旧的密钥对：
作为有意识的localhost主机管理员，我仅通过ssl打开了身份验证，然后安全地将其忘记了，因此在删除密钥对之后，服务器拒绝与我进行通信：
通过将以下行添加到/var/CommuniGate/Accounts/postmaster.macnt/account.settings文件中，我终止了偏执狂服务器：
RequireAPOP = NO;但是，沉积物当然仍然存在。 自然，我想
为自己创建一个
按钮，以脚本的一次运行替换密钥对，而不是根据用户设置绕圈走。
Communigate中的自动化工具有多达
四个接口 ：通过TCP连接（PWD）进行文本通信，CLI.pm Pearl模块（CG / PL），简单的Web请求和XIMSS。
由于各种原因（当然，大多数情况是懒惰），我选择了Web请求。
从一开始就出了点问题：
[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 ~]#
嗯...嗯...没想到
我以为是certbot，而不是私钥，我偷了一些奇怪的东西，取出了文件的内容：
[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的聊天室道别。
但是，事情并非如此简单。 手动清除了私钥后，我发现它仍然没有被导入。
在这里，我陷入了最后的僵局。
经历了这种现象之后，我决定手动吐痰并做所有事情，通过Web界面导入私钥……最后我提出了一个getdomainsettings请求。 突然，事实证明Communigate并没有将我给他喂的东西还给我。 此外，清理后的“让我们加密”专用密钥长1624个字符，而Communigate向我显示的长度只有1592个字符。
我还没准备好转弯，就爬进了openssl。 第一枪击中目标：
[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不是我的本机环境，因此我将不胜感激这些优化。
好吧，你永远不会知道，突然有人会需要我，我无法用谷歌搜索。
*在Communigate Pro中确实找不到钉子