# SSL Certificate error when attempting a secure=true input stream

**URL:** <https://discourse.libretime.org/t/ssl-certificate-error-when-attempting-a-secure-true-input-stream/1676>\
**Category:** Get Help\
**Created:** [February 16, 2024, 8:39pm UTC](https://discourse.libretime.org/t/ssl-certificate-error-when-attempting-a-secure-true-input-stream/1676 "2024-02-16T20:39:31Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![locua](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.libretime.org/locua/32/781_2.png) [@locua](https://discourse.libretime.org/u/locua)\
**Post date:** [February 16, 2024, 8:39pm UTC](https://discourse.libretime.org/t/ssl-certificate-error-when-attempting-a-secure-true-input-stream/1676/1 "2024-02-16T20:39:31Z")

</div>

**SSL Certificate error when attempting a secure=true input stream.**

I’ve just done a fresh install of libretime on a Debian 11 server. It’s working fine for playing files and streaming with `stream.inputs.main.secure=false`, but when I set that value to `true`, it is giving an error and not accepting the stream.

It seems to be a permissions issue with the libretime-liquidsoap or liquidsoap group not being able to read the SSL certificates. Any ideas?

**To reproduce**  
Steps to reproduce the behavior.

1. Set `stream.inputs.main.secure=true` in **config.yml**.
2. Broadcast stream to the master stream, I’m using Butt for this.

**Expected behavior**

1. LibreTime does not detect the stream.
2. Inspecting **/var/log.syslog** or **liquidsoap.log** spews the following:

```sudo
Feb 16 20:28:41 localhost libretime-liquidsoap[65500]: 2024/02/16 20:28:41 [harbor:2] Failed to accept new client: SSL: Certificate error: error:0200100D:system library:fopen:Permission denied
Feb 16 20:28:41 localhost libretime-liquidsoap[65500]: 2024/02/16 20:28:41 [harbor:2] Failed to accept new client: SSL: Certificate error: error:0200100D:system library:fopen:Permission denied
Feb 16 20:28:41 localhost libretime-liquidsoap[65500]: 2024/02/16 20:28:41 [harbor:2] Failed to accept new client: SSL: Certificate error: error:0200100D:system library:fopen:Permission denied
Feb 16 20:28:41 localhost libretime-liquidsoap[65500]: 2024/02/16 20:28:41 [harbor:2] Failed to accept new client: SSL: Certificate error: error:0200100D:system library:fopen:Permission denied

```

**LibreTime version**  
LibreTime version: 4.0.0

**Installation method and OS / Environment**  
Install script on Debian 11

---

<div class="post-metadata">

**Author:** ![HAL9000](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.libretime.org/hal9000/32/878_2.png) [@HAL9000](https://discourse.libretime.org/u/HAL9000)\
**Post date:** [March 15, 2025, 8:13pm UTC](https://discourse.libretime.org/t/ssl-certificate-error-when-attempting-a-secure-true-input-stream/1676/2 "2025-03-15T20:13:01Z")

</div>

I got same issue on Libretime 4.3.0.  
Harbor looks for symlinks of certs in the let’s encrypt folder “live” that points to the folder “archive” where files are stored.  
File permissions on certs should be ok: owned by root but available for reading to the group and others.  
Did someone solved this issue?

Debian 11

---

<div class="post-metadata">

**Author:** ![imsifrn](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.libretime.org/imsifrn/32/827_2.png) [@imsifrn](https://discourse.libretime.org/u/imsifrn)\
**Post date:** [June 3, 2025, 3:35pm UTC](https://discourse.libretime.org/t/ssl-certificate-error-when-attempting-a-secure-true-input-stream/1676/3 "2025-06-03T15:35:52Z")

</div>

Hello, In my setup Liquidsoap was failing to start its SSL input stream (the `input.harbor.ssl` part) with the error `SSL: Certificate error: error:0200100D:system library:fopen:Permission denied`. This meant Liquidsoap, running as the `libretime` user, could not read its SSL private key file (`privkeyX.pem`) located in `/etc/letsencrypt/archive/(your domain name)/`

The most direct fix for the immediate `Permission denied` error was applying the correct group execute permission to the `/etc/letsencrypt/archive` directory:`sudo chmod g+x /etc/letsencrypt/archive`This allowed the `libretime` user to traverse the directory path and access the private key.

While often handled by Certbot, we also explicitly ensured the specific private key file had the correct group ownership and read permissions:`sudo chgrp ssl-cert /etc/letsencrypt/archive/(domain name)/(priv key name).pem \ sudo chmod g+r /etc/letsencrypt/archive/(domain name)/(priv key name).pem

This ensures the `ssl-cert` group (and thus the `libretime` user) can read the file itself.