Co powinno znajdowaæ siê na Twoim dysku zamin zostaniesz "Certificate Authorities".
Podstawowym oprogramowaniem jest oczywi¶cie openssl.
W tym miejscu nale¿y zachowaæ czujno¶æ
bo openssl MUSI byæ co najmniej w wersji 0.9.2b dziêki czemu
ominie Ciê czê¶æ karko³omnych
operacji przy pomocy pcks12
ktory tak¿e musisz posiadaæ w swoich zasobach dyskowych.
Je¶li masz ju¿ zainstalowane powy¿sze oprogramowanie mo¿esz zacz±æ
tworzyæ certyfikaty.
Konfiguracja openssl.
Zak³adam ze openssl jest zainstalowany standardowo czyli w /usr/local/ssl.
Pierwszym krokiem jest
przejrzenie i "dokonfigurowanie" /usr/local/ssl/lib/openssl.cnf.
Mój domowy konfig wygl±da nastêpuj±co
(kolorem czerwonym zaznaczylem opcje które raczej powiniene¶ zmieniæ)
:
je¶li nie chce Ci siê tego
czytaæ to skocz na koniec konfiga
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
RANDFILE
= $ENV::HOME/.rnd
oid_file
= $ENV::HOME/.oid
oid_section
= new_oids
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
####################################################################
[ ca ]
default_ca = CA_default
# The default ca section
####################################################################
[ CA_default ]
dir
= ./demoCA
# Where everything is kept
certs
= $dir/certs
# Where the issued certs are kept
crl_dir = $dir/crl
# Where the issued crl are kept
database = $dir/index.txt
# database index file.
new_certs_dir = $dir/newcerts
# default place for new certs.
certificate = $dir/cacert.pem
# The CA certificate
serial = $dir/serial
# The current serial number
crl
= $dir/crl.pem #
The current CRL
private_key = $dir/private/cakey.pem# The
private key
RANDFILE = $dir/private/.rand
# private random number file
x509_extensions = usr_cert
# The extentions to add to the cert
crl_extensions = crl_ext
# Extensions to add to CRL
default_days = 365
# how long to certify for
default_crl_days= 30
# how long before next CRL
default_md = md5
# which md to use.
preserve = no
# keep passed DN ordering
# A few difference way of specifying how similar the request should
look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName
= match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName
= supplied
emailAddress
= optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName
= optional
stateOrProvinceName = optional
localityName
= optional
organizationName = optional
organizationalUnitName = optional
commonName
= supplied
emailAddress
= optional
####################################################################
[ req ]
default_bits
= 1024
default_keyfile
= privkey.pem
distinguished_name = req_distinguished_name
attributes
= req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed
cert
[ req_distinguished_name ]
countryName
= Country Name (2 letter code)
countryName_default
= PL
countryName_min
= 2
countryName_max
= 2
stateOrProvinceName
= State i Prowincja
stateOrProvinceName_default = State-Prowincja
domyslna
localityName
= Locality Name (eg, city)
localityName_default
= Lodz
0.organizationName
= Organization Name (eg, company)
0.organizationName_default = Nawza
Organizacji
# we can do this but it is not needed normally :-)
#1.organizationName
= Second Organization Name (eg, company)
#1.organizationName_default = World Wide
Web Pty Ltd
organizationalUnitName
= Organizational Unit Name (eg, section)
organizationalUnitName_default = Unit
name domyslny
commonName
= Common Name (eg, YOUR name)
commonName_max
= 64
emailAddress
= Email Address
emailAddress_max
= 40
# SET-ex3
= SET extension number 3
[ req_attributes ]
challengePassword
= A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName
= An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some
software
# requires this to avoid interpreting an end user certificate as
a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
#nsCertType
= server
# For an object signing certificate this would be used.
#nsCertType = objsign
# For normal client use this is typical
nsCertType = client, email
# This is typical also
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
nsComment
= "OpenSSL Generated Certificate"
# PKIX recommendations
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
# Import the email address.
subjectAltName=email:copy
# Copy subject details
issuerAltName=issuer:copy
#nsCaRevocationUrl
= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
[ v3_ca]
# Extensions for a typical CA
# It's a CA certificate
basicConstraints = CA:true
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
# This is what PKIX recommends but some broken software chokes on
critical
# extensions.
#basicConstraints = critical,CA:true
# Key usage: again this should really be critical.
keyUsage = cRLSign, keyCertSign
# Some might want this also
nsCertType = sslCA, emailCA, objCA
# Include email address in subject alt name: another PKIX recommendation
subjectAltName=email:copy
# Copy issuer details
issuerAltName=issuer:copy
# RAW DER hex encoding of an extension: beware experts only!
# 1.2.3.5=RAW:02:03
# You can even override a supported extension:
# basicConstraints= critical, RAW:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in
a CRL.
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
################################################################################
########## koniec pliku openssl.cnf
Jak widaæ zmiany s± praktycznie kosmetyczne.
Nale¿y zwrócic jedynie uwagê na opcjê default_bits w
sekcji req.
W momencie generowania certyfikatu CA powinna mieæ ona warto¶æ 1024
lub wiêcej, natomiast w trakcie tworzenia
certyfikatów klienckich winno mieæ siê na uwadze wredn± cechê produktów
M$ dostêpnych poza granicami USA.
Nie s± one w stanie zaimportowaæ kluczy maj±cych wiêcej ni¿ 512 bitów.
W takim przypadku default_bits nale¿y
zmniejszyæ do tej warto¶ci. Je¶li chodzi o Netscapa konieczno¶æ taka
nie wystêpuje, nawet gdy nie jest on
patchowany przy pomocy Fortify.
Jednak¿e klucz nie powinien byæ wiêkszy ni¿ 1024 bity.
Generowanie certyfikatu CA
Pierwszy± czynno¶ci± jak± nale¿y wykonaæ jest wygenerowanie certyfikatu
CA czyli czego¶ czym bêd±
podpiswane certyfikaty udostêpniane klientom. Uruchom rxvt lub co¶
innego i wykonaj polecenie:
adas:~# cd /usr/local/ssl/bin
adas:/usr/local/ssl/bin# ./CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Using configuration from /usr/local/ssl/lib/openssl.cnf
Generating a 1024 bit RSA private key
..+++++
....+++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
State i Prowincja [Kraina Bezrobotnych Szwaczek]:
Locality Name (eg, city) [Lodz]:
Organization Name (eg, company) [Instytut Badan Czarow i Magii]:
Organizational Unit Name (eg, section) [Komorka d/s Egzorcyzmow
i Opentan]:
Common Name (eg, YOUR name) []:Adam Hernik
Email Address []:adas@infocentrum.com
adas:/usr/local/ssl/bin#
Skrypt CA.pl uruchomiony poraz pierwszy tworzy w /usr/local/ssl/bin
katalog o nazwie demoCA w którym znajduje siê
wygenerowany przed chwil± certyfikat publiczny cacert.pem (do³±czany
pó¿niej do certyfikatów klienckich) oraz tajny
zabezpieczony has³em klucz cakey.pem
którym bêdziesz podpisywa³ certyfikaty wydawane u¿ytkownikom. Klucz i has³o
oczywi¶cie nale¿y dobrze chroniæ i najlepiej jest gdy znajduje siê
na serwerze tylko w momencie generowania certyfikatu.
Ponowne uruchomienie CA.pl z parametrem -newca niszczy to co pracowicie
stworzy³e¶ i generuje nowy klucz i certyfikat.
Tworzenie certyfikatu dla stunnela i innych serwerów
Zanim siê do tego zabierzesz powiniene¶ lekko zmodyfikowac skrypt CA.pl
oraz plik konfiguracyjny openssl.cnf.
Skopiuj je odpowiednio do plików /usr/local/ssl/bin/CAserv.pl
i /usr/local/ssl/lib/openssl_serv.cnf.
Generowane certyfikaty domy¶lnie zabezpieczone s± has³em, w takim przypadku
w momencie startu stunnela zawsze
bêdziesz pytany o haslo zabezpieczaj±ce, co skutecznie uniemo¿liwi
automatyczne uruchamianie programu w czasie
bootowania serwera, czy te¿ przy próbie wystartowania go przez
inetd. Nale¿y poprawiæ linie 40 i 41 skryptu
CAserv.pl z
linia 40:
$REQ="openssl req $SSLEAY_CONFIG";
na
$REQ="openssl req -nodes -config /usr/local/ssl/lib/openssl_serv.cnf";
linia 41:
$CA="openssl ca $SSLEAY_CONFIG";
na
$CA="openssl ca -config /usr/local/ssl/lib/openssl_serv.cnf";
Natomiast w pliku /usr/local/ssl/lib/openssl_serv.cnf nalezy
w sekcji usr_cert "zahashowaæ" linijkê
nsCertType = client, email oraz "odhashowaæ"
linijkê nsCertType = server . Je¶li tego
nie zrobisz klient nie bêdzie
poprawnie rozpoznawa³ typu certyfikatu. A teraz kolej na wygenerowanie
"requestu" posy³anego zazwyczaj do CA.
Bêd±c w katalogu /usr/local/ssl/bin wykonaj:
adas:/usr/local/ssl/bin# ./CAserv.pl -newreq
Using configuration from /usr/local/ssl/lib/openssl_serv.cnf
Generating a 1024 bit RSA private key
..............................+++++
.........+++++
writing new private key to 'newreq.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
State i Prowincja [Kraina Bezrobotnych Szwaczek]:Kraina latajacych
scyzorykow
Locality Name (eg, city) [Lodz]:Sielpia
Organization Name (eg, company) [Instytut Badan Czarow i Magii]:Bar
Sloneczko
Organizational Unit Name (eg, section) [Komorka d/s Egzorcyzmow
i Opentan]:Kuflownia
Common Name (eg, YOUR name) []:adas.pl
Email Address []:adas@adas.pl
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem
adas:/usr/local/ssl/bin#
Polem o którym warto wspomnieæ jest "Common Name" (zaznaczone na czerwono).
W trakcie generowania requestu
nale¿y w tym miejscu wpisaæ FQDN serwera na którym bêdzie on
u¿ywany. W przeciwnym wypadku w chwili
po³±czenia klient bêdzie twierdzi³, ¿e certyfikat jakim przedstawia
siê serwer nie nale¿y do niego. Unikniemy w ten
sposób niepotrzebnego klikania. Kolejn± czynno¶ci± jest podpisanie
wygenerowanego requestu. W katalogu
/usr/local/ssl/bin wykonaj polecenie:
adas:/usr/local/ssl/bin# ./CAserv.pl -sign
Using configuration from /usr/local/ssl/lib/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName
:PRINTABLE:'PL'
stateOrProvinceName :PRINTABLE:'Kraina latajacych scyzorykow'
localityName
:PRINTABLE:'Sielpia'
organizationName :PRINTABLE:'Bar Sloneczko'
organizationalUnitName:PRINTABLE:'Kuflownia'
commonName
:PRINTABLE:'adas.pl'
emailAddress
:IA5STRING:'adas@adas.pl'
Certificate is to be certified until Mar 26 21:06:13 2000 GMT (365
days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem
adas:/usr/local/ssl/bin#
W trakcie podpisywania bêdziesz pytany o has³o zabezpieczaj±ce klucz
prywatny CA (zaznaczone na zielono).
Po tej operacji powiniene¶ w katalogu /usr/local/ssl/bin otrzymaæ 2
pliki: newcert.pem oraz newreq.pem.
Zanim zaczniesz ich u¿ywaæ musisz wykonaæ jeszcze jedn± operacje, a
mianowicie z³orzyæ wszystko do kupy.
Wykonujesz: cat newcert.pem newreq.pem > httpds.pem a nastêpnie
poddajesz tak powsta³y certyfikat edycji.
Nale¿y z pliku httpds.pem nale¿y usun±æ wszystkie niepotrzebne informacje
tak by pozosta³ jedynie certyfikat oraz
klucz prywatny. Po tej operacji plik httpds.pem powinien wygl±daæ mniej
wiêcej tak:
issuer :/C=PL/ST=Kraina Bezrobotnych Szwaczek/L=Lodz/O=Instytut Badan
Czarow i Magii/OU=Komorka d/s Egzorcyzmow i opentan/CN=Adam Hernik/Email=adas@infocentrum.com
subject:/C=PL/ST=Kraina latajacych scyzorykow/L=Sielpia/O=Bar Sloneczko/OU=Kuflownia/CN=adas.pl/
Email=adas@adas.pl
-----BEGIN CERTIFICATE-----
Tu s± magiczne dane
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
I tu te¿ s± magiczne dane
-----END RSA PRIVATE KEY-----
Spreparowany w ten sposób plik umieszczamy w katalogu /usr/local/ssl/certs
i zajmujemy siê generowaniem dwu
certyfikatów klienckich.
Generowanie i importowanie certyfikatów klienckich
do Netscape Communikatora.
Generalnie s± dwie metody tworzenia i importowania certyfikatów klienckich
do Netscapa
Sposób pierwszy:
Przy pomocy komendy CA.pl -newreq wygeneruj request a nastêpnie
przy pomocy CA.pl -sign podpisz go.
Pytanie o challenge password zignoruj. Kolejn± czynno¶ci± jest
scalenie i podczyszczenie certyfikatu.
W przypadku certyfikatu klienta wa¿ne jest podanie prawid³owego
adresu email ! Bez tego nie bêdzie mo¿na
podpisywaæ i szyfrowaæ listów. Stwórz dwa certyfikaty. Bêd± one
potrzebne do wyja¶nienia dzia³ania opcji -v 3
programu stunnel. Zak³adam ¿e pierwszy certyfikat nale¿y do Jana Kowalskiego
jan@ibczim.pl zachowany w
pliku jan.pem a drugi do Genowefy Pigwy pigwa@scyzoryki.pl znajduj±cym
siê w pliku pigwa.pem. Przed
zaimportowaniem plików do Netscpea nale¿y przekonwertowaæ je z formatu
PEM do PCKS12. Wykonuje siê to
przy pomocy wspomnianego na pocz±tku programu pcks12. Aby przekonwertowaæ
certyfikat Jan Kowalskiego,
w katalogu w ktorym znajduje siê plik jan.pem wykonaj:
pkcs12 -export -name "Jan Kowalski jan@ibczim.pl" -in jan.pem -out jan.p12 -certfile /usr/local/ssl/bin/demoCA/cacert.pem
(jest to jedna linia !!!)
w wyniku czego powstanie plik jan.p12 który mo¿na zaimportowaæ do Netscapea.
Bardzo wa¿n± opcj± jest
-certfile /usr/local/ssl/bin/demoCA/cacert.pem. Bez niej
nie bêdzie mo¿na w prawid³owy sposób podpisywaæ listów.
Prze³±cznik -certfile powoduje do³±czenie publicznego certyfikatu CA
do certyfikatu klienta dziêki czemu Netscape
jest wstanie "wyekstrachowaæ" certyfikat CA i dodaæ go do wewnêtrznej
bazy CA. Wykonaj powy¿sz± operacjê tak¿e
dla pigwy. Samo zaimportowanie certyfikatu jest bardzo proste wykonuje
siê to klikaj±c w Netscape na
Security-> Yours -> Import a Certificate
Po zaimportowaniu nale¿y w Security -> Signers zaznaczyæ nasz
CA certyfikat a nastêpnie klikn±æ na przycisku Edit
oraz "zaczekowaæ" opcje:
Accept this Certificate Authority for Certifying network sites
Accept this Certificate Authority for Certifying e-mail users
Od tej pory nasz certyfikat bêdzie traktowany na równi z innymi, komercyjnymi.
Sposób drugi:
Polega on na wygenerowaniu i imporcie certyfikatu poprzez strone www.
Wraz z stunnelem dostarczane s±
przk³adowe strony (dwie) i skrypty (dwa). Skrypty nale¿y raczej
traktowaæ jako wzorzec i ka¿dy powinien napisaæ
swoje, bardziej bezpieczne. Pierwszym krokiem jest import certyfikatu
CA. U¿ywa siê do tego strony importCA.html
oraz skryptu importCA.sh. Sam skrypt wygl±da tak:
#!/bin/bash
echo "Content-type: application/x-x509-ca-cert"
echo
cat /var/lib/httpds/cgi-bin/cacert.pem
cacert.pem jest to oczywi¶cie certyfikat publiczny CA znajduj±cy siê
w katalogu /usr/local/ssl/bin/demoCA
który nale¿y przekopiowaæ do katalogu cgi-bin serwera httpd oraz nadaæ
mu odpowiednie prawa dostêpu.
Po zaimportowaniu certyfikatu CA nale¿y w Security->Signers zaznaczyæ
do jakich celów bêdziemy uznawli
go za wiarygodny. Do generowania certyfikatu klienta wykorzystamy pozosta³±
strone i skrypt. Zanim do tego dojdzie
nale¿y "dokonfigurowaæ" skrypt i stworzyæ potrzebne katalogi.
W /tmp (lub w innym miejscu) nalezy stworzyæ
katalog ssl a nastêpnie przekopiowaæ do niego katalog /usr/local/bin/demoCA
oraz plik openssl.cnf.
Jako ¿e skrypty domy¶lnie uruchamiane s± z prawami u¿ytkownika nobody
nale¿y uczyniæ go wla¶cicielem
katalogu /tmp/ssl i ca³ej jego zawarto¶ci. Kolejn± czynno¶ci± jest
wygenerowanie pliku .rnd. W Linuxie robimy to
tak:
cat /dev/random > /tmp/ssl/.rnd
czekamy chwilkê tak by plik .rnd mia³ wielko¶æ oko³o 1024 B po czym
w³a¶cicielem pliku robimy u¿ytkownika nobody.
Teraz trzeba przekonfigurowaæ plik /tmp/ssl/openssl.cnf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
RANDFILE
= /tmp/ssl/.rnd
#oid_file
= /tmp/ssl/.oid
oid_section
= new_oids
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
####################################################################
[ ca ]
default_ca = CA_default
# The default ca section
####################################################################
[ CA_default ]
dir
= /tmp/ssl/demoCA
# Where everything is kept
certs
= $dir/certs
# Where the issued certs are kept
crl_dir = $dir/crl
# Where the issued crl are kept
database = $dir/index.txt
# database index file.
new_certs_dir = $dir/newcerts
# default place for new certs.
Nale¿y zmieniæ opcje zaznaczone na czerwono. Ostatni± czynno¶ci± jest
sprawdzenie i ewentualne poprawienie
strony ca.html i skryptu ca.pl. W pliku ca.html nalezy wpisaæ poprawn±
nazwê serwera na którym znajduje siê
skrypt ca.pl czyli linijkê <FORM ACTION="http://localhost/cgi-bin/ca.pl"
METHOD=POST>. W ca.pl
nale¿y skontrolowaæ poprawno¶æ podanych ¶cie¿ek oraz wpisaæ has³o jakim
zabezpieczony jest klucz prywatny CA
(zmienna $certpass zaznaczona na czerwono).
#!/usr/bin/perl
#ca.pl
$config = "/tmp/ssl/openssl.cnf";
$capath = "/usr/local/ssl/bin/openssl ca";
$certpass = "tu_jest_haslo";
$tempca = "/tmp/ssl/cli".rand 10000;
$tempout = "/tmp/ssl/certtmp".rand 10000;
$caout = "/tmp/ssl/certwynik.txt";
$CAcert = "/tmp/ssl/demoCA/cacert.pem";
...
Po umieszczeniu tak przygotowanych stron i skryptów na serwerze bêdzie mo¿na generowaæ certyfikaty dla klientów.
Wady i zalety obydwu sposobów generowania i instalowania certyfikatów.
Jak wynika z powy¿szego opisu bezpieczniejszym
i polecanym przeze mnie jest sposób pierwszy. Jego powa¿n± wad±
jest fakt ¿e cz³owiek generuj±cy certyfikaty znajduje siê w posiadaniu
klucza prywatnego osoby wystêpuj±cej o
certyfikat. Oczywi¶cie uczciwy CA powinien
skasowaæ go, zaraz po utworzeniu. W takim wypadku metoda pierwsza
spe³nia wszelkie wymogi. Sposób drugi prócz samych wad ma jedn±
acz ogromn± zaletê. Mianowicie klucz prywatny
klienta nigdy nie opuszcza jego komputera. Do wad mo¿na zaliczyæ
fakt ¿e has³o zabezpieczaj±ce klucz prywatny CA
znajduje siê na serwerze i to w dodatku w ¿aden sposób nie chronione.
Kolejn± wad± jest generowanie kompletnych
certyfikatów przez strone www, co mo¿e groziæ wykradzeniem klucza prywatnego.
Rozwi±zaniem mo¿e byæ sk³adowanie
requestów w bazie danych a nastpnie rêczna ich obróbka przez administratora.
Reasumuj±c, sposób drugi nale¿y
potraktowaæ jako demonstracje metody któr± mo¿na przeæwiczyæ przed
napisaniem porz±dnych skryptów.
Tajemniczy prze³±cznik -v 3 w stunnelu
Stunnel posiada trzy tryby weryfikacji klienta.
Pierwszy opcja -v 1 oznacza ¿e nale¿y spróbowaæ
zweryfikowaæ osobê nawi±zuj±c± po³±czenie czyli uzyskaæ jej
ceryfikat. Je¶li operacja ta siê nie powiedzie, mimo wszystko dostêp
do serwera bêdzie zapewniony.
Prze³±cznik -v 2 nakazuje stunnelowi zweryfikowaæ
klienta. Je¶li u¿ytkownik nie posiada certyfikatu lub certyfikat
jest niewa¿ny, niew³a¶ciwy czy te¿ nie posiadamy certyfikatu CA którym
podpisany jest certyfikat klienta
(straszny jest ten jêzyk polski) nawi±zanie po³±czenia
z serwerem bêdzie niemo¿liwe. I wreszcie opcja -v 3
nakazuj±ca
stunnelowi zweryfikowaæ klienta a tak¿e poszukaæ jego certyfikatu w
naszej lokalnej bazie.
Dzieki opcji -v 3 mo¿emy stworzyæ bardzo selektywny dostêp do us³ug
oferowanych przez serwer, unikaj±c generowania du¿ych ilo¶ci certyfikatów.
Uwaga ogólna: do poprawnej weryfikacji klienta KONIECZNE
jest posiadanie certyfikatu CA którym podpisany jest sprawdzany certyfikat.
Bez tego stunnel nie jest wstanie przeprowadziæ poprawnej autoryzacji klienta.
Próba taka koñczy siê b³êdami "VERIFY ERROR: self signed certificate
for ....." oraz "SSL_accept: error:140890B1:SSL routines: SSL3_GET_CLIENT_CERTIFICATE:no
certificate returned". A teraz przyk³ad praktyczny: chcemy aby do https
bêd±cym na porcie 444 mia³y dostêp wszystkie osoby maj±ce certyfikaty
natomiast
do do https na porcie 445 dostêp mia³ tylko Jan Kowalski. Pierwsz±
czynno¶ci± jak± nale¿y wykonaæ jest skopiowanie
certyfikatu CA do katalogu /usr/local/ssl/certs (default cert
area), nastêpnie w tym katalogu nale¿y utworzyæ
podkatalog o nazwie mytrusted, poczym skopiowaæ do niego
certyfikat klienta czyli jan.pem. Uwaga: z pliku
jan.pem
MUSISZ usun±æ klucz prywatny !!! Czyli
to co siê znajduje miêdzy
-----BEGIN RSA PRIVATE KEY-----
.......
-----END RSA PRIVATE KEY-----
³±cznie z powy¿szymi liniami. Nastêpnie w katalogach /usr/local/ssl/certs
i /usr/local/ssl/certs/mytrusted nale¿y
wykonaæ polecenie
/usr/local/ssl/bin/c_rehash ./
Teraz kolej na uruchomienie stunnela:
stunnel -d 444 -r 80 -v 2
oraz
stunnel -d 445 -r 80 -v 3
Netscapem nale¿y po³±czyæ sie z https://localhost:444/ a po pytaniu
o certyfikat przedstawiæ certyfikat nale¿±cy
do pigwy. Dostêp do serwera bêdzie zapewniony. Czynno¶c tê nale¿y powtórzyæ
przedstawiaj±c siê za drugim razem
certyfikatem Jana Kowalskiego. Po³±czenie tak¿e bêdzie zrealizowane.
W przypadku https://localhost:445/ wej¶cie
na serwer bêdzie zapewnione tylko po wylegitymowaniu siê certyfikatem
Jana Kowalskiego. Po kazdej zmianie w
katalogu /usr/local/ssl/certs/mytrusted nale¿y wykonaæ komendê c_rehash
./ i zrestartowaæ stunnela.