Onderwerp: SSL Sertivicaten, iedere klant. Op een server

ok

Origineel geplaatst door HBCS
www.clesoft.nl bied ook certificaten aan

www.perfectssl.com haal ik ze vandaan.

Origineel geplaatst door The MAzTER

kan je gewoon vinden met google
edit: lol, Comodo gebruikt dezelfde tekst

Niet zo vreemd dit is co-branded......vandaar

Ik zij dus ZONDER credit card

Dus op het mommend alleen web-zila en www.clesoft.nl

Origineel geplaatst door Rollerscapes
Ik zij dus ZONDER credit card

Dus op het mommend alleen web-zila en www.clesoft.nl

WebZilla is het

(Ik weet dat je licht dyslectisch bent, het zou sonde zijn als je niet op de goede website terecht zou komen )

Ik had even zin om een lange reactie te posten

Origineel geplaatst door Triloxigen
Voor ieder SSL cert. is inderdaad een eigen IP nodig.
Dit is ook geldig volgens de RIPE voorwaarden om een IP te krijgen.

Je hebt geen eigen IP nodig voor HTTPS hoor, je zou namelijk HTTPS kunnen gebruiken op andere poorten dan 443. Dat is zeg maar de goedkope manier, de nette manier is uiteraard wel via een eigen IP adres.

Origineel geplaatst door Japi
bij mijn hoster www.in.nl hebben ze iets leuks gedaan met mijn website www.keizerskroon.net

als ik https ervoor zet kom ik bij een voor mij compleet onbekende site terecht. Heb ze er al op gewezen tweemaal, maar na enkele maanden nog steeds niet veranderd.

Dat komt dus omdat HTTPS niet werkt met Host Headers/Virtual Hosts. Kun je eigenlijk niets aan doen, behalve die klant alsnog een eigen IP adres toekennen.

Origineel geplaatst door Rollerscapes
Een https, als die via apache loopt dan moet die aan aparte virtualhost hebben anders krijg je dat hij verkeerd word door gestuurd.

Nogmaals, HTTPS kent geen Virtual Hosts. Een browser hoeft het opgevraagde host adres niet door te sturen naar de server. (Hij stuurt het wel door, maar dat is al versleuteld. Om dat te ontsleutelen heb je het certificaat nodig. De webserver kan dus maar met 1 certificaat per IP/Port omgaan.)

Origineel geplaatst door Rollerscapes
Dat snap ik even niet

Het gaad per ip-adres, maar als de domeinnaam niet overeenkomt dan krijg je zoon fout melding, van niet feilig enzo.

Dat klopt, de browser controleert het SSL certificaat aan de hand van het IP adres en de host/domein naam. Als dat in conflict is, dan krijg je een foutmelding. Je kunt ook een foutmelding krijgen als de browser de uitgever van het SSL certificaat niet kent. Dat krijg je dus bijvoorbeeld als je zelf een SSL certificaat aanmaakt Het is overigens geen foutmelding, maar een waarschuwing.

Origineel geplaatst door Glenn
Is een certificaat nodig om een 128bits versleuteling te krijgen, of heb je die sowieso al met https?

Dit vraag ik omdat iemand die ik ken een zelfgemaakt certificaat (heb je dus niks aan, staat namelijk niet geregistreerd) heeft.

Ja, voor (128 bits) versleuteling heb je inderdaad een SSL certificaat nodig, die kun je eventueel zelf maken (met bijvoorbeeld OpenSSL). Als je HTTPS gebruikt, dan heb je sowieso een SSL certificaat nodig. HTTPS zonder SSL certificaat bestaat niet

Origineel geplaatst door Triloxigen
Maar met alleen HTTPS heb je geen beveilige verbinding (met de juiste server ).

Jawel, met HTTPS heb je altijd een beveiligde verbinding, HTTPS zonder encryptie bestaat namelijk niet.

Origineel geplaatst door Glenn
Thanks The Mazter. Stel je hebt een eigen server in beheer en je hebt een applicatie die je alleen zelf gebruikt die je wilt versleutelen, dan zou je theoretisch dus zonder een certificaat kunnen?

Nee, want zonder certificaat werkt HTTPS niet Je kunt wel zelf een certificaat aanmaken (met bijvoorbeeld OpenSSL), dan heb je ook gewoon HTTP encryptie.

Origineel geplaatst door MediaCreations
Nee, want zonder certificaat werkt HTTPS niet Je kunt wel zelf een certificaat aanmaken (met bijvoorbeeld OpenSSL), dan heb je ook gewoon HTTP encryptie.

volgens mij bedoelde die, zonder een cetificaat aan te schaffen en dus zelf een genereren. Zo las ik het altans.

Het klinkt misschien wel wat flauw maar ik zou toch overwegen eerst Nederlands te leren en pas daarna alles over SSL certificaten.

"Rollerscapes is een pas gestart internet bedrijf dat zich voornamelijk richt internet en wat hier om heen hangt. "

Ik bedoel, hoe zou je die certificaten uberhaupt willen verkopen?

Origineel geplaatst door MediaCreations

Je hebt geen eigen IP nodig voor HTTPS hoor, je zou namelijk HTTPS kunnen gebruiken op andere poorten dan 443. Dat is zeg maar de goedkope manier, de nette manier is uiteraard wel via een eigen IP adres.

Waar zie je mij zeggen dat je voor HTTPS een eigen IP nodig hebt?
Indien je een SSL Certificaat wilt installeren moet je een dedicated IP hebben voor dat domein.

Origineel geplaatst door MediaCreations

Jawel, met HTTPS heb je altijd een beveiligde verbinding, HTTPS zonder encryptie bestaat namelijk niet.

Je hebt inderdaad altijd een beveiligde verbinding..
Maar zoals ik dus al zei "met de juiste server"..
De truuk is 'm nou juist dat het SSL Cert. garandeerd dat je met de juiste server verbonden bent...
Weet je eigenlijk wel wat een SSL Cert. precies allemaal doet en wat je eraan hebt?

Die pagina van Rollerscapes die word binnekoord vervangen door een echt website

Maar is nu dus wel mogelijk op meerdere sertivicate te hebben op 1 IP adres of niet.

En hoe zit dat dan met virhosts in apache, of word dat geregeld door die SSL instelingen.

/Warom kan het nooit makelijk

Je hebt voor ieder SSL Cert. een eigen IP nodig.

Werk je met een control panel (Plesk, cPanel, etc)?
Je moet in ieder geval zorgen dat je een SSL mod hebt voor Apache.

Die heb ik ja

Maar ik was gisteren wat aan het snuffelen.

En toen vond ik dat er wel een virtualhosts is voor OpenSSL onder apache.

<VirtualHost _default_:443>

# General setup for the virtual host
DocumentRoot "/data/apache2/htdocs"
ServerName www.example.com:443
ServerAdmin you@example.com
ErrorLog /data/apache2/logs/error_log
TransferLog /data/apache2/logs/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:+SSL v2:+EXP:+eNULL

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
SSLCertificateFile /data/apache2/conf/ssl.crt/server.crt
#SSLCertificateFile /data/apache2/conf/ssl.crt/server-dsa.crt

# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /data/apache2/conf/ssl.key/server.key
#SSLCertificateKeyFile /data/apache2/conf/ssl.key/server-dsa.key

# 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 /data/apache2/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 /data/apache2/conf/ssl.crt
#SSLCACertificateFile /data/apache2/conf/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 /data/apache2/conf/ssl.crl
#SSLCARevocationFile /data/apache2/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 CompatEnvVars:
# This exports obsolete environment variables for backward compatibility
# to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this
# to provide compatibility to existing CGI scripts.
# 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 "/data/apache2/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 /data/apache2/logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>


Maar staat op port 443, waorm moet je dan toch een apart ip adres hebben

Wand ik heb 1 IP-adres gebruikt voor alle domeinamen op de server.

Dus dan moet dat toch ook kunenn voor SSL ?

Origineel geplaatst door Rollerscapes
Maar staat op port 443, waorm moet je dan toch een apart ip adres hebben

Wand ik heb 1 IP-adres gebruikt voor alle domeinamen op de server.

Dus dan moet dat toch ook kunenn voor SSL ?

SSL kent geen virtual hosts; dit betekent dus in het kort dat als je een SSL certificaat installeert, je automatisch het IP adres gebruikt voor dat certificaat.

Voorbeeld:

site-a.com staat op 127.0.0.1
site-b.com staat op 127.0.0.1

Als je nou een SSL certificaat installeert op site-a, dan krijg je bij https://site-a.com de juiste site te zien die ook nog eens encrypted is.
Probeer je vervolgens https://site-b.com, krijg je site-a.com te zien..

Origineel geplaatst door Henky!
Het klinkt misschien wel wat flauw maar ik zou toch overwegen eerst Nederlands te leren en pas daarna alles over SSL certificaten.

Lees z'n signature eens...

Origineel geplaatst door Triloxigen

(Ik weet dat je licht dyslectisch bent, het zou sonde zijn als je niet op de goede website terecht zou komen )

Zou inderdaad zonde zijn

+ Dat een eigen IP meer zekerheid geeft op de betrouwbaarheid van de juiste locatie.