Let's Encrypt Symlink breaks Coturn configuration

ℹ️ Support 💬 Talk (spreed)
, , ,
1

I have setup coturn reusing my already existing let’s encrypt certificate some weeks ago.
With one of the last let’s encrypt renewals the certbot got upgraded to certbot 1.1.0 (I assume)
It seems with this upgrade, the files within /etc/letsencrypt/live/mydomain/ where replaced with symlinks pointing to the archive directory instead of the actual files.

This breaks coturn in my setup, because it is unable to load the “symlinked” files. My workaround was to delete the symlink and copy back the files from /etc/letsencrypt/archive/mydomain/ into the live directory.

But, I would like to fix this issue permanently and also understand how and when this was applied. I am using NextCloudPi on a standard x86-64 hardware. Perhaps this is also related to this, but I just don’t know (yet). I assume it is a simple permission problem in combination with coturn.

This is the error coturn reports via journalctl after the restart (which happens using hooks automatically after a let’s encrypt renewal).

Feb 04 11:27:53 cloud turnserver[14057]: 0: WARNING: cannot find certificate file: /etc/letsencrypt/live/mydomain/fullchain.pem (1)
Feb 04 11:27:53 cloud turnserver[14057]: 0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly

Feb 04 11:27:53 cloud turnserver[14057]: 0: WARNING: cannot find private key file: /etc/letsencrypt/live/mydomain/privkey.pem (1)
Feb 04 11:27:53 cloud turnserver[14057]: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly

Feb 04 11:27:53 cloud turnserver[14057]: 0: Relay address to use:
Feb 04 11:27:53 cloud turnserver[14058]: 0: pid file created: /run/turnserver/turnserver.pid

This is the content of the directory I am pointing turnserver.conf for the certs

drwxr-xr-x 2 root root 4096 Feb  3 07:58 .
drwxr-xr-x 4 root root 4096 Jun  7  2019 ..
lrwxrwxrwx 1 root root   44 Feb  3 07:58 cert.pem -> ../../archive/mydomain/cert9.pem
lrwxrwxrwx 1 root root   45 Feb  3 07:58 chain.pem -> ../../archive/mydomain/chain9.pem
-rw-r--r-- 1 root root  769 Jan 20 21:03 dhparam.pem
lrwxrwxrwx 1 root root   49 Feb  3 07:58 fullchain.pem -> ../../archive/mydomain/fullchain9.pem
lrwxrwxrwx 1 root root   47 Feb  3 07:58 privkey.pem -> ../../archive/mydomain/privkey9.pem
-rw-r--r-- 1 root root  692 Feb  4  2019 README

After replacing the symlinks with the files itself it works

Feb 04 11:45:12 cloud turnserver[14731]: 0: SSL23: Certificate file found: /etc/letsencrypt/live/mydomain/fullchain.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: SSL23: Private key file found: /etc/letsencrypt/live/mydomain/privkey.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: TLS1.2: Certificate file found: /etc/letsencrypt/live/mydomain/fullchain.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: TLS1.2: Private key file found: /etc/letsencrypt/live/mydomain/privkey.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: TLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5
Feb 04 11:45:12 cloud turnserver[14731]: 0: DTLS: Certificate file found: /etc/letsencrypt/live/mydomain/fullchain.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: DTLS: Private key file found: /etc/letsencrypt/live/mydomain/privkey.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: DTLS1.2: Certificate file found: /etc/letsencrypt/live/mydomain/fullchain.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: DTLS1.2: Private key file found: /etc/letsencrypt/live/mydomain/privkey.pem
Feb 04 11:45:12 cloud turnserver[14731]: 0: DTLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5
Feb 04 11:45:12 cloud turnserver[14731]: 0: Relay address to use:
Feb 04 11:45:12 cloud turnserver[14732]: 0: pid file created: /run/turnserver/turnserver.pid

I also tried to extend the permissions for the archive folder by adding read rights for everyone, but this did not really work - but perhaps I just missed something.

Thanks for any tip :slight_smile:

2

I didn’t have a good reply but you solve my problem.

1 Like
3

at least something good coming out of this

4

have a look at acme.sh

it doesn’t use links to certs. you define the path to cert files. example from here:

acme.sh --install-cert -d example.com \
        --cert-file      /path/to/certfile/in/apache/cert.pem  \
        --key-file       /path/to/keyfile/in/apache/key.pem  \
        --fullchain-file /path/to/fullchain/certfile/apache/fullchain.pem \
        --reloadcmd     "service apache2 force-reload; service coturn force-reload"

just a tipp. not the solution to your certbot problem.

5

Thanks, but this would most properly break the NextcloudPi integration of Letsencrypt, but anyhow, I am going to look at it.

6

Had a closer look but I am using the built in mechanisms of NextCloudPi and this makes it now kind of hard to replace thing. I would to stay as close as possible to NCP.

So it happened again and I have no clue how to fix coturn to use the symlinks or reference to the correct file in the archive file. because the name just changes with every renewal.

7

Created a ticket at the coturn github project

8

OK they would appreciate some help in fixing the symlink handling in their C Code. I am not a DEV and most properly never will be :wink:

Perhaps someone could jump on ship fixing this.

9

Someone helped me figuring this out, I am not sure if it is the most secure solution, but it works with the symlinks created by certbot.

All I needed to do was setting the permissions to 744 for the archive directory and the symlinks resolved correctly after a reboot of coturn

My turnserver installation on Debian runs as the user turnserver and not as root, nor is the user turnserver in any group owning the letsencrypt directory.
If your turnserver does run as root, it should be fine just adding execute permissions.

I hope this helps some of you.