web-dev-qa-db-fra.com

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

(Note latérale: j'utilise .insecure pour le fichier de clé car le 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, j'obtiens 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 sais pas lequel est le bon dans Ubuntu: par défaut, Ubuntu utilise ssl-cert, mais d'un autre côté, les processus Apache s'exécutent avec l'utilisateur www-data: il est démarré par l'utilisateur root, mais les modifications apportées à www-data à certains moments et je ne sais pas quand les certificats sont lus.

Mais de toute façon, changer le propriétaire du groupe n'a pas amélioré la situation. Mes questions sont:

  1. Quoi d'autre pourrais-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) travailler ensemble?

Je pense qu'Apache donne un message d'erreur trompeur, et je voudrais identifier l'erreur.

apache-2.2ubuntusslssl-certificatemod-ssl
36
dangonfast

J'ai trouvé l'erreur. C'est parce que j'utilise un script pour configurer les certificats, et l'une des étapes que j'exécute est Apache2ctl configtest. L'erreur provenait de cette commande, et non du redémarrage d'Apache, ce qui me trompait. Comme 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 qui sont uniquement destinées à la vérification de la syntaxe (Apache2ctl), car ils ont également besoin d'accéder aux clés.

42
dangonfast

Je reçois aussi le message

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

tandis que /path/to/file existe et dispose des autorisations appropriées, simplement parce que SELinux est activé et que ce fichier est 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 réparera la propriété SELinux pour le fichier de problème.

8
AntonioK

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/
6
Radamanf

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 que l'éditeur de texte que j'utilisais plaçait un ascii 148 "à droite" au lieu d'un ascii 34 à guillemet normal; en utilisant un éditeur de type unix (par exemple TextWrangler), mettez la bonne citation et corrigez le problème.

1
dkpruett

Les autorisations sont fausses, mais selon votre réponse, ce n'est 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 basés sur Debian.

Je viens de remarquer le perm 0710 et je me demande à quoi il peut servir.

0
user130370