I would like to be able to have my TLS certs chmod 400 root:root or root:wheel. This doesn't work for me right now.
I have:
# ls -l /etc/ssl/sparkles.ooo.fullchain.pem /etc/ssl/private/sparkles.ooo.key
-r-------- 1 root wheel 3272 Aug 9 09:50 /etc/ssl/private/sparkles.ooo.key
-r--r--r-- 1 root wheel 3925 Aug 9 09:50 /etc/ssl/sparkles.ooo.fullchain.pem
If I try to configure prosody to use these:
VirtualHost "sparkles.ooo"
ssl = {
certificate = "/etc/ssl/sparkles.ooo.fullchain.pem";
key = "/etc/ssl/private/sparkles.ooo.key";
}
it chokes:
# prosodyctl start
startup info Hello and welcome to Prosody version unknown
startup info Prosody is using the select backend for connection handling
portmanager info Activated service 'http' on no ports
portmanager info Activated service 'https' on [::]:5281, [*]:5281
portmanager info Activated service 'c2s' on [::]:5222, [*]:5222
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for legacy_ssl port 5223)
portmanager error Error binding encrypted port for legacy_ssl: error loading private key (Permission denied)
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for legacy_ssl port 5223)
portmanager error Error binding encrypted port for legacy_ssl: error loading private key (system lib)
portmanager info Activated service 'legacy_ssl' on no ports
sql error Error in SQL transaction: commit failed
sql error Error in SQL transaction: commit failed
portmanager info Activated service 's2s' on [::]:5269, [*]:5269
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for sparkles.ooo)
sparkles.ooo:tls error Error creating context for c2s: error loading private key (system lib)
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for sparkles.ooo)
sparkles.ooo:tls error Error creating contexts for s2sout: error loading private key (Permission denied)
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for sparkles.ooo)
sparkles.ooo:tls error Error creating contexts for s2sin: error loading private key (system lib)
sparkles.ooo:cloud_notify info Module loaded
sparkles.ooo:http_upload info URL: <https://sparkles.ooo:5281/upload> - Ensure this can be reached by users
sparkles.ooo:http_upload info Storage path: '/var/prosody/http_upload'
portmanager info Activated service 'proxy65' on [::]:5000, [*]:5000
sparkles.ooo:csi_battery_saver info 8717: Successfully loaded module
portmanager info Activated service 'console' on [127.0.0.1]:5582, [::1]:5582
console@sparkles.ooo:tls error Error creating context for c2s: No certificate present in SSL/TLS configuration for console@sparkles.ooo
console@sparkles.ooo:tls error Error creating contexts for s2sin: No certificate present in SSL/TLS configuration for console@sparkles.ooo
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for chat.sparkles.ooo)
chat.sparkles.ooo:tls error Error creating context for c2s: error loading private key (Permission denied)
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for chat.sparkles.ooo)
chat.sparkles.ooo:tls error Error creating contexts for s2sout: error loading private key (system lib)
certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for chat.sparkles.ooo)
chat.sparkles.ooo:tls error Error creating contexts for s2sin: error loading private key (system lib)
c2sbee64498600 info Client connected
c2sbee64498600 warn No stream features to offer
c2sbee64498600 info Client disconnected: connection closed
Prosody has this section in its config file
-- Drop privileges
prosody_user = "_prosody"
prosody_group = "_prosody"
And this must be happening because prosody can't read those files. And also:
comms3# ps auwxx | grep pros
root 9960 0.0 0.9 2348 4368 p3 Tp 1:47PM 0:00.13 vi /etc/prosody/prosody.cfg.lua
_prosody 27600 0.1 1.9 3912 9828 p3 T 2:37PM 0:00.15 /usr/local/bin/lua51 /usr/local/sbin/prosodyctl start
_prosody 97020 0.0 0.2 844 776 p3 Tp 2:37PM 0:00.01 sh -c /usr/local/lib/prosody/../../sbin/prosody
_prosody 6724 0.9 4.2 11392 21280 p3 T 2:37PM 0:00.58 /usr/local/bin/lua51 /usr/local/lib/prosody/../../sbin/prosody
But I want prosody to read its certs before dropping privs.
This is a difficult point on OpenBSD, whose theory of secrets is that apps should start as root, load their certs and other secrets into RAM, and then switch users and call pledge() to drop those unneeded privileges. A lot of their infra -- for example, http://man.openbsd.org/acme-client -- is set up around the assumption that it is safe and good to make things chmod 400 root:wheel. And other apps -- particularly opensmtpd -- refuse to run if their SSL certs are *not* 400 root:wheel.
On Linux, some apps load secrets and then drop privs, and others don't. Debian has an ssl-cert group to put the (users of the) apps that don't. But that's a less good solution because then it means that every app has permissions to every other apps certs -- sometimes that makes sense but in other shared hosting setups it doesn't.
With static ssl certificates this isn't such a problem: for those you can make copies to all the necessary places and set permissions manually each time. But it's a big pain with letsencrypt (or any other acme-client) because it erases and rewrites files according to need.
I added this workaround to root's crontab:
0 * * * * sleep $((RANDOM \% 2048)) && cp /etc/ssl/private/domain.com.key /etc/ssl/private/domain.com.key-prosody && chown _prosody /etc/ssl/private/comain.com.key-prosody
but that seems like a bad hack.
Zash
on
Your assumption that Prosody starts as 'root' and drops privileges is wrong. Prosody does never ever EVER run as root. Changing user is normally done by the init system or prosodyctl.
The general recommendation is to copy certificate and key files into /etc/prosody/certs and make them readable by the 'prosody' user.
For further details see explanation in #263
Changes
tags Status-Duplicate
kousu
on
I see now. Thanks Zash. I was misled because the OpenBSD package comes with:
```
-- Drop privileges
prosody_user = "_prosody"
prosody_group = "_prosody"
```
It is partially true: prosodyctl drops privs -- https://hg.prosody.im/0.11/file/bacca65ce107/util/startup.lua#l446 -- like you said, even if prosody doesn't. I was confused; I didn't realize prosody and prosodyctl were sharing a config file. That makes it seem like they form one coherent app.
I would like to be able to have my TLS certs chmod 400 root:root or root:wheel. This doesn't work for me right now. I have: # ls -l /etc/ssl/sparkles.ooo.fullchain.pem /etc/ssl/private/sparkles.ooo.key -r-------- 1 root wheel 3272 Aug 9 09:50 /etc/ssl/private/sparkles.ooo.key -r--r--r-- 1 root wheel 3925 Aug 9 09:50 /etc/ssl/sparkles.ooo.fullchain.pem If I try to configure prosody to use these: VirtualHost "sparkles.ooo" ssl = { certificate = "/etc/ssl/sparkles.ooo.fullchain.pem"; key = "/etc/ssl/private/sparkles.ooo.key"; } it chokes: # prosodyctl start startup info Hello and welcome to Prosody version unknown startup info Prosody is using the select backend for connection handling portmanager info Activated service 'http' on no ports portmanager info Activated service 'https' on [::]:5281, [*]:5281 portmanager info Activated service 'c2s' on [::]:5222, [*]:5222 certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for legacy_ssl port 5223) portmanager error Error binding encrypted port for legacy_ssl: error loading private key (Permission denied) certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for legacy_ssl port 5223) portmanager error Error binding encrypted port for legacy_ssl: error loading private key (system lib) portmanager info Activated service 'legacy_ssl' on no ports sql error Error in SQL transaction: commit failed sql error Error in SQL transaction: commit failed portmanager info Activated service 's2s' on [::]:5269, [*]:5269 certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for sparkles.ooo) sparkles.ooo:tls error Error creating context for c2s: error loading private key (system lib) certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for sparkles.ooo) sparkles.ooo:tls error Error creating contexts for s2sout: error loading private key (Permission denied) certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for sparkles.ooo) sparkles.ooo:tls error Error creating contexts for s2sin: error loading private key (system lib) sparkles.ooo:cloud_notify info Module loaded sparkles.ooo:http_upload info URL: <https://sparkles.ooo:5281/upload> - Ensure this can be reached by users sparkles.ooo:http_upload info Storage path: '/var/prosody/http_upload' portmanager info Activated service 'proxy65' on [::]:5000, [*]:5000 sparkles.ooo:csi_battery_saver info 8717: Successfully loaded module portmanager info Activated service 'console' on [127.0.0.1]:5582, [::1]:5582 console@sparkles.ooo:tls error Error creating context for c2s: No certificate present in SSL/TLS configuration for console@sparkles.ooo console@sparkles.ooo:tls error Error creating contexts for s2sin: No certificate present in SSL/TLS configuration for console@sparkles.ooo certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Check that the permissions allow Prosody to read this file. (for chat.sparkles.ooo) chat.sparkles.ooo:tls error Error creating context for c2s: error loading private key (Permission denied) certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for chat.sparkles.ooo) chat.sparkles.ooo:tls error Error creating contexts for s2sout: error loading private key (system lib) certmanager error SSL/TLS: Failed to load '/etc/ssl/private/sparkles.ooo.key': Previous error (see logs), or other system error. (for chat.sparkles.ooo) chat.sparkles.ooo:tls error Error creating contexts for s2sin: error loading private key (system lib) c2sbee64498600 info Client connected c2sbee64498600 warn No stream features to offer c2sbee64498600 info Client disconnected: connection closed Prosody has this section in its config file -- Drop privileges prosody_user = "_prosody" prosody_group = "_prosody" And this must be happening because prosody can't read those files. And also: comms3# ps auwxx | grep pros root 9960 0.0 0.9 2348 4368 p3 Tp 1:47PM 0:00.13 vi /etc/prosody/prosody.cfg.lua _prosody 27600 0.1 1.9 3912 9828 p3 T 2:37PM 0:00.15 /usr/local/bin/lua51 /usr/local/sbin/prosodyctl start _prosody 97020 0.0 0.2 844 776 p3 Tp 2:37PM 0:00.01 sh -c /usr/local/lib/prosody/../../sbin/prosody _prosody 6724 0.9 4.2 11392 21280 p3 T 2:37PM 0:00.58 /usr/local/bin/lua51 /usr/local/lib/prosody/../../sbin/prosody But I want prosody to read its certs before dropping privs. This is a difficult point on OpenBSD, whose theory of secrets is that apps should start as root, load their certs and other secrets into RAM, and then switch users and call pledge() to drop those unneeded privileges. A lot of their infra -- for example, http://man.openbsd.org/acme-client -- is set up around the assumption that it is safe and good to make things chmod 400 root:wheel. And other apps -- particularly opensmtpd -- refuse to run if their SSL certs are *not* 400 root:wheel. On Linux, some apps load secrets and then drop privs, and others don't. Debian has an ssl-cert group to put the (users of the) apps that don't. But that's a less good solution because then it means that every app has permissions to every other apps certs -- sometimes that makes sense but in other shared hosting setups it doesn't. With static ssl certificates this isn't such a problem: for those you can make copies to all the necessary places and set permissions manually each time. But it's a big pain with letsencrypt (or any other acme-client) because it erases and rewrites files according to need. I added this workaround to root's crontab: 0 * * * * sleep $((RANDOM \% 2048)) && cp /etc/ssl/private/domain.com.key /etc/ssl/private/domain.com.key-prosody && chown _prosody /etc/ssl/private/comain.com.key-prosody but that seems like a bad hack.
Your assumption that Prosody starts as 'root' and drops privileges is wrong. Prosody does never ever EVER run as root. Changing user is normally done by the init system or prosodyctl. The general recommendation is to copy certificate and key files into /etc/prosody/certs and make them readable by the 'prosody' user. For further details see explanation in #263
ChangesI see now. Thanks Zash. I was misled because the OpenBSD package comes with: ``` -- Drop privileges prosody_user = "_prosody" prosody_group = "_prosody" ``` It is partially true: prosodyctl drops privs -- https://hg.prosody.im/0.11/file/bacca65ce107/util/startup.lua#l446 -- like you said, even if prosody doesn't. I was confused; I didn't realize prosody and prosodyctl were sharing a config file. That makes it seem like they form one coherent app.