CommuniGate Proの秘密鍵とWeb API

さまざまなプロセスにより、ほとんどすべての人がすでに輸入代替のようなことを聞​​いています。 特に、現在、輸入されたMS Exchange製品は、単一の釘* Communigate Proなしで、元のロシア語に積極的に置き換えられています。 同僚が時間を見つけたら、クラスター、作業負荷、および移行について多くを語ることができると思いますが、1つの恐ろしい血を伝えたいと思いますが、この素晴らしい製品の証明書を更新することの全国的な特徴については、それほど広範囲ではありません。



実際、簡単な背景。 クローゼットの中に小さなラップトップがあり、最近までメールサーバーが多数のWindows + hMailServerで賑やかでした。 当然、インポートの置換により、Communigate Proをより詳しく知りたいと思いました。幸いなことに、要件は非常に控えめで、いくつかのスケールでは無料です。

CommuniGate Proのフルバージョンは、テスト目的および小規模プロジェクト（企業）で使用するために、5人のユーザーに無料で提供されます。

知り合いはAbout Usセクションで始めることができます。 1997年に「最初の信頼」というマイルストーンに到達し、マーケティング担当者のストーカー社は2004年までに「リリース」という言葉を書くことを学びましたが、ロシアのサイトのロシア語マーケティング資料を作成することはできませんでした。







製品のインストール（私はCentOS 7にインストールしました）は問題を引き起こしませんでした。この機会を利用して、CertBotをそこに置き、Let's Encryptから証明書をねじ込み、一般にすべてが起動しました。

3か月後、証明書は計画どおりに期限切れになり、証明書を変更する時間になりました。



次に、WindowsがTelnetクライアントの非常に予期しない置換をもたらしたことを発見しました。







CertBotツールを使用したキーの再生成は退屈でしたが、おそらくdns1.yandex.ruサーバーに満足しました。サーバーは1時間で古いまたは更新されたtac-record _acme-challengeを提供しました。 。

そして、魔法が始まりました。



Communigateサーバーには、インターフェイスを介してキーペアを新しいキーペアに置き換える機能がないため、最初に古いキーペアを削除する必要があります。







意識的なローカルホストホスト管理者として、私はSSL経由でのみ認証をオンにし、それを安全に忘れたため、キーペアを削除した後、サーバーは私との通信を拒否しました：







この行を/var/CommuniGate/Accounts/postmaster.macnt/account.settingsファイルに追加することで、偏執的なサーバーを停止しました。

RequireAPOP = NO;





しかし、もちろん、堆積物は残りました。 当然、スクリプトのボタンを作成して、キーペアをこのスクリプト自体の1回の実行に置き換え、ユーザー設定に応じて円を描くようにしたくありませんでした。



Communigateの自動化ツールは、TCP接続（PWD）を介したテキスト通信、CLI.pmパールモジュール（CG / PL）、シンプルなWebリクエスト、XIMSSという4つのインターフェースに存在します 。



さまざまな理由（主に怠iness、もちろん）で、Web要求を選択しました。



最初から、何かがおかしくなりました。

 [root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/getdomainsettings' [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 ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings%20test' {} [root@mx ~]#
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前に完全に一致するテストドメインはテストドメインであるため、設定はありません。

次に、URLに証明書を埋め込む方法を紹介し、それについて何かする必要があると判断しました。 たとえば、データ転送のために喫煙者のGETリクエストの代わりに健康な人のPOSTリクエストを使用します。

 [root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、これまでのところ、すべては計画通りに進んでいます。



Let's Encryptは、そこから宝物を/etc/letsencrypt/live/domain.my/ディレクトリに保存し、それらを取得します。



getdomainsettingsリクエストの少し上で、プライベートキーがPrivateSecureKeyフィールドにあり、さらに、ヘッダーとフッターが噛まれており、他のすべてが1行にマージされていることがわかりました。 インポートしてみましょう。

 [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 ~]#
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Webインターフェースを介して挿入します。







突然、すべてがうまくいきました：







キーを削除し、HTTPリクエストで再度インポートしようとしました。 奇跡は起こらず、 秘密鍵データはまだ破損していることが判明しました。



困惑した、私は再びテクニカルサポートウサギを訪問しに行きました。 技術サポートは、秘密鍵ファイルからヘッダーとフッターをかみ、結果を1行にまとめる必要があると述べました。 このコマンドですべてを正しく行ったかどうかを尋ねたとき：

 grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サポート担当者は、grepの専門家ではなく、知らなかったと答えました。



対話中に、getdomainsettingsリクエストで古いキーを取り出すと、HTTPリクエストがそれを正常にインポートするので、grep | trは余分なものを噛み付き、Stalkerのチャットルームに別れを告げました。



しかし、それはそれほど単純ではありませんでした。 秘密キーを手動で消去したところ、とにかくインポートされていないことがわかりました。



ここで私は最後の行き詰まりにさまよいました。



この現象に苦しんでいたので、私はすべてを手動で吐き出し、Webインターフェースを介して秘密鍵をインポートすることにしました...そして最後にgetdomainsettingsリクエストを行いました。 Communigateが私が彼に与えたものを私に返していないことが突然判明しました。 さらに、クリーニング後のLet's Encrypt秘密キーの長さは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 ~]#
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

やったー、ミッションは達成された。



証明書付きのダンスは必要ありませんでした。フッターでヘッダーを噛むだけで、残りは1行にまとめられます。



合計、最終的な結果は私にとって次のようになります：

 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の爪は実際には見つかりませんでした