Apache: SSLCertificateKeyFile: Datei existiert nicht oder ist leer

Ich konfiguriere SSL für Apache 2. Mein System ist Ubuntu Server 10.04 LTS. Ich habe die folgenden Einstellungen in Bezug auf SSL in meiner vhost-Konfiguration:

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

(Randnotiz: Ich verwende .insecurefür die Schlüsseldatei, weil die Datei nicht durch Passphrasen geschützt ist, und ich möchte deutlich sehen, dass es sich um eine unsichere Schlüsseldatei handelt.)

Wenn ich Apache neu starte, erhalte ich die folgende Meldung:

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.

Aber die Datei ist da und nicht leer (tatsächlich enthält sie einen privaten Schlüssel):

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/

Ich habe versucht, den Inhaber zu ändern, indem ich zwei Gruppen www-data und ssl-cert verwendete. Ich bin mir nicht sicher, welches in Ubuntu das richtige ist: Ubuntu verwendet standardmäßig ssl-cert, aber die Apache-Prozesse laufen auf der anderen Seite mit Benutzer-WWW-Daten: Sie werden vom Benutzer root gestartet, ändern sich jedoch in einigen Fällen zu WWW-Daten Punkt, und ich bin nicht sicher, wann die Zertifikate gelesen werden.

Der Wechsel des Gruppeneigentümers hat die Situation jedoch nicht verbessert. Meine Fragen sind:

1. Was könnte ich sonst noch versuchen, um das zum Laufen zu bringen?
2. Wie kann ich überprüfen, ob meine Schlüsseldatei eine gültige Schlüsseldatei ist?
3. Wie kann ich überprüfen, ob die Schlüsseldatei und das Zertifikat ( /etc/ssl/certs/portal.selfsigned.crt) zusammenarbeiten?

Ich denke, dass Apache eine irreführende Fehlermeldung ausgibt, und ich möchte den Fehler genau bestimmen.

Ich habe den Fehler gefunden. Es war, weil ich ein Skript verwende, um die Zertifikate einzurichten, und einer der Schritte, die ich durchführe, ist apache2ctl configtest. Der Fehler kam von diesem Befehl und nicht von Apache Restart, was mich irreführte. Da ich den Befehl apache2ctl als normaler Benutzer ausgeführt habe, hatte er keinen Zugriff auf die Schlüsseldateien und damit auf die Fehlermeldung.

Facit: Stellen Sie sicher, dass alle Apache-Befehle mit sudo ausgeführt werden, auch diejenigen, die nur zur Syntaxüberprüfung ( apache2ctl) vorgesehen sind, da sie sonst Zugriff auf die Schlüssel benötigen.

Ich bekomme auch die Nachricht

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

während /path/to/fileexist und rechten Berechtigungen haben, wandte sich nur wegen der SELinux auf und diese Datei war für Apache Benutzer unaccessable.

Es sieht aus wie das:

$ 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

Um dies zu beheben, starte ich sudo restorecon -Rv /etc/pki/tls/certs/- es repariert die SELinux-Eigenschaft für die Problemdatei.

Ich habe das getan und es hat mir auf CentOS 5.7 geholfen

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

Ich habe eine ähnliche Nachricht erhalten:

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

Mein Problem war der Texteditor, mit dem ich ein "richtiges Anführungszeichen" gesetzt habe. Verwenden Sie einen Unix-Editor (zB TextWrangler), geben Sie das richtige Zitat ein und beheben Sie das Problem.

Berechtigungen sind falsch, aber laut Ihrer Antwort war es nicht die Ursache des Problems:

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

/ etc / ssl / private gehört normalerweise zur Gruppe ssl-cert auf debian-basierten Systemen.

Ich habe gerade die 0710 Dauerwellen bemerkt und mich gefragt, wofür sie verwendet werden können.