PDA

Bekijk Volledige Versie : SSL Sertivicaten, iedere klant. Op een server



SebastiaanStok
25/03/05, 10:36
Sorry voor die tietel :)

Mijn vraag is dus als volgt, voor de hosting dienst wil ik standaart ierdere klant de optie geven van https

Maar nu heb ik vernomen dat dit per domein op een apart ip adres moet :huh:


Dus hoe zit het nu, kan ik de klanten gewoon https geven op een 1 IP adres of moet ik hier iets anders voor bedenken :(


Edit: /typo, het is nog vroeg.

Triloxigen
25/03/05, 11:02
Voor ieder SSL cert. is inderdaad een eigen IP nodig.
Dit is ook geldig volgens de RIPE voorwaarden om een IP te krijgen.

SebastiaanStok
25/03/05, 11:05
Dus hoe kan ik dit het beste doen ?

Ik kan gratis IP adresen aanvragen op RIPE-voorwaarden.

Triloxigen
25/03/05, 11:07
Gewoon aan je hosting/colocatie boer om een IP vragen omdat je een SSL cert. wilt installeren.

SebastiaanStok
25/03/05, 11:11
En wat is hier het limiet van ?

Wand zoals ik al zij, IEDERE klant op een shared hosting.

Dit kan bij wij ze van tot 100 Oplopen, en ik dank niet dat RIP Daar blij mee is :D

Triloxigen
25/03/05, 11:29
Als iedere klant een SSL Cert. nodig heeft (en dus niet alleen HTTPS, maar echt SSL) dan hebben ze allemaal een IP nodig.

En of ze er blij mee zijn of niet, het is wel nodig :)

repsaj
25/03/05, 12:30
lol, heb je strax heel ip block op je naam staan
voor een server :)

SebastiaanStok
25/03/05, 12:32
Dus het is mogelijk :)

Dat wilden ik dus gewoon weten, maar is het wezelijk.

Ik bedoel moet ik het standaart er bij doen of op aanvraag ? Wat is het verstandichts ;)

Triloxigen
25/03/05, 12:42
Het is gewoon te doen :)

En SSL cert. zou ik niet standaard erbij doen, dit zijn jaarlijkse kosten die je betaald terwijl niet eens alle klanten er gebruik van zullen maken.

TSG-Hans
25/03/05, 12:42
Origineel geplaatst door Rollerscapes
Dus het is mogelijk :)

Dat wilden ik dus gewoon weten, maar is het wezelijk.

Ik bedoel moet ik het standaart er bij doen of op aanvraag ? Wat is het verstandichts ;)

Eeeuuuhhh, je weet dat je dan ook voor iedere klant een SSL certificaat moet kopen?

SebastiaanStok
25/03/05, 12:49
Daar voor moeten ze betalen, maar ik wil ze de optie geven ook een gratis aanmaken via het contol panel.

Ps: waar kan je sertivicaten bestellen zonder credit card en dat soort ongein.
Dus gewoon via acsept giro.

Hoe doen julie dat, moet de klant zelf het sertivikaat bestellen of gebeurd dit via de host.

Kunnen julie ee voorbeeld geven, van hoe julie dat doen.

Japi
25/03/05, 12:51
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.

SebastiaanStok
25/03/05, 12:56
Een https, als die via apache loopt dan moet die aan aparte virtualhost hebben anders krijg je dat hij verkeerd word door gestuurd.

Lekker geregeld :)

Triloxigen
25/03/05, 13:05
HTTPS ervoor laten zetten is GEEN SSL Cert..
Je hebt wel een HTTPS verbinding nodig voor een SSL Cert. te installeren..

Waar aan te schaffen zonder CC? Check mijn sig ;)
De hoster of de klant kan dit bestellen, maakt in wezenlijke niet zoveel uit...
Zolang het domeinnaam en het IP maar bekend is...

Henky!
25/03/05, 13:17
Wat ook kan (toch?) is een SSL crtificaat op een IP adres en vervolgens daar de klanten ruimte aanbieden.

Triloxigen
25/03/05, 13:20
Origineel geplaatst door Henky!
Wat ook kan (toch?) is een SSL crtificaat op een IP adres en vervolgens daar de klanten ruimte aanbieden.

Ja, dat kan natuurlijk ook...

Maar dan kan de klant dat niet op eigen domeinnaam en dan is de controle op webspace en dataverkeer niet/moeilijk te controleren....

SebastiaanStok
25/03/05, 13:21
Dat snap ik even niet :huh:

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

SebastiaanStok
25/03/05, 13:37
Wat betekend Verzekerd tot € 10.000,00 ?

The MAzTER
25/03/05, 13:37
fout melding krijg je als het niet een echt cetificaat betreft. (dus een gekochte).

Waarom zou je dit uberhaupt op deze manier doen?

misschien dat 0,1% van je klanten ooit zo'n ding nodig heeft. Stel dat dus gewoon achteraf in. Zet alle klanten op 1 ip, mocht iemand echt ssl nodig hebben dan geef je hem een eigen ip.

SebastiaanStok
25/03/05, 13:40
Oke :)

Dat wilden ik dus weten ;)

Maar nu die vraag aan webzila, wat betekend dat ?
"Wat betekend Verzekerd tot € 10.000,00 ?"

Glenn
25/03/05, 13:43
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.

The MAzTER
25/03/05, 13:47
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.

versleuteling is wel 128bits enzo, maar je weet nooit 100% of je op het juiste server/adres bezig ben als je zo'n melding krijgt. Dus als iemand je bewust 'ergens' (je isp bijv. maar zal daar niet voorkomen lijk me) naar 12.34.56.78 door verwijst terwijl de echte site op 78.56.34.12 staat zal je zonder officiele cetificaat niet zien of dit gedaan word.

The MAzTER
25/03/05, 13:50
Origineel geplaatst door Rollerscapes
Wat betekend Verzekerd tot € 10.000,00 ?


kan je gewoon vinden met google


EBIZID SSL Certificate Warranty

What does the Warranty actually mean?

We believe it is important to protect the end user. If we were to mis-issue a certificate to a fraudulent site, and that fraudulent site has an SSL link with an end user and as a result of this the end user loses money. The end user had what they thought was a "trusted session". EBIZID should never have provided the fraudster with the ability to engineer this situation. Hence, we have taken out insurance to pay out money to the end user. How can we do this?

1. We value the end customer.
2. We believe the insurance provides greater peace of mind, allowing the merchant to sell more products.
3. We value our validation techniques, delivered through Idauthority, and our live human validation proceedures.

We pre-validate customers and provide validation that is far higher than the majority of other SSL providers. Some CA's have very weak validation Procedures, hence they decide NOT to offer insurance! Finally, it is worth pointing out that we offer high validation, but not at the compromise of speed. You can still obtain SSL within 24 hours. In addition, we now offer Accelerated Validation for a nominal fee, allowing our customers the option of having their SSL Certificates issued, Literally, within minutes.


edit: lol, Comodo gebruikt dezelfde tekst

SebastiaanStok
25/03/05, 13:55
Het is dus een verzekering die mij indekt als ik gebruik van maak en er froude mee word gepleegt, door onzorgvuldighijt van hun.

The MAzTER
25/03/05, 14:01
Origineel geplaatst door Rollerscapes
Het is dus een verzekering die mij indekt als ik gebruik van maak en er fraude mee word gepleegd, door onzorgvuldigheid van hun.

zo iets ja

Triloxigen
25/03/05, 14:34
Origineel geplaatst door The MAzTER


zo iets ja

Zie zijn sig.

Ik heb een ligte form van dyslektie, dus sorry voor mijn speling.

Maar met alleen HTTPS heb je geen beveilige verbinding (met de juiste server ;)).

De verzekering is nu duidelijk?

SebastiaanStok
25/03/05, 15:12
Min of meer die zin is niet echt duidelijk :)

Volgens mij bedoel je dit:
"Maar met alleen HTTPS, heb je geen beveilige verbinding (met de juiste server) dan geld dit niet."

Zo wie zo moet ik er al hebben voor het contoll panel.

Voor het admin gedeelte kan ik wel een Free aan maken :X

HBCS
25/03/05, 15:29
www.clesoft.nl bied ook certificaten aan

Glenn
25/03/05, 17:21
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?

The MAzTER
25/03/05, 17:28
ja

Glenn
25/03/05, 17:29
ok :)

japieo
25/03/05, 17:36
Origineel geplaatst door HBCS
www.clesoft.nl bied ook certificaten aan

www.perfectssl.com haal ik ze vandaan.

japieo
25/03/05, 17:37
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

SebastiaanStok
25/03/05, 18:54
Ik zij dus ZONDER credit card :)

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

Triloxigen
25/03/05, 20:05
Origineel geplaatst door Rollerscapes
Ik zij dus ZONDER credit card :)

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

WebZilla (http://www.webzilla.nl) is het ;)

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

MediaServe
25/03/05, 20:46
Ik had even zin om een lange reactie te posten :p

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 :huh:

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 :p Je kunt wel zelf een certificaat aanmaken (met bijvoorbeeld OpenSSL), dan heb je ook gewoon HTTP encryptie.

The MAzTER
25/03/05, 21:00
Origineel geplaatst door MediaCreations
Nee, want zonder certificaat werkt HTTPS niet :p 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.

Henky!
26/03/05, 00:26
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?

Triloxigen
26/03/05, 13:06
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?

SebastiaanStok
26/03/05, 14:45
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 :mad:

Triloxigen
27/03/05, 11:54
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.

SebastiaanStok
27/03/05, 12:44
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 :huh:

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

Dus dan moet dat toch ook kunenn voor SSL ?

PeterT
27/03/05, 13:53
Origineel geplaatst door Rollerscapes
Maar staat op port 443, waorm moet je dan toch een apart ip adres hebben :huh:

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..

PeterT
27/03/05, 13:54
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 :D:D)

Zou inderdaad zonde zijn :p

Triloxigen
27/03/05, 14:08
+ Dat een eigen IP meer zekerheid geeft op de betrouwbaarheid van de juiste locatie.

SebastiaanStok
29/03/05, 20:44
Het wil nog niet lukken :mad:

Dit is het hele ssl.conf bestand.
#
# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailing information about these
# directives see <URL:http://httpd.apache.org/docs-2.0/mod/mod_ssl.html>
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#

#
# 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.
#
# Note: This must come before the <IfDefine SSL> container to support
# starting without SSL on platforms with no /dev/random equivalent
# but a statically compiled-in mod_ssl.
#
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

<IfDefine SSL>

#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
# Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"
#
Listen 443

##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##

#
# 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 shmht:/data/apache2/logs/ssl_scache(512000)
#SSLSessionCache shmcb:/data/apache2/logs/ssl_scache(512000)
SSLSessionCache dbm:/data/apache2/logs/ssl_scache
SSLSessionCacheTimeout 300

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

##
## SSL Virtual Host Context
##

<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>

# Rollerscapes test...

<VirtualHost *:443>

# General setup for the virtual host
DocumentRoot "/data/apache2/htdocs/rollerscapes/public_html"
ServerName www.rollerscapes.net:443

# 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_files/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_files/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>

</IfDefine>


Als ik naar https://www.rollerscapes.net gaad krijg ik een 404 error.

De sertivicaten heb ik aan gemaakt via dit script.

http://nl3.php.net/manual/nl/function.openssl-csr-new.php

De uit voer van openssl_csr_export() heb ik opgeslagen als een csr-bestand en

openssl_pkey_export als key-bestand.

Als iemand weet warom dit niet wil werken hoor ik het graag.

Sander Aerts
01/04/05, 06:17
dude, het lijk me verstandig dat je jezelf eerst nog even wat dieper gaat verdiepen in Linux/Bsd or whatever voor je start met apache configs en ssl certificaten waar je zelf nog niet aan uit bent hoe het functioneert terwijl er genoeg mensen zijn op het forum die uitleg omtrend SSL certifacten gegeven hebben.

Dat wilde ik even kwijt :)

Tot sinas dagg..

SebastiaanStok
01/04/05, 10:31
Ik heb alles gedaan wat in de handlijng staat, voor zo ver ik tijd heb gehad om telezen.

En nog werkt het niet :huh:

Ik ben al genoeg thuis in linux hoor.
Ik kan zelf batch-script maken, en al die andere dingen die linux verijst.

Ik probeer enkel dat ding aan de praat te krijgen zo dat ik er mee kan gaan werken.

De instellingen zijn goed, maar warom hij het nu niet doet is mij nog niet bekend.

Ik snap dat hele principe niet van "Een IP-adres" je kan toch gewoon een domeinnaam gebruiken, dus warom heb je dan nog een IP-adres nodig ?

dreamhost_nl
01/04/05, 10:39
Origineel geplaatst door Rollerscapes
Ik snap dat hele principe niet van "Een IP-adres" je kan toch gewoon een domeinnaam gebruiken, dus warom heb je dan nog een IP-adres nodig ? [/B]

Voor het aanvragen van een SSL certificaat heb je een IP adres nodig. Per IP-adres kun je maar één certificaat aanvragen. Een SSL certificaat dien je te zien als een verzekering (per certificaat staat er een dekkingsbedrag voor). Er is altijd maar één verzekeringsnemer.

SebastiaanStok
01/04/05, 10:48
Maar als ik zelf een sertivicaat aanmaaak dan kan ik geen IP-adres op geven, komt dat omdat niet door een gerechtelijke instantie word uit gegeven ?

Maar zijn die insteling nu wel goed, wand je hebt toch ook een zo ganaamd openssl.cnf
Moet ik die niet er bij instellen of zo ?

Ik ga is kijken of ik op google een duidelijke handlijding kan vinden die helemaal uit legt hoe je dat nu moet instellen, maar als iemand direct een goed adres heb ik het graag.

SebastiaanStok
01/04/05, 11:36
Volgens mij ben ik er achter
:rolleyes:
Ik was vergeten dat apache de SSL aan moet zetten tijdens het starten :D

Maar geef nu start ik hem: service htppd startssl

En dan gaad hij naar een andere configuratie bestand :huh:

Edit: Hoe stel ik hem nu zo in dat hij tijdens het booten gelijk die parameter insteld ?