New Options of Ruspo Relay 1


Ruspo Relay 1 Options tab
Ruspo Relay 1 Options tab

Ruspo Relay 1 ( ) is a desktop / workstation application, designed to connect various analog audio devices (e.g. two-way radios, intercoms, remote microphones, etc.) via a local network or the Internet.

This program is popular among both radio professionals and hobbyists thanks to its flexibility and vendor-neutrality. Unlike some other solutions, Relay 1 does not, in general, require any third-party services. However, until recently, as any server-client application, to connect, the server side required a fixed IP address.. It is not a problem at all to assign a fixed IP address within the LAN . And, despite lively forum debates on the imminent exhaustion of white IP4 addresses, it is still not an issue to get an IP4 address from the cable provider or LTE carrier. But, anyway, that imposed certain restrictions on the using of the software, say, in the casual places or in the certain networks.

Now the possibilities of using the program have become even wider. Starting from October 2017, users of the software are able to connect different instances of Ruspo Relay 1 through Remote Repeater service. So, if it is impossible to obtain a real IP address for “server” mode, just contact Ruspo tech support — there is a  Remote Repeater solution for an affordable fee ($9.9/mo, prepaid). For this fee, you get a virtual channel, where may be connected up to 5 instances of the program (probably, located geographically in the very different places and connected to the Internet in different ways).

Remote Repeater service have 99.1% average uptime and may be used for constant connection (for example, if Ruspo Relay 1  works as an Internet bridge (repeater) for two-way radios in different locations.

For connection, you have to chose a Client connection mode and input service address and port numbers (provided by the support) in the IP and Port fields. In the common case, you also have to remove a tick from the Stay server ON check-box. Other options are the similar with the conventional case of use. They are comprehensively described in manual.

Free demo version of the program works via Remote Repeater as well, but under usual limitations ( ).

Installing the LetsEncrypt SSL Certificate, and Arranging an Automatic Renewal

Chrome warning
Chrome warning


There are a lot of reasons to use TLS encryption on a website. Some of them are obvious (e.g. the protection of visitor’s safety), some are related to the subtleties like SEO and user experience. Many analysts recommend switching to HTTPS because search engine of Google consider HTTPS as one of the ranking signals. Beside that, new versions of browsers, (e.g. Chrome) frighten visitors of non-encrypted websites, marking them as “unsafe”.

Until recently, many webmasters, bloggers and SOHO business owners used to encrypt their resources with free StartSSL and WoSign certificates. Since StartSSL and WoSign certificates were going to be distrusted by Mozilla ( and Google, and there were no other free options to get SSL for a long term, we have chosen an LetsEncrypt ( option. Since LetsEncrypt certificate is valid for 90 days only, automation is really needed. Recommended automation tool is EFF’s Certbot ( This utility semi-automatically enables HTTPS on your website, deploying Let’s Encrypt certificates.

Hereinafter we share our own experience on initial installation and automation, briefly.


Above mentioned resources give full description for different situations. Here we just demonstrate a logic of using the software for one particular case (only one domain/subdomain on VPS, which had previously another certificate; Nginx as a webserver, and CentOS7 as an OS; root SSH access; also presumed that we can stop webserver temporarily without negative consequences).

Step by step:

1. Install certbot:
yum install certbot

(several EPEL dependencies will be downloaded along; that’s Ok)

2. To obtain a certificate using a built-in “standalone” plugin, you may need to temporarily stop your existing webserver:
systemctl stop nginx

3. Start process:
certbot certonly –standalone -d

and make sure that things go smoothly:


– Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/ Your cert will expire on 2017-04-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run “certbot renew”

Certificates actually will be placed at

Symlinks to certificates will be placed at
You may use Webroot plugin of the Certbot (it allows to get a certificate without stopping/starting Nginx) instead of Standalone plugin, but you will probably need to restart/reload Nginx later anyway in order to activate changes made in config file(s). It made no difference in our case.

4. Find the Nginx config file(s). In our case there are:
/etc/nginx/nginx.conf and the linked one /etc/nginx/conf.d/ext.conf

Make sure to remove or comment off the old Certificate parameters and add the new ones:
# disabled 2017-01-28
# ssl_certificate /etc/nginx/conf.d/yourold.crt;
# ssl_certificate_key /etc/nginx/conf.d/;
# added 2017-01-28
ssl_certificate /etc/letsencrypt/live/;

ssl_certificate_key /etc/letsencrypt/live/;
ssl_trusted_certificate /etc/letsencrypt/live/;

Also it is useful to add directories used by Webroot plugin of the Certbot to the Webroot path (it allows to renew the certificate in the future without stopping/starting Nginx). So add:
location /.well-known {
alias /home/site/.well-known;
into the both parts of the config file:
server {
listen 80;


server {
listen 443 ssl;

(There may be a vague point here, but we found by experience that though Standalone plugin uses port 443, Webroot plugin uses port 80 for verification).

It may be useful to put a test file (a.txt, for instance), into specified directory /.well-known/acme-challenge (to test access later).

Also, if there was not SSL before, several usual options must be added, but we leave old ones.

5. Then don’t forget starting webserver:

systemctl start nginx

Make sure it works and test file is accessible from the Internet via both http and https.

6. Now let’s turn to the future renewals automation.
Find .conf file in /etc/letsencrypt/renewal/

Edit options used in the renewal process like this:


# authenticator = standalone
authenticator = webroot
webroot-path = /home/site

un-comment line:
renew_before_expiry = 5 days

7. Launch Certbot renew using test (dry-run) mode:
certbot renew –dry-run -w /home/site

Make sure all things are OK, especially verification:

Congratulations, all renewals succeeded. The following certs have been renewed: …

9. It makes sence to archive folder /etc/letsencrypt and configuration files (/etc/nginx/conf.d), and store them in a cool, dry place 🙂

8. Add command

certbot renew -w /home/site -q

into the Crontab for daily fulfillment. It will not reload a certificate every day if you set renew_before_expiry properly (see p.6).

9. Make sure your Nginx reloads configuration after certificate renewal. Obvious way for that may be adding command like
nginx -t -q && nginx -s reload
into the Crontab for the certain date. A little bit smarter way would be to tie reloading with the exact moment of certificate renewal. In this case we can modify renewal command (p.8) with hook like this:
certbot renew –no-self-upgrade -w /home/site -q –renew-hook “nginx -t -q && nginx -s reload”

or (with full paths):

certbot renew –no-self-upgrade -w /home/site -q –renew-hook “/usr/sbin/nginx -t -q && /usr/sbin/nginx -s reload”

10. If you have configured some of the other servers (e.g. Webmin) to use the same certificates, don’t forget to reload/restart their configuration as well, e.g.:
systemctl stop webmin
systemctl start webmin

After all that, you may create an appropriate rolling event in your calendar to check if certificate is up-to-date on the website after each 90 days.

This method was approved and works well on both our websites: and


Our experience shows that the Letsencrypt and the Certbot itself run like clockwork. Some issues may appear from the Cron side and usually they caused by incorrect permissions, wrong script name or environment. If you have got problems of that sort, you may have a look at the logs, and to study a couple of useful articles:
6 Reasons Your Cron Job is Not Running ( ).

Paths and files, related to Certbot: