SSL für Anfänger?

Wenn ich den Apache neu starte kommt übrigens folgende Warnmeldung:

[root@232428 init.d]# httpd -k restart
[Sat Apr 17 17:23:10 2004] [warn] NameVirtualHost 61.72.355.167:80 has no VirtualHosts
 
nee nee.. ich würde mal nach ssl.conf suchen.
In dieser Datei sind ab Redhat 9? die SSL-Dinger gemacht.
Bearbeite diese Datei mal. Musst ja nur noch Pfad zu den Certificates und den DocumentRoot angeben. Vergesse aber die PHP-Values net!
Viel Spaß!
 
Die ssl.conf ist schnell gefunden. Aber was genau muß ich darin ändern???
welche PHP einstellungen meinst du?
 
Hier ist das file ssl.conf



LoadModule ssl_module modules/mod_ssl.so

# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
Listen 443


# Dynamic Shared Object (DSO) Support

# To be able to use the functionality of a module which was built as a DSO you
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common



#
# Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl

# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin

# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
#SSLSessionCache none
#SSLSessionCache dbm:/var/cache/mod_ssl/scache(512000)
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300

# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex file:logs/ssl_mutex

# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512

#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName new.host.name:443
#ServerAdmin you@your.address

# Use separate log files:
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log

# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on

# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP


SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
#SSLCertificateFile /etc/httpd/conf/ssl.crt/server-dsa.crt


SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
#SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server-dsa.key


#SSLCertificateChainFile /etc/httpd/conf/ssl.crt/ca.crt

# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/httpd/conf/ssl.crt
#SSLCACertificateFile /usr/share/ssl/certs/ca-bundle.crt

# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/httpd/conf/ssl.crl
#SSLCARevocationFile /etc/httpd/conf/ssl.crl/ca-bundle.crl

# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10

# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>

# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>
 
Langsam wird's interessant:

jetzt hab ich den neuen Virtual Host Eintrag den ich ursprünglich neu in die httpd.conf gelegt habe in die ssl.conf verschoben.
Das Ergebnis: Es funktioniert!!!
Unter https://ssl.domain.de kommt meine Site. also das Verzeichnis html/SSL

ABER: unter https://irgendwas.domain.de kommt meine Site auch!!! :( :mad: :mad: :confused: :confused:

Aber warum? Der Virtual Host Eintrag bezieht sich doch nur auf meine ssl.domain.de

hier nochmal der eintrag:

<VirtualHost 61.72.231.147:443>
ServerName ssl.domain.de
DocumentRoot /var/www/web1/html/ssl
SuexecUserGroup web1 ftponly
ScriptAlias /cgi-bin/ /var/www/web1/html/cgi-bin/
php_admin_value open_basedir /var/www/web1/:/var/www/html/phpmyadmin/:/var/www/confixx/html/gesperrt/
php_admin_value upload_tmp_dir /var/www/web1/phptmp/
php_admin_flag safe_mode Off
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
</VirtualHost>
 
Hallo Huschi...

inzwischen weiß ich warum das gestern abend nicht so funktioniert hat:

Ich hatte das "SSLEngine on" vergessen :rolleyes: Mann bin ich doof!!!!

Und jetzt wie gesagt: Es funktionert, nur leider nicht nur mit der einen gewünschten Sub-Domain, sondern egal was man vorne dran schreibt, alles verlinkt in mein eines SSL verzeichis :(
 
cretter said:
inzwischen weiß ich warum das gestern abend nicht so funktioniert hat:
Es war halt schon spät, gelle? ;)

Es funktionert, nur leider nicht nur mit der einen gewünschten Sub-Domain, sondern egal was man vorne dran schreibt, alles verlinkt in mein eines SSL verzeichis :(
Dann kommen wir zur Feinabstimmung:
Füge noch dieses nach oder in der SSL-vhost ein:
Code:
<Directory /var/www/web1/html/ssl>
  SSLRequire %{SERVER_NAME} eq "ssl.domain.de"
</Directory>

Dann werden alle Versuche über eine andere Domain mit "403 Forbidden" geandet.

huschi.
 
Guten Morgen

Aktueller Stand: Feintuning war erfolgreich! :)

https://ssl.domain.de verlinkt in das gewollte Verzeichnis
https://irgendwas(also www, oder beliebig).domain.de verlinken immer auf eine Seite von Server4You wo dann steht dass ich noch nichts hochgeladen habe.

Was ich jetzt noch nicht ganz verstehe:
Wo stell ich diesen https://irgendwas(also www, oder beliebig).domain.de ab??? Denn da sollte meiner Ansicht nach einfach nichts kommen.

Und 2. : Wie kann ich neue SSL-Subdomains hinzufügen. Denn ich hab dasselbe wie wir mit https://ssl.domain.de gemacht haben mal mit https://ssl2.domain.de getestet. Das funktioniert dann nicht mehr, und linkt auch immer auf die Server4You site :(:(:(
 
cretter said:
Wo stell ich diesen https://irgendwas(also www, oder beliebig).domain.de ab??? Denn da sollte meiner Ansicht nach einfach nichts kommen.
Ach nein???
Was kommt sollte, Deiner Meinung nach, der Browser anzeigen, wenn man eine falsche Domain angibt?

Und 2. : Wie kann ich neue SSL-Subdomains hinzufügen. Denn ich hab dasselbe wie wir mit https://ssl.domain.de gemacht haben mal mit https://ssl2.domain.de getestet. Das funktioniert dann nicht mehr, und linkt auch immer auf die Server4You site :(:(:(
Grundsätzlich mal 2 Dinge:
a) 'die Server4You site' ist die Default-Startseite von Deinem Server. Die kannst Du auch relativ einfach ändern...
b) SSL ist IP- und nicht Domain-basiert. D.h. theoretisch kann man keine 2 Domains mit der selben IP (am selben Port) mit SSL laufen lassen.

Zu b) muß man folgendes sagen: Wenn man das mitgelieferte Zertifikat von Apache nutzt, kann man durchaus zwei Domains betreiben. Es ist aber keine saubere Lösung. Normalerweise macht man sich sein eigenes Zertifikat und dies ist (zwangsweise) mit nur einer Domain verknüpft.

huschi.
 
Servus!
Also:
SSL geht grundsätzlich nur mit EINER IP und demnach auch nur EINER Domain!
Und diese hast du hiermit schon aufgebraucht, so ein Mist, gelle? :)
Hier gibt es aber natürlich wie immer auch mal eine Lösung Europas Webhosters #1:
http://server.1und1.com/root_server/howto/6.html
Außerdem würde ich an deiner Stelle diese Fehler-Datei von S4Y auf dich anpassen, ich mag es nicht, wenn da so eine indirekte Werbung drauf ist!
Das How2 von 1&1 sollte einbahnfrei auf dem Server funzen!
Viel Spaß damit.

edit:
Der Huschi hat ja gerade noch das mit den Certificates geschrieben. Unter all diesen verwirrenden Beschreibungen, die es da so im Netz gibt.. gibt es hier die Offizielle von europe.redhat.com:
http://europe.redhat.com/documentation/rhl9/rhl-cg-en-9/ch-httpd-secure-server.php3
Wenn du Spaß dran hast, kannst du das ganze auch in German haben, aber ich hatte halt gerade die Englishe erwischt (reiner Zufall! lol)
 
Last edited by a moderator:
Zusammenfassend also:

Auch wenn ich eine 2. Domain auf meinern Vserver connecte, kann ich trotzdem keine weitere ssl-verbindung aufbauen.
Ich würde eine weitere IP-Adresse benötigen, und die gibts veim vserver nicht. (oder eben die lösung die von 1und1 beschrieben ist)

Kann mir einer von euch noch sagen, WO diese Standard-Site von server4you liegt? ich hab schon gesucht und finde sie nicht.
 
cretter said:
Kann mir einer von euch noch sagen, WO diese Standard-Site von server4you liegt? ich hab schon gesucht und finde sie nicht.
Ja, könnte ich...
Aber leider habe ich gerade keine Zeit, sie zu suchen, da ich es nicht im Kopf habe.
Schick dir nachher noch ne PN
 
Jetzt schreib ich es doch noch schnell hier herein, dann brauchen andere nicht ewig suchen:
/var/www/error/noindex.html
Damit sollte diese Frage auch gelöst sein.
 
cretter said:
Dann brauch ich jetzt noch ein Zertitikat. grundsätzliche Frage:
Um diese lästige Abfrage vor der SSL-Verbindung loszubekommen - muß ich da ein Zertifikat kaufen, oder reicht es wenn ich mir auf diesem Weg http://server.1und1.com/root_server/security/9.html eins selbst erstelle?
kaufen..kaufen...kaufen...
umsonst ist leider nur der Tod :)
Wenn du es aber nur für private Zwecke benutzt reicht es ja auch einfach das Certificate als vertrauenswürdig einzustufen, dann kommt keine Frage mehr... ansonsten musst du halt eins kaufen und das geht gewaltig ins Geld!
 
Guten Morgen,

neulich hab ich irgendwo gelesen, dass man sein Zertifikat auch irgendwo kostenlos signieren lassen kann. Schade, ich hab den Link nicht mehr, sonst würde ich ihn euch schicken.

Die Verschlüsselungsqualität an sich, ist aber unabhängig vom Zertifikat, oder? Also ich mein: Das Standard Apache SSL-Cert verschlüsselt im Moment genauso gut, als wenn ich später mal mein neues Zertifikat teuer von verisign signieren lasse, oder?
 
cretter said:
neulich hab ich irgendwo gelesen, dass man sein Zertifikat auch irgendwo kostenlos signieren lassen kann.
Klar, ich signier Dir das Ding auch kostenlos. Du mußt nur Deinem Browser sagen, daß ich 'trusted' bin. ;)
Das ist das eigendliche Problem. Sobald Du ein Crert. haben willst, wo der User ohne 'OK' zuklicken surfen kann, kostet es Geld.

Also ich mein: Das Standard Apache SSL-Cert verschlüsselt im Moment genauso gut, als wenn ich später mal mein neues Zertifikat teuer von verisign signieren lasse, oder?
Die Verschlüsselung ist genauso gut. Aber beim Apache-Cert kann halt trotzdem jeder mitlesen, der mitlesen will, da ja jeder an den private-Key kommt. Gegen eine Man-in-the-middle-Attacke hilft dieses Cert rein gar nichts. Erst, wenn Du Deinen Eigenen gemacht hast bist Du gegen soetwas gefeit.

huschi.
 
Oka, dann erstell ich mir jetzt ein eigenes Zertifikat, damit erstmal niemand mitlesen kann.

Die andere Sache: Woher weiß der Browser welche Zertifizierungsstellen trusted sind?
 
Back
Top