Benötigt ein SSL-Zertifikat eine eigene IP-Adresse?

  • Thread starter Thread starter Deleted member 10028
  • Start date Start date
D

Deleted member 10028

Guest
Hallo Zusammen,

benötigt ein SSL-Zertifikat, welches Domaingebunden ist, eine eigene IP-Adresse, damit ich es benutzen kann?
Ich komme auf diese "Idee", weil ich vor einigen Jahren mal mit Plesk gearbeitet habe und dieses eine eigene IP für die Domain benötigt hat, damit ich das Zertifikat anlegen kann.

Zur Zeit verwende ich ispCP mit Apache2.
In den Einstellungen für die Verwendung von SSL im Apache konnte ich bisher nichts zu einer eigenen IP-Adresse finden, warscheinlich verunsichert mich Plesk diesbezüglich einfach.

Zur Info:
ispCP unterstützt momentan kein SSL, deswegen muss ich manuell Hand anlegen, was auch kein Problem ist.


Gruß
Julian
 
Hi,

dass siehst du schon richtig.
Je Zertifikat eine dedizierte IP. Wenn du nur ein Zert brauchst kannst du auch deine jetzige IP als Zert IP verwenden.
 
benötigt ein SSL-Zertifikat, welches Domaingebunden ist, eine eigene IP-Adresse, damit ich es benutzen kann?
Ja und nein. Die Antwort haengt vom Betriebssystem des Client ab.
TLS erlaubt es die Verschluesslung erst nach Uebermittlung des vHost-Namen zu starten und somit mehrere SSL-verschluesselte Webseiten auf einer einzigen IP zu hosten. Klingt zu schoen um wahr zu sein?
Naja Windows XP und andere aeltere Betriebssysteme sowie Browser unterstuetzen diese Funktionalitaet nicht und versuchen eine SSL(2) Verbindung her zu stellen welche 1 IP = 1 Zertifikat = 1 Domain verlangt.

Interessanterweise werden von der RIPE angesichts der IPv4-Knappheit jedoch keine weiteren IP's fuer SSL-Zertifikate vergeben. (Kein ausreichender Grund)
 
Danke für eure Antworten.

An den IPs sollte es nicht scheitern, für meinem Server stehen mir 8 Adressen zur Verfügung.
Der Apache-Server arbeitet mit vHosts und hiebrei geht es mir speziell um eine Subdomain, meine Konfigurationsdaten sieht wie folgt aus:

Code:
<IfModule mod_ssl.c>
<VirtualHost subdomain.domain.de:443>
	ServerAdmin info@domain.de
	
	DocumentRoot /var/www/virtual/subdomain.domain.de/htdocs/
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /var/www/>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	</Directory>

	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
	<Directory "/usr/lib/cgi-bin">
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
	</Directory>

	ErrorLog /var/log/apache2/ssl-error.log

	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn

	CustomLog /var/log/apache2/ssl_access.log combined

	Alias /doc/ "/usr/share/doc/"
	<Directory "/usr/share/doc/">
		Options Indexes MultiViews FollowSymLinks
		AllowOverride None
		Order deny,allow
		Deny from all
		Allow from 127.0.0.0/255.0.0.0 ::1/128
	</Directory>

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

	#   A self-signed (snakeoil) certificate can be created by installing
	#   the ssl-cert package. See
	#   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
	#   If both key and certificate are stored in the same file, only the
	#   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/ssl/subdomain.domain.de/apache.cert.pem
        SSLCertificateKeyFile /etc/ssl/subdomain.domain.de/apache.key.pem
	#SSLCertificateFile    /etc/ssl/apache.cert.pem
	#SSLCertificateKeyFile /etc/ssl/apache.key.pem

	#   Server Certificate Chain:
	#   Point SSLCertificateChainFile at a file containing the
	#   concatenation of PEM encoded CA certificates which form the
	#   certificate chain for the server certificate. Alternatively
	#   the referenced file can be the same as SSLCertificateFile
	#   when the CA certificates are directly appended to the server
	#   certificate for convinience.
	#SSLCertificateChainFile /etc/apache2/ssl.crt/server-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/ssl/certs/
	#SSLCACertificateFile /etc/apache2/ssl.crt/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/apache2/ssl.crl/
	#SSLCARevocationFile /etc/apache2/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 +StrictRequire
	<FilesMatch "\.(cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>
	<Directory /usr/lib/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.
	BrowserMatch ".*MSIE.*" \
		nokeepalive ssl-unclean-shutdown \
		downgrade-1.0 force-response-1.0

</VirtualHost>
</IfModule>

subdomain.domain.de habe ich jetzt lediglich als Platzhalter verwendet.
im ispCP habe ich eine weitere IP-Adresse hinzugefügt, einen entsprechenden Reseller angelegt und mit diesem dann eine Subdomain erstellt.
Natürlich habe ich auch die DNS für die Domain angepasst und die Domain lauscht auch auf der richtigen IP.

Sofern ich nun SSL im Apache aktiviere (a2enmod ssl) und das gekaufte Zertifikat "eintrage", sollte es problemlos funktionieren, richtig? (Natürlich nur reine Theorie).


Gruß
Julian
 
Sofern ich nun SSL im Apache aktiviere (a2enmod ssl) und das gekaufte Zertifikat "eintrage", sollte es problemlos funktionieren
Ohne es in Tiefe analysiert zu haben; ja.
Du kannst uebrigens recht einfach kostenfrei mit einem Testzertifikat (meist auf 14 oder 30 Tage begrenzt) oder einem Cert von StartSSL testen ob alles wie gewuenscht funktioniert bevor du mit dem funkelnagelneuen Cert in den Regelbetrieb gehst.

Kleiner aber feiner Unterschied; du kaufst kein SSL-Zertifikat sondern du mietest es. Der AUssteller kann es zu jedglichem Zeitpunkt revoken, was in einem Update der Browser und Betriebssysteme ausgeliefert wird.
 
Die SSL-Gegenstelle konnte keinen akzeptablen Satz an Sicherheitsparametern aushandeln.
Hast du das Browser-Zertifikat installieren lassen?

Ich hatte immer Probleme mit StartSSL und Chrome, versuch Firefox.
(Dies betrifft nur deren Webseite, nicht die ausgestellten Zertifikate)
 
Welches Zertifikat soll ich installieren?

Normalerweise kenne ich es von selbst-erstellten Zertifkaten so, dass ich diese erst Herunterladen muss, doch das ist dort gar nicht erst möglich, siehe Screenshot.

//Email an startssl ist diesbezüglich schon verschickt.
 
Bei der Registrierung wird dir ein Zertifikat uebermittelt welches der Browser dann fragt ob er installieren soll.
Mit diesem Zertifikat wirst du in spaeteren Sessionen authentifiziert.
Bei Firefox 3.6 ists unter Tools->Options->Advanced->View Certificates->Your certificates gespeichert.
 
Wunderbar, man sollte auch deren Emails lesen *Kopf gegen Wand hau*

Jedoch scheint ein Problem mit meinem Webserver zu bestehen.
Ich wollte nun meine Email-Adresse angeben (webmaster@domainname.de), doch ich erhalte dann folgende Meldung.
Error Sending Mail
There seems to be a problem sending your verification code to webmaster@domain.de"!

Please check your selection and try again. Make sure, the mail server of your mail server is running and not blocking mail from us.

Verify, that the mail account "webmaster@domain.de" exists and is accepting mail!

If your mail server implements grey listing, wait for about five minutes and try it afterwards again.

//Die Email-Adresse existiert defintiv, fungiert jedoch nur als Weiterleitung - Könnte es damit zu tun haben?
//Nach 3 Versuchen konnte ich nun endlich meine Email-Adresse erfolgreich angebenm Problem gelöst.
(und ja, ich habe das Zeitintervall von 5 Minuten eingehalten *gg*)


Vielen Dank für deine Unterstützung.
Die Website rennt nun mit dem SSL-Zertifikat :)

Jetzt nur noch ein "richtiges" Zertifikat beantragen und fertig.
 
Last edited by a moderator:
Back
Top