moin allerseits,
fuer alle, die es interessiert, ich habe es nun hinbekommen, nachdem ich mir weider einmal ne weitere nacht um die ohren geschlagen habe...
ich moechte hier nun *schnell* berichtet, wie ich es zum laufen gebracht habe.
noch ne kleinigkeit zur grundsaetzlichen konfiguration.
ich habe insgesamt 9 virutelle hosts die fuer den zugriff unter http konfiguriert sind und einen fuer den zugriff unter https.
das ganze laeuft auf einer suse linux 9.0 pro distribution.
saemtliche vHosts sind mittels jeweils separater konfigurationsDatei unter /etc/apache2/vhosts.d definiert.
als erstes sorgt man dafuer, dass die kDateien beim laden von apache in der reihenfolge abgearbeitet werden, wie sie in der laufZeitKonfiguration auftauchen sollen. man erreicht dies, indem man z.b. die kDateien im dateiName nummeriert =>
vhost.00.IRGENDEINNAME.conf
vhost.01.IRGENDEINWEITERERNAME.conf
usw...
die konfig fuer den sslHost kommt bei mir zum schluss.
in die erste kDatei (fuer httpAccess) schreibt man vor den vHost die direktive:
Code:
NameVirtualHost xxx.xxx.xxx.xxx:80>
anschliessend wird jeder vHost, der fuer den zugriff via http eingerichtet wird, mittles:
Code:
<VirtualHost xxx.xxx.xxx.xxx:80>
angegeben, wobei xxx.xxx.xxx.xxx jeweils genau die gleiche ipAdresse ist, wie die unter NameVirtualHost. die unterscheidung, welcher host auf welche anfrage antworten soll, trifft man mittels der direktive:
Code:
ServerName host.domain.tld
in der kDatei zum sslVHost beginnt man mit der direktive:
und definiert den ssVHost dann wei folgt:
wenn nun noch die zertifikate fuer den apache verwendbar sind und alles soweit richtig konfiguriert ist, dann sollte es eigentlich klappen.
die durchnummerrierung der vHost scheint mir aus zwei gruenden vernuenftig:
1. wird von apache immer der httpVHost genommen, wenn eine anfrage kommt, die nicht direkt zu einem vHost zugeordnet werden kann, der als erstes in die laufzeitKonfiguration uebernommen wurde. somit kann man bestimmen, welcher vHost diese anfragen bedienen soll.
2. kommen die angaben der NameVirtualHost-direktiven somit nicht durcheinander.
ich poste hier mal noch zwei beispiele fuer http- und httpsVHostConfigFiles:
httpVHost (dateiName => vhost.00.meinVHostDomainName.conf):
Code:
NameVirtualHost xxx.xxx.xxx.xxx:80
<VirtualHost xxx.xxx.xxx.xxx:80> # wobei xxx.xxx.xxx.xxx gleich wie bei NameVirtualHost!
DocumentRoot /pfad/zur/dokumentenRoot
ServerName host.domain.tld # fqdName, auf den der vHost antworten soll
ServerAdmin beliebigeEMailAdresse@domain.tld
LogLevel info
TransferLog /pfad/zur/logDatei/nameDerLogDatei
<Directory "/">
allow from all
order allow,deny
</Directory>
</VirtualHost>
solange dieser kDatei weitere kDateien fuer httpVHosts folgen, muss die direktive NameVirualHost natuerlich nicht meht angegben werden, wenn man diesem, von mir gewaehlten schema treu beleibt.
httpsVHost (dateiName => vhost.ssl.00.meinSSLVHostDomainName.conf):
Code:
NameVirtualHost *:443
<VirtualHost *:443>
DocumentRoot /pfad/zur/dokumentenRoot
ServerName host.domain.tld
ServerAdmin beliebigeEMailAdresse@domain.tld
LogLevel warn
ErrorLog /var/log/apache2/error_log # ich benutzer die stdErrLogDatei
TransferLog /pfad/zur/logDatei/nameDerLogDatei
<Directory "/">
allow from all
order allow,deny
</Directory>
SSLEngine On
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /pfad/zum/zertifikat/certificate.pem
SSLCertificateKeyFile /pfad/zum/zertifikat/key/certificate.key.unsecure
SSLCACertificateFile /pfad/zur/caRoot/cacert.pem
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
wenn ich es nicht vollkommen falsch verstanden habe, so ist die angabe von SSLCACertificateFile nur dann wirklich notwendig, wenn der apache spaeter clientAuthentifizierung mittels clientZertifikaten durchfuehren soll. dann muss er natuerlich wissen, gegen welche ca (ca => certificate authority) er das cZertifikat validieren soll.
fuer den zertifikatsSchluessel empfiehlt es sich, diesen unverschluesselt dem apache zur verfuegung zu stellen, da apache an sonsten zur eingabe des zertifikatsPasswortes auffordert und dies bei jedem start von apache, was natuerlich nicht so schoen ist. man sollte dann allerdings darauf auchte, dass die zugriffsRechte auf den schluessel entsprechend gesetzt werden, da sonst jeder diesen lesen kann. fragt mich aber bitte grad ned wie, muss nachher auch erst mal noch schnell ne runde googlen... :roll:
man kann einen unverschluesselten key erzeugen, indem man folgende anweisung auf der shell reinKlopft:
Code:
openssl rsa -in dateiDieDenSchlusselEnthaelt -out nameDesUVKeys
des weiteren muss man, zumindest unter suse linux 9.0 pro, in der datei /etc/sysconfig/apache2 noch zwei eintraege vornehmen:
1. ssl zu APACHE_MODULES hinzufuegen
2. "-D SSL" zu APAPCHE_SERVER_FLAGS hinzufuegen.
anschliessend SuSEconfig (genau so geschrieben) ausfuehren!
wenn es nicht richtig oder gar nicht tut, dann kann man in dieser datei auch noch "debug" unter APACHE_LOGLEVEL eintragen, dann spuckt der ne menge info aus. default fuer die eintraege ist dann /var/log/apache2. dort findet man die meisten eintraege dann in der datei => error_log.
kleiner tipp => gibt man z.b.
Code:
tail -fn 20 /var/log/apache2/error_log
auf der shell ein, dann werden einem die letzten 20 eintraege in der angegebenen datei auf der shell angezeigt. es haengt also von der zahl ab, die man hinter -fn angibt, wieviele eintraege angezeigt werden. ansich nichts tolles, gelle. schoen ist aber, dass nun saemtliche eintraege, die zur laufzeit hinzukommen, immer gleich auf der shell ausgegeben werden. SEHR hilfreich, wenn man am debuggen ist. dies nur so neben bei...
zum schluss noch eines. beim erzeugen des zertifikates muss fuer den *common name* genau der fqdName angegeben werden, welcher spaeter dann auch benutzt wird, um auf den sslVHost zuzugreifen...!
so, ich hoffe damit dem ein oder anderen, der/die in meiner situation ist, geholfen zu haben.
nen schoenen tag@all
greetz
dialsc
