CommuniGate Pro, Private Keys and Web API

Due to various processes, now almost everyone has heard about the phenomenon of import substitution. In particular, the imported MS Exchange product is now being actively replaced by native Russian without a single nail * Communigate Pro. If my colleagues take the time, I think they will be able to tell a lot about clusters, loading and migration, I want to tell one blood-curdling, but much smaller story about national peculiarities of updating certificates in this wonderful product.

Actually, a brief background. I have a small laptop in the closet, on which, until recently, the mail server in the bundle of Windows + hMailServer was buzzing. Naturally, due to import substitution, I wanted to get a closer look at Communigate Pro, since it is very modest in requirements and free on some scales :

We provide the full version of CommuniGate Pro for free for five users for testing purposes and for use in small projects (companies).

Acquaintance can be started in the section "About Us" . It is very clearly seen that, in 1997, the milestone “First reliase” was reached, the word “Release” marketers of Stalker, Inc learned to write only by 2004, and Russian-language marketing materials could not be done for the Russian-language website until now.



Installing the product (I put it on CentOS 7) did not cause any difficulties, I used the occasion to put CertBot there, screw the certificates from Let's Encrypt and, in general, it all started.
After 3 months, the certificates have expired and it’s time to change them.
')
Then I discovered that Windows brought a rather unexpected replacement to the Telnet client:



The key regeneration by means of CertBot turned out to be boring, pleased, perhaps, the server dns1.yandex.ru, which for an hour issued the outdated or updated txt-record _acme-challenge, because of what I was able to generate certificates only on the third attempt .
And then the magic began.

The Communigate server does not have the ability to replace the key pair with a new one through the interface; you must first delete the old key pair:



I, as a conscious admin of localhost, turned on authentication only via ssl and safely forgot about it, so after removing the key pair, the server refused to talk to me:



I pugasil the paranoia to the server by adding the following line to the /var/CommuniGate/Accounts/postmaster.macnt/account.settings file:
RequireAPOP = NO;
but, sediment, of course, remained. Naturally, I wanted to make myself a button for replacing a key pair with a single launch of this script itself, rather than walking in circles according to user settings.

Communigate automation tools are present in a number of four interfaces : text communication via TCP connection (PWD), pearl-barley CLI.pm module (CG / PL), simple web requests and XIMSS.

For various reasons (mostly lazy, of course), I chose web requests.

From the very beginning, something went wrong:

 [root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/getdomainsettings' [root@mx ~]# 

As it turned out, I inattentively read the documentation, I had to do this:

 [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=();} 

Then something went wrong again:

 [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=();} 

I was puzzled by this turn of events and turned in support of the vendor .

As advertising.

Yes, they have a chat. And it even meets the experts. Even without any corporate subscription.

As it turned out, the http request does not understand the named parameters. Only positional, only hardcore:

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

Domain test, in full accordance with its name, test, so that there are no settings in it.
Here I presented how I would insert the certificate into the URL, and decided that I had to do something about it. For example, use the POST request of a healthy person instead of a GET request for a smoker to transfer data:

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

Well, as long as everything goes according to plan.

Let's Encrypt keep our treasures in the /etc/letsencrypt/live/domain.my/ directory from there and we'll get them.

Slightly higher in the getdomainsettings request, I saw that the private key lies in the PrivateSecureKey field, in which case it lies there with the bitten header and footer, and all the rest is merged into one line. Let's try to import it.

 [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-uh ... Well ... I didn't expect that.

I thought it was a certbot, instead of a private key, I slipped something strange, pulled the contents of the file:

 [root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY-----     -----END PRIVATE KEY----- [root@mx ~]# 

and pasted through the web-interface:



Suddenly, everything went fine:



I deleted the key and again tried to import it with an HTTP request. A miracle did not happen, the private key data was still is corrupted .

Puzzled, I again went to visit the rabbit technical support. Technical support said that it is necessary to bite the header with the footer from the file of the private key, and combine the result into one line. When I asked if I did everything right with this command:

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

the support officer replied that he was not an expert in grep and did not know.

During the dialogue, I found that if I retrieved the old key with the getdomainsettings request, then the HTTP request imports it normally, decided that my grep | tr bites into something extra, and says goodbye to Chatik Stalker.

However, it was not so easy. Having manually cleaned the private key, I found that it wasn’t imported anyway.

Here I wandered into the final deadlock.

Having suffered from this phenomenon, I decided to spit and do everything manually, imported the private key through the web interface ... And finally I made a getdomainsettings request. Suddenly, it turned out that Communigate returns to me something completely different from what I fed him. Moreover, the private key of Let's Encrypt after cleaning was 1624 characters in length, and what Communigate showed me was only 1592 in length.

By this turn, I was not ready and I climbed into openssl. The first shot hit the 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 ~]# 

Hooray, mission accomplished.

With certificates, no dancing was needed; there, the heder with the footer just bites out and the remnants are combined into one line.

Total, the final result in my looks like this:

 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'`];}" 

Since unix-shell is not my native environment, I will accept optimization with gratitude.

Well, and it is not enough, suddenly someone will need it, I could not google it.

* No nails were actually found in Communigate Pro