Ao usar vamos criptografar os seguintes diretórios só são acessíveis pelo root:
/etc/letsencrypt/live/
/etc/letsencrypt/archive/
Ao iniciar o MariaDB, ele é executado como usuário "mysql" e, portanto, você recebe uma mensagem de erro ao tentar ativar o SSL com o certificado Let's Encrypt.
[Warning] SSL error: SSL_CTX_set_default_verify_paths failed
Este é o comportamento esperado até agora. Quando eu executo:
chmod 755 /etc/letsencrypt/live/
chmod 755 /etc/letsencrypt/archive/
Isso permite que o MariaDB inicie com SSL ativado, o que pode ser verificado, por ex. com o seguinte comando quando conectado ao MariaDB:
show variables like '%ssl%'
Bem, a questão é quão grande é o problema de segurança. O Nginx pode usar Vamos Criptografar certificados com os privilégios padrão, mesmo que ele seja executado como usuário "nginx" no meu sistema, mas desde que ele esteja usando portas abaixo de < 1024 parece correr com privilégios mais altos que o MariaDB.
chmod 755 torna os arquivos de chave privada do letsencrypt "legíveis para o mundo" no meu sistema ... feio. Você pode se conectar ao meu servidor apenas por meio de autenticação de chave pública SSH e o root não tem permissão para efetuar login. O usuário que tem permissão para fazer o login não pode fazer nada, exceto su root, então uma força bruta até mesmo no sistema parece bastante impossível. Existem alguns outros usuários do sftp no sistema que são chrooted e não podem acessar / etc /...
Então, eu deveria estar seguro, mas gostaria de saber se existe alguma solução para isso sem tornar legível o diretório letsencrypt. (exceto usando certificados auto-assinados para o MariaDB, claro)
Tags security ssl mariadb lets-encrypt