APACHE2: Abfage der geladenen Module

[Tom]

Hello,

ich steh gerade im Wald.
Ich wollte die geladenen Module des Apachen abfragen und bekomme leider nur eine Fehlermeldung. Wo liegt denn da jetzt mein Denkfehler?

debian4:/usr/sbin# apache2 -t
apache2: bad user name ${APACHE_RUN_USER}

debian4:/usr/sbin# apache2 -D
apache2: option requires an argument -- D
Usage: apache2 [-D name] [-d directory] [-f file]
               [-C "directive"] [-c "directive"]
               [-k start|restart|graceful|graceful-stop|stop]
               [-v] [-V] [-h] [-l] [-L] [-t] [-S] [-X]
Options:
  -D name            : define a name for use in <IfDefine name> directives
  -d directory       : specify an alternate initial ServerRoot
  -f file            : specify an alternate ServerConfigFile
  -C "directive"     : process directive before reading config files
  -c "directive"     : process directive after reading config files
  -e level           : show startup errors of level (see LogLevel)
  -E file            : log startup errors to file
  -v                 : show version number
  -V                 : show compile settings
  -h                 : list available command line options (this page)
  -l                 : list compiled in modules
  -L                 : list available configuration directives
  -t -D DUMP_VHOSTS  : show parsed settings (currently only vhost settings)
  -S                 : a synonym for -t -D DUMP_VHOSTS
  -t -D DUMP_MODULES : show all loaded modules
  -M                 : a synonym for -t -D DUMP_MODULES
  -t                 : run syntax check for config files
  -X                 : debug mode (only one worker, do not detach)

debian4:/usr/sbin# apache2 -D DUMP_MODULES
apache2: bad user name ${APACHE_RUN_USER}

debian4:/usr/sbin# ps -aux | grep apache
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
root      3033  0.0  1.3  30384  6776 ?        Ss   10:20   0:00 /usr/sbin/apache2 -k start
www-data  3053  0.0  0.9  30716  4680 ?        S    10:21   0:00 /usr/sbin/apache2 -k start
www-data  3054  0.0  0.6  30384  3480 ?        S    10:21   0:00 /usr/sbin/apache2 -k start
www-data  3055  0.0  0.6  30384  3476 ?        S    10:21   0:00 /usr/sbin/apache2 -k start
www-data  3056  0.0  0.6  30384  3476 ?        S    10:21   0:00 /usr/sbin/apache2 -k start
www-data  3057  0.0  0.6  30384  3476 ?        S    10:21   0:00 /usr/sbin/apache2 -k start
root      3516  0.0  0.1   3140   760 pts/0    R+   11:35   0:00 grep apache

debian4:/usr/sbin# ./apache2 -t
apache2: bad user name ${APACHE_RUN_USER}
debian4:/usr/sbin#

Und nun?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Vinzenz Mai]

Hallo,

Ich wollte die geladenen Module des Apachen abfragen und bekomme leider nur eine Fehlermeldung. Wo liegt denn da jetzt mein Denkfehler?

debian4:/usr/sbin# apache2 -t
apache2: bad user name ${APACHE_RUN_USER}

Das ist zu erwarten, das ist kein Fehler. Das ist genauso dokumentiert.

Und nun?

Doku lesen:

man apache2

Noch genauer steht es in

/usr/share/doc/apache2/README.Debian.gz

Versuche es daher mit

apache2ctl -M

wie es in der Debian-Doku steht.

Freundliche Grüße

Vinzenz

[Tom]

Hello,

Und nun?
Doku lesen:

apache2ctl -M

wie es in der Debian-Doku steht.

Danke Vinzenz.

Da hätte ich nun gedacht, dass es so funktioniert, wie das Programm es selber mitteilt... zumal ich noch im Dezember eine Installation in den Fingern hatte, die es getan hat.

Also nochmal lesen.

Ich möchte eine Seite auf SSL umstellen - ohne fremdzertifizierten Schlüssel zwar, aber eben mit geschützter Kommunikation. Das funktioniert hier auch nicht so, wie ich es erwarte. Gibt's da auch solche Fallstricke? Schaun wir mal.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Tom]

Hello,

nächster Schritt: Der Apache 2.2 soll möglichst simpel auf einem Virtual Host für SSL (HTTPS) eingerichtet werden. Eine eigene IP würde dafür bereitstehen.

Welche Nachteile muss in Kauf nehmen, wenn ich einen Zertifizierer benutzen will, sondern "nur" ein eigenes Zertifikat erzeugen will? Ich habe gehört, dass der Firefox 3.x dann schon recht lästig reagieren soll. Stimmt das?

Es handelt sich nur um einen geschlossenen Benutzerkreis, dessen Kommunikation mit dem Server aber auch niemand außenstehendes etwas angeht. Diesen Benutzern kann man eine Anleitung für die Benutzung zumuten.

Gibt es eine gute Anleitung für die Einrichtung? Ich habe schon das Archiv und einige Anleitungen aus dem Internet durchgeforstet und ausprobiert und bleibe dann immer wieder irgendwo stecken, weil wohl irgendwas ausgelassen wurde... bzw. ich eben 'was ausgelassen habe. :-(

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Tom]

Hello,

Welche Nachteile muss     in Kauf nehmen, wenn ich einen Zertifizierer benutzen will, sondern "nur"

ich                          keinen

Ich verstehe nicht, was hier zwischenzeitlich passiert mit den Postings. Vorhin war es noch vollständig!

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[flowh]

Hallo Tom.

Gibt es eine gute Anleitung für die Einrichtung?

Kennst du diese diese Anleitung?

[..] und bleibe dann immer wieder irgendwo stecken, weil wohl irgendwas ausgelassen wurde... bzw. ich eben 'was ausgelassen habe. :-(

Sag uns doch, bei was du stecken bleibst.

Grundsätzlich schaut das so aus:
Du erstellst dir dein Zertifikat (das natürlich dann erstmal nicht "trusted" ist) via openssl req -new -x509 -nodes -days 365 -out certificate.crt -keyout private.key

  
Listen 127.0.0.1:443  
NameVirtualHost 127.0.0.1:443  
<VirtualHost 127.0.0.1:443>  
    ServerName secure.example.org  
    DocumentRoot /var/www/secure/  
  
    SSLEngine On  
    SSLCertificateFile /path/to/your/certificate.crt  
    SSLCertificateKeyFile /path/to/your/private.key  
</VirtualHost>

Das müsste eigentlich reichen, um deinen Server über https://secure.example.org erreichen zu können.

Servus,
Flo

[Tom]

Hello Flo,

das sieht nun wieder ganz einfach aus.
Hab ich mir das Leben viel zu schwer gemacht?
Probiere ich gleich aus.

Wo gebe ich die gewünschte Schlüssellänge an?

ich sehe schon: -> man openssl komme ich nicht drum herum :-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[flowh]

Hallo Tom.

ich sehe schon: -> man openssl komme ich nicht drum herum :-)

Ist sicher kein Fehler.
Bei mir (Debian) war die Default-Schlüssellänge 1024 Bit (RSA), ich denke, das sollte eigentlich ausreichen.

Servus,
Flo

[Tom]

Hello,

ich sehe schon: -> man openssl komme ich nicht drum herum :-)
Ist sicher kein Fehler.
Bei mir (Debian) war die Default-Schlüssellänge 1024 Bit (RSA), ich denke, das sollte eigentlich ausreichen.

Und es funktioniert jetzt bei mir auch.

Der Fehler war wohl, dass ich immer mit -rsa statt mit -x509 gearbeitet habe. Da musste dann immer die CA noch angegeben werden, was ich ja nicht will. Es sollte ja ein Eigenzertifikat werden.

Die manpage ist etwas lästig zu lesen, weil sie auf diverse Einzelseiten aufgeteilt ist. Da habe ich das bisher auch noch nicht gefunden, wie man trotz Eigenzertifikat die Schlüssellänge festlegen kann.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Tom]

Hello,

die letzte Frage wie immer zum Schluss:

welche Rechte sollten für die Verzeichnisse eingerichtet werden, in denen die Schlüssel und Zertifikate geparkt werden?

/etc/ssl/cert/certificate.crt
    /etc/ssl/private/private.key

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[flowh]

Hallo Tom.

Die manpage ist etwas lästig zu lesen, weil sie auf diverse Einzelseiten aufgeteilt ist.

Mir sind mehrere kleine man-pages lieber als eine fette. Ist wahrscheinlich Geschmackssache.

Da habe ich das bisher auch noch nicht gefunden, wie man trotz Eigenzertifikat die Schlüssellänge festlegen kann.

man req bringt dieses Beispiel: openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem

In Bezug auf dein letztes Posting zu Rechten:
Rechte sollten immer so restriktiv wie möglich und so freizügig wie nötig gesetzt werden.
D.h. konkret für die Zertifikate/Schlüssel, dass sie dem Apachen (unter Debian: www-data) gehören sollten, und nur er außschließlich Leserechte auf sie hat. Also chown www-data file.crt und chmod 400 file.crt.

Servus,
Flo

[Tom]

Hello,

In Bezug auf dein letztes Posting zu Rechten:
Rechte sollten immer so restriktiv wie möglich und so freizügig wie nötig gesetzt werden.
D.h. konkret für die Zertifikate/Schlüssel, dass sie dem Apachen (unter Debian: www-data) gehören sollten, und nur er außschließlich Leserechte auf sie hat. Also chown www-data file.crt und chmod 400 file.crt.

Meisnt Du nicht besser, dass sie root gehören sollten? Der Apache läuft ja unter root, nur seine öffentlichen Kinder laufen unter dem user (z.B. www-data)

Zur Zeit ist auf dem Testserver durch die automatische Installation von openssl eingerichtet:

debian4:~# cd /etc/ssl
debian4:/etc/ssl# ls -la
insgesamt 40
drwxr-xr-x   4 root root      4096 2008-11-01 19:38 .
drwxr-xr-x 116 root root      4096 2009-03-10 18:31 ..
drwxr-xr-x   2 root root     16384 2009-03-10 13:20 certs               <---
-rw-r--r--   1 root root      9374 2008-08-04 01:06 openssl.cnf
drwx--x---   2 root ssl-cert  4096 2009-03-10 13:21 private             <---
debian4:/etc/ssl#

und dann in den Verzeichnissen ganz normal 644 für die Files

An die private Keys sollte ja möglichst niemand anderes herankommen.
Das hat bei mir eben die Frage aufgeworfen, wer muss denn die Certificates lesen können?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg