The new Vicibox 8.1 Certbot

[dspaan]

Certbot SSL setup - /usr/local/bin/vicidial-certbot
- You need a FULLY QUALIFIED DOMAIN NAME (FQDN), I.E. vicibox.somedomain.com
- SSL only works with internet IPs in general
- LetsEncrypt SSL certs expire after 90 days, but will set a crontab entry for you
- Updates apache and asterisk for you
- Attempts to do some basic network checks, but it's not super strict
- If you don't have a static IP, you will need to update the DNS for your FQDN when it changes, otherwise this will just break
- Not the most foolproof script, but it works

Long story short you need to be able to go to http://vicibox.somedomain.com from your couch at home and be able to log into the ViciBox web interface across the internet before certbot will even begin to work. Once the web interface is up and the FQDN is correct, certbot will work just fine.

I ran:
cd /usr/local/bin
./vicibox-certbot

First thing i noticed that certbot can't provide a cert because i had closed off allowed services http and https in yast. We also had this problem on our servers before and created a special script for it that opens and closes the firewall ports when issueing a new certificate and renewing. Does Vicibox 8.1 have something similar?

After i opened those ports i succesfully installed a certificate and allowed the script to configure all the needed parts. But when i visit the URL with https:// i get this error: NET::ERR_CERT_COMMON_NAME_INVALID

This is what i see in the apache error log:

[Mon Sep 24 16:02:37.387192 2018] [ssl:warn] [pid 1149] AH01906: corpnew.vicihost.com:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Sep 24 16:02:37.387211 2018] [ssl:warn] [pid 1149] AH01909: corpnew.vicihost.com:443:0 server certificate does NOT include an ID which matches the server name

And i don't see any vhost with my FQDN in /etc/apache2/vhosts.d

[williamconley]

1) look in /etc/letsencrypt/live to see if you have any certs

2) Use the fullchain (this is the cert with all chain info) and privkey links in your ssl conf file to make it work. After you've altered the apache conf file pointing to these sym links, when certbot updates the new cert, it'll "just work" because they'll alter the sym link to point to the new cert.

3) Obviously report your findings in case there was a hiccup in the script somewhere: UNLESS you never actually got the cert and just didn't see the error message.

[dspaan]

Hey Bill,

/etc/letsencrypt doesn't even exist...

[williamconley]

Unless there's some reason it's different on 8.1 than when I manually install, or they're using some other service ... that means you never got a cert. Try running the commands from the script manually until you hit an error?

[dspaan]

It seems the new path is /etc/certbot/live underneath it i have a folder for my FQDN and underneath that my fullchain.pem

[williamconley]

is there also a key?

[dspaan]

Yes:

README cert.pem chain.pem fullchain.pem privkey.pem

[williamconley]

fullchain.pem privkey.pem are the two you use. fullchain is the key (with everything included) and privkey is the key. plug those in to the conf file where crt and key are from the dummy cert and you're done.

[Kumba]

First thing i noticed that certbot can't provide a cert because i had closed off allowed services http and https in yast. We also had this problem on our servers before and created a special script for it that opens and closes the firewall ports when issueing a new certificate and renewing. Does Vicibox 8.1 have something similar?

Nope. It's a basic script designed to just generate LetsEncrypt SSL's and try to install them. So you'll need to modify it to your liking.

After i opened those ports i succesfully installed a certificate and allowed the script to configure all the needed parts. But when i visit the URL with https:// i get this error: NET::ERR_CERT_COMMON_NAME_INVALID

This is what i see in the apache error log:

[Mon Sep 24 16:02:37.387192 2018] [ssl:warn] [pid 1149] AH01906: corpnew.vicihost.com:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Sep 24 16:02:37.387211 2018] [ssl:warn] [pid 1149] AH01909: corpnew.vicihost.com:443:0 server certificate does NOT include an ID which matches the server name

And i don't see any vhost with my FQDN in /etc/apache2/vhosts.d

Can you show me what your /etc/apache2/vhosts.d/1111-default-ssl.conf looks like after the script ran, more specifically the 3 SSL lines that define paths to the certs? And what the server= line from /etc/certbot/cli.ini is?

[dspaan]

Code: Select all

<VirtualHost _default_:443>
        ServerAdmin support@vicidial.com
        ServerName corpnew.vicihost.com
        #ServerAlias
        DocumentRoot /srv/www/htdocs
        ErrorLog /var/log/apache2/error_log
        #CustomLog /var/log/apache2/access_log combined
        CustomLog /dev/null combined
        HostnameLookups Off
        UseCanonicalName Off
        ServerSignature Off
        TraceEnable Off
        Include /etc/apache2/conf.d/*.conf
        DirectoryIndex index.html index.php index.htm

        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl.crt/vicibox.crt
        #SSLCACertificateFile /etc/apache2/ssl.crt/CA_chain.crt
        SSLCertificateKeyFile /etc/apache2/ssl.key/vicibox.key

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>

         BrowserMatch "MSIE [2-5]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

        <Files ~ "^\.ht">
                Require all denied
        </Files>
        <Files ~ "opcache.php">
                Require ip 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12 127.0.0.1
        </Files>

        <Directory "/srv/www/htdocs">
                Options Indexes FollowSymLinks
                AllowOverride None
                Require all granted
        </Directory>

        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

</VirtualHost>

/etc/certbot/cli.ini:

Code: Select all

# The staging/testing server
server = https://acme-v01.api.letsencrypt.org/directory
# The production server.

[Kumba]

Found the issue. In vicibox-certbot I have:

APACHE_CONF="/etc/apache2/vhosts/1111-default-ssl.conf"

when it should be:

APACHE_CONF="/etc/apache2/vhosts.d/1111-default-ssl.conf"

For your issue change the three SSL lines in 1111-default-ssl.conf to be like this:

SSLCertificateFile /etc/certbot/live/$FQDN/cert.pem
SSLCACertificateFile /etc/certbot/live/<FQDN>/fullchain.pem
SSLCertificateKeyFile /etc/certbot/live/<FQDN>/privkey.pem

Make sure you replace <FQDN> with your fully qualified domain name.

Already made that correction in the image so that'll be in v.8.1.1 which is always the wrap-up release to the dot ohhhh (.0) release. I've also gone ahead and started the ViciBox v.8.1 bugfix thread and documented this fixup.

[dspaan]

Yup, it's working now! thnx.

[dspaan]

Kumba, maybe you could add to the install script a choice to redirect all http traffic to https?

[Kumba]

Kumba, maybe you could add to the install script a choice to redirect all http traffic to https?

The problem is if SSL really isn't working right then you have kind of crippled your server. Everything will come up saying security warning and if you aren't experienced enough to know that you'll think bad things happened. Therein lies the crux of the problem. Balancing advanced things from those who know very little.

That's why the certbot script stops after generating an SSL and putting it into apache and Asterisk. There's just too many different ways that things can break that it's hard to know what is and isn't set-up correctly.

I might look at doing some sort of a secondary script or something, but right now I wouldn't want forced SSL to be part of the initial setup. I'll have to think about how to best handle that.

If you want to add that on your own, you can try putting this in /etc/apache2/vhosts.d/1111-default.conf after the SSL section:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

- OR -

Redirect / https://<FQDN>/

[dspaan]

Thanks got it working with the redirect. You could also just add that line to the 1111-default.conf but leave it commented out and add an instruction. Better then nothing.

[Kumba]

Thanks got it working with the redirect. You could also just add that line to the 1111-default.conf but leave it commented out and add an instruction. Better then nothing.

Good point. I've added the mod rewrite part to 1111-default.conf and put a note about it in vicibox-certbot. I also changed the default renewal period to be every Sunday at midnight as well as added an apache soft reload after it. If the SSL certificate is renewed then Apache needs to reload it. It'll be in ViciBox v.8.1.1.

[alexgrad]

vicibox 8.1.1

while running vicibox-certbot

- Congratulations! Your certificate and chain have been saved at
/etc/certbot/live/aaa.bbb.ccc/fullchain.pem. Your cert will
expire on 2018-12-30. 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"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/certbot. You should make a secure
backup of this folder now. This configuration directory will also
contain certificates and private keys obtained by Certbot so making
regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

done.

Do you want to enable the new SSL certificate in Apache/Asterisk? (N/y) : y
/usr/local/bin/vicibox-certbot: line 176: syntax error in conditional expression: unexpected token `;'
/usr/local/bin/vicibox-certbot: line 176: syntax error near `;'
/usr/local/bin/vicibox-certbot: line 176: ` if [[ `/sbin/service apache2 status` == 0]]; then'

1. incorrect check in line 176. check on apache status, but reload asterisk
asterisk is not started by systemd service, so
if [ `pgrep "^asterisk$" |wc -l` -gt 0 ]; then

2. for apache should be
/sbin/service apache2 status >/dev/null 2>&1
if [[ $? == 0 ]]; then

[alexgrad]

/sbin/service asterisk -rx 'module reload http'
should be replaced to
/usr/sbin/rasterisk -x 'module reload http'

[alexgrad]

echo '0 0 * * 0 $CERTBOT_BIN -n --webroot renew >/dev/null 2>&1' >> /tmp/rootcron
should be replaced to
echo "0 0 * * 0 $CERTBOT_BIN -n --webroot renew >/dev/null 2>&1" >> /tmp/rootcron

[alexgrad]

sed -i "/SSLCertificateKeyFile/c\\SSLCertificateKeyFile /etc/certbot/live/<FQDN>/privkey.pem" $APACHE_CONF
sed -i "/SSLCACertificateFile/c\\SSLCACertificateFile /etc/certbot/live/<FQDN>/fullchain.pem" $APACHE_CONF

should be replaced to

sed -i "/SSLCertificateKeyFile/c\\SSLCertificateKeyFile /etc/certbot/live/$FQDN/privkey.pem" $APACHE_CONF
sed -i "/SSLCACertificateFile/c\\SSLCACertificateFile /etc/certbot/live/$FQDN/fullchain.pem" $APACHE_CONF

[alexgrad]

should be added to vicibox-certbot
echo " also need to add rewrite to the APACHE_MODULES variable by editing /etc/sysconfig/apache2"

[Kumba]

Blah. And this is what happens when you get interrupted during the day while doing thinking stuff. Anyways it's been corrected and tested. I also added a part so that it doesn't re-insert itself into the crontab if you keep re-running it and it tab spaces the apache config file to match the rest of it. So that's now fixed and will be in v.8.1.2.

It usually takes 3-4 versions to get everything tuned up. :/

[alexgrad]

So that's now fixed and will be in v.8.1.2.

I see v.8.1.2 released.
Are there any other changes in v.8.1.2?
I do not want to reinstall if it is only these changes.

Could you, please, add a topic "ViciBox v.8.1 Changelog" and documents all changes in minor versions, like
=== Changes from ViciBox v.8.1 to ViciBox v.8.1.1 ===
...
=== Changes from ViciBox v.8.1.1 to ViciBox v.8.1.2 ===

[Kumba]

So that's now fixed and will be in v.8.1.2.

I see v.8.1.2 released.
Are there any other changes in v.8.1.2?
I do not want to reinstall if it is only these changes.

Could you, please, add a topic "ViciBox v.8.1 Changelog" and documents all changes in minor versions, like
=== Changes from ViciBox v.8.1 to ViciBox v.8.1.1 ===
...
=== Changes from ViciBox v.8.1.1 to ViciBox v.8.1.2 ===

The change log is /etc/vicibox-version and v.8.1.2 is mostly just vicibox-certbot fixups with a few commented apache config directives. Most of the release versions after the initial .0 release are for bug fixes. There might be some additional things here and there but they aren't major.

[alexgrad]

The change log is /etc/vicibox-version and v.8.1.2

To look at it I have to download a whole ISO.
Or is it possible to update ViciBox like 'zypper up'?

[Kumba]

Doing 'zypper up' will update the base OS. It won't do anything with the ViciDial SVN codebase or do anything with the handful of ViciBox related scripts and configs. So you can monitor OpenSuSE for changes to OpenSuSE Leap 42.3 and get the OS updates and what not. You can monitor the ViciDial SVN server to get any new changes and additions there. And I'll try to copy vicibox-version to http://download.vicidial.com/vicibox/se ... version8_1 whenever I release a new update.

But the only script in ViciBox used after install is VB-firewall.pl and /etc/sysconfig/scripts/SuSEfirewall2-custom. So whenever there's a bugfix to one of the ViciBox scripts or these they'll be posted in the ViciBox v.8.1 bugfix thread. All the minor stuff like the commented optional apache configs added in ViciBox v.8.1.2 won't be added to the bugfix thread cause it's such a minor thing.

[alexgrad]

And I'll try to copy vicibox-version to http://download.vicidial.com/vicibox/se ... version8_1 whenever I release a new update.

Thank you.

By the way the Asterisk does not reload TLS certificates on "module reload http" if http.conf was not modified.
There is patch on review which fixes it
https://gerrit.asterisk.org/#/c/asterisk/+/10395/

So the cron should modify http.conf file
echo '11 0 * * 0 /usr/sbin/asterisk -rx "module reload http" >/dev/null 2>&1' >> /tmp/rootcron
should be replaced to
echo "11 0 * * 0 touch $ASTERISK_CONF; /usr/sbin/asterisk -rx 'module reload http' >/dev/null 2>&1" >> /tmp/rootcron

[Kumba]

And I'll try to copy vicibox-version to http://download.vicidial.com/vicibox/se ... version8_1 whenever I release a new update.

Thank you.

By the way the Asterisk does not reload TLS certificates on "module reload http" if http.conf was not modified.
There is patch on review which fixes it
https://gerrit.asterisk.org/#/c/asterisk/+/10395/

So the cron should modify http.conf file
echo '11 0 * * 0 /usr/sbin/asterisk -rx "module reload http" >/dev/null 2>&1' >> /tmp/rootcron
should be replaced to
echo "11 0 * * 0 touch $ASTERISK_CONF; /usr/sbin/asterisk -rx 'module reload http' >/dev/null 2>&1" >> /tmp/rootcron

Yeah not really sure how to handle that one. Best approach would just be to bug-patch asterisk and call it a day once they settle down on a patch.

I went ahead and added it to the bugfix thread.

[dspaan]

I just did a new Vicibox 8.1.2 install and ran the certbot script and my cert is working fine. Only i noticded there is nothing that renews the cert in the crontab while the instruction says:

Certbot SSL setup - /usr/local/bin/vicidial-certbot
- You need a FULLY QUALIFIED DOMAIN NAME (FQDN), I.E. vicibox.somedomain.com
- SSL only works with internet IPs in general
- LetsEncrypt SSL certs expire after 90 days, but will set a crontab entry for you

I found an instruction in this thread:

viewtopic.php?f=8&t=37686

The last thing to do is to set certbot to automatically renew the SSL certificate before it expires. This is done with some simple crontab entries like the following:
--------
### Renew SSL certificate monthly
0 5 1 * * /usr/bin/certbot certonly > /var/log/certbot.log
5 5 1 * * /usr/sbin/apache2ctl -k graceful >/dev/null 2>&1
--------
This will cause Certbot to renew the certificate at 5am on the 1st day of the month, and then reload the Apache configuration 5 minutes after. That way you will always have a valid certificate. If you do not do this, then the certificate will expire in a few months. I believe letsencrypt gives you 60 days for each cert, however I'm sure someone will correct me if I'm wrong. Regardless, the certs should be checked monthly. If a renewal is not needed, then certbot will simply exit and apache will harmlessly reload.

Is this still correct?

[thephaseusa]

Should be. Let’s try it and see.

I have certbot on 3 boxes and I need to get that crontab entry in there too.

JM

[dspaan]

Hi,

I found out that if you uncomment these lines in 1111-default.conf the links to recording weblinks also get forced to https and gives you a warning SSL page. Is there a way to make an exception for recording links?

Code: Select all

        ### To force everything to SSL uncomment the following
        ##RewriteEngine On
        ##RewriteCond %{HTTPS} off
        ##RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

[williamconley]

System Settings -> Log Recording Access

This should change the access method in a way that would allow https passthrough.

[dspaan]

If i enable that i get a forbidden page when i want to download a recording. Do i need to change anything in vicirecord.conf?

[williamconley]

I don't think I've ever had that problem. Did you already make changes?

Check the apache log and see if it'll give you the source of the permission issue ...

[dspaan]

I figured out what the problem was with the forbidden page. After that i had to give myself permission to access recordings but then i have the same problem again. When i click a recording link i get this:



Of course i can bypass this by clicking advanced and continue but it's a hassle.

[williamconley]

You are apparently accessing this page with an incorrect domain name. What is the domain name in this request (using the browser's developer's tools to get the request info) vs the name of your cert? This error is explicitly saying that they don't match if I'm reading the error correctly. I didn't think this page would "redirect" at all, and I also don't think it would have a background function to pull file(s) but that may be wrong. The dev tools will tell you, though.

[dspaan]

The domain name is the server ip because that's the only way to access recordings. So to summerize:

-The vicidial server is accessed through https and has a domain name.
-The links to the recordings have an IP in the url and http instead of https
-I can change the links to the recordings so they show a domain name through the server page recording url setting and use https flag in the cronjob but then i can't access the recordings anymore from the QC modify pages

[williamconley]

Does this same concept apply if you push the files to an FTP server using the vicidial ftp script? This would centrally locate the files and override the URL to a domain and likely cause all links to be the same without any overrides caused by "which server is this file on". You could try it with a single file and see if that fixes the problem while awaiting a bug fix on QC.