it-swarm.com.de

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 benutze .insecure für die Schlüsseldatei, da die Datei nicht durch Passphrasen geschützt ist und ich deutlich sehen möchte, dass es sich um eine unsichere Schlüsseldatei handelt)

Wenn ich Apache neu starte, wird folgende Meldung angezeigt:

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 Besitz zu ändern, indem ich zwei Gruppen www-data und ssl-cert verwendet habe. Ich bin mir nicht sicher, welches in Ubuntu das richtige ist: Standardmäßig verwendet Ubuntu ssl-cert, aber andererseits werden die Apache-Prozesse mit Benutzer-www-Daten ausgeführt: Es wird vom Benutzer root gestartet, ändert sich jedoch bei einigen in www-Daten Punkt, und ich bin nicht sicher, wann die Zertifikate gelesen werden.

Der Wechsel des Gruppenbesitzers hat die Situation jedoch nicht verbessert. Meine Fragen sind:

  1. Was könnte ich sonst noch versuchen, um dies 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.

36
dangonfast

Ich habe den Fehler gefunden. Das lag daran, dass ich ein Skript zum Einrichten der Zertifikate verwende und einer der Schritte, die ich ausführe, Apache2ctl configtest Ist. Der Fehler kam von diesem Befehl und nicht vom Neustart von Apache, was mich irreführte. Da ich den Apache2ctl-Befehl als normaler Benutzer ausführte, hatte er keinen Zugriff auf die Schlüsseldateien und damit auf die Fehlermeldung.

Facit: Stellen Sie sicher, dass alle Ihre Apache-Befehle mit Sudo ausgeführt werden, auch diejenigen, die nur zur Überprüfung der Syntax bestimmt sind (Apache2ctl), Da sie ebenfalls Zugriff auf die Schlüssel benötigen.

42
dangonfast

Ich bekomme auch die Nachricht

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

während /path/to/file existieren und haben die richtigen Berechtigungen, nur weil SELinux aktiviert ist und auf diese Datei für Apache-Benutzer nicht zugegriffen werden konnte.

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, führe ich Sudo restorecon -Rv /etc/pki/tls/certs/ - Die SELinux-Eigenschaft für die Problemdatei wird repariert.

8
AntonioK

Ich habe dies getan und es hat mir unter CentOS 5.7 geholfen

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

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, dass der von mir verwendete Texteditor ein "richtiges Anführungszeichen" ascii 148 anstelle eines normalen doppelten Anführungszeichens ascii 34 platzierte; Verwenden Sie einen Unix-Editor (z. B. TextWrangler), geben Sie das richtige Anführungszeichen ein und beheben Sie das Problem.

1
dkpruett

Berechtigungen sind falsch, aber Ihrer Antwort zufolge war dies 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.

Habe gerade die 0710 Dauerwellen bemerkt und frage mich, wofür sie verwendet werden können.

0
user130370