Apache: SSLCertificateKeyFile: le fichier n'existe pas ou est vide

Je configure SSL pour Apache 2. Mon système est Ubuntu Server 10.04 LTS. J'ai les paramètres suivants liés à SSL dans ma configuration vhost:

SSLEngine On
SSLCertificateKeyFile /etc/ssl/private/server.insecure.key
SSLCertificateFile    /etc/ssl/certs/portal.selfsigned.crt

(Remarque: je l’utilise .insecurepour le fichier de clé car ce fichier n’est pas protégé par une phrase secrète et j’aime bien voir qu’il s’agit d’un fichier de clé non sécurisé.)

Ainsi, lorsque je redémarre Apache, je reçois le message suivant:

Syntax error on line 39 of /etc/apache2/sites-enabled/500-portal-https:
SSLCertificateKeyFile: file '/etc/ssl/private/server.insecure.key' does not exist or is empty
Error in syntax. Not restarting.

Mais le fichier est là et n'est pas vide (en fait, il contient une clé privée):

sudo ls -l /etc/ssl/private/server.insecure.key
-rw-r----- 1 root www-data 887 2012-08-07 15:14 /etc/ssl/private/server.insecure.key
sudo ls -ld /etc/ssl/private/
drwx--x--- 2 root www-data 4096 2012-08-07 13:02 /etc/ssl/private/

J'ai essayé de changer de propriétaire en utilisant deux groupes, www-data et ssl-cert. Je ne suis pas sûr de savoir lequel est le bon dans Ubuntu: par défaut, Ubuntu utilise ssl-cert, mais d'autre part, les processus apache fonctionnent avec l'utilisateur www-data: il est lancé par l'utilisateur root, mais des modifications apportées à www-data point, et je ne suis pas sûr quand les certificats sont lus.

Quoi qu'il en soit, le changement de propriétaire du groupe n'a pas amélioré la situation. Mes questions sont:

1. Que puis-je essayer de faire fonctionner cela?
2. Comment puis-je vérifier que mon fichier de clés est un fichier de clés valide?
3. Comment puis-je vérifier que le fichier de clés et le certificat ( /etc/ssl/certs/portal.selfsigned.crt) fonctionnent ensemble?

Je pense qu'Apache envoie un message d'erreur trompeur et je voudrais localiser l'erreur.

J'ai trouvé l'erreur. C'est parce que j'utilise un script pour configurer les certificats, et l'une des étapes que j'effectue est apache2ctl configtest. L'erreur provenait de cette commande et non d'Apache restart, ce qui m'induisait en erreur. Depuis que j'exécutais la commande apache2ctl en tant qu'utilisateur normal, elle n'avait pas accès aux fichiers de clés, et donc au message d'erreur.

Facit: assurez-vous que toutes vos commandes apache sont exécutées avec sudo, même celles destinées uniquement à la vérification de syntaxe ( apache2ctl), car elles nécessitent également un accès aux clés.

Je reçois aussi le message

SSLCertificateKeyFile: file '/path/to/file' does not exist or is empty

bien qu’il /path/to/fileexiste et qu’il dispose des autorisations adéquates, tout simplement parce que SELinux est activé et que ce fichier était inaccessible pour l’utilisateur Apache.

Cela ressemble à ceci:

$ sudo ls -laZ /etc/pki/tls/certs/
drwxr-xr-x. root root system_u:object_r:cert_t:s0      .
drwxr-xr-x. root root system_u:object_r:cert_t:s0      ..
-rw-------. root root unconfined_u:object_r:cert_t:s0  this-one-works.crt
-rw-------. root root unconfined_u:object_r:admin_home_t:s0 this-one-is-unaccessable.crt

Pour résoudre ce problème, je lance sudo restorecon -Rv /etc/pki/tls/certs/- il va réparer la propriété SELinux pour le fichier de problème.

Je l'ai fait et cela m'a aidé sur CentOS 5.7

server:~ # chcon -t cert_t /etc/pki/tls/private/my.key 
server:~ # ls -laZ /etc/pki/tls/private/

J'ai reçu un message similaire:

SSLCertificateChainFile: file '/opt/bitnami/apache2/conf/DigiCertCA.crt\xe2\x80\x9d' does not exist or is empty

Mon problème était l'éditeur de texte que j'utilisais plaçait une "bonne citation" ascii 148 au lieu d'une double citation ascii normale 34; en utilisant un éditeur de type unix (par exemple, TextWrangler), mettez le bon devis et corrigez le problème.

Les autorisations sont erronées, mais selon votre réponse, ce n'était pas la cause du problème:

drwx--x--- 2 root www-data 4096 2012-08-07 13:02 /etc/ssl/private/

/ etc / ssl / private appartient généralement au groupe ssl-cert sur les systèmes Debian.

Je viens de remarquer les permanentes 0710 et je me demande à quoi il peut servir.