One Hat Cyber Team

Edit File: tworzenie_certyfikatow.html

<HTML>
<HEAD>
 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-2">
 <META NAME="Author" CONTENT="Adam Hernik">
 <TITLE>Wszystko co powiniene� wiedzie� o tworzeniu certyfikat�w ale nie chce Ci si� poszuka� w dokumentacji</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#CCCCCC" LINK="#0000EF" VLINK="#51188E" ALINK="#FF0000">

<CENTER>
<H1>
Wszystko co powiniene� wiedzie� o tworzeniu certyfikat�w
ale nie chce Ci si�</H1></CENTER>

<CENTER>
<H1>
poszuka� w dokumentacji.</H1></CENTER>
&nbsp;

Co powinno znajdowa� si� na Twoim dysku zamin zostaniesz
"Certificate Authorities".

Podstawowym oprogramowaniem jest oczywi�cie <A HREF="http://www.openssl.org">openssl</A>.
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 <A HREF="http://www.drh-consultancy.demon.co.uk">pcks12</A>
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�)
:
 <A HREF="#koniec openssl.cnf">je�li nie chce Ci si� tego
czyta� to skocz na koniec konfiga</A>

#
 # OpenSSL example configuration file.
 # This is mostly being used for generation of certificate requests.
 #
 &nbsp;
 RANDFILE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= $ENV::HOME/.rnd
 oid_file&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= $ENV::HOME/.oid
 oid_section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= new_oids
 &nbsp;
 [ new_oids ]
 &nbsp;
 # 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
 &nbsp;
 ####################################################################
 [ ca ]
 default_ca&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = CA_default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# The default ca section
 &nbsp;
 ####################################################################
 [ CA_default ]
 &nbsp;
 dir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= ./demoCA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where everything is kept
 certs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= $dir/certs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where the issued certs are kept
 crl_dir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/crl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where the issued crl are kept
 database&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/index.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# database index file.
 new_certs_dir&nbsp;&nbsp; = $dir/newcerts&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# default place for new certs.
 &nbsp;
 certificate&nbsp;&nbsp;&nbsp;&nbsp; = $dir/cacert.pem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# The CA certificate
 serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# The current serial number
 crl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= $dir/crl.pem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #
The current CRL
 private_key&nbsp;&nbsp;&nbsp;&nbsp; = $dir/private/cakey.pem# The
private key
 RANDFILE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/private/.rand&nbsp;&nbsp;&nbsp;
# private random number file
 &nbsp;
 x509_extensions = usr_cert&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# The extensions to add to the cert
 crl_extensions&nbsp; = crl_ext&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Extensions to add to CRL
 default_days&nbsp;&nbsp;&nbsp; = 365&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# how long to certify for
 default_crl_days= 30&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# how long before next CRL
 default_md&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = md5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# which md to use.
 preserve&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# keep passed DN ordering
 &nbsp;
 # 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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = policy_match
 # For the CA policy
 [ policy_match ]
 countryName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= match
 stateOrProvinceName&nbsp;&nbsp;&nbsp;&nbsp; = match
 organizationName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = match
 organizationalUnitName&nbsp; = optional
 commonName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= supplied
 emailAddress&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= optional
 &nbsp;
 # For the 'anything' policy
 # At this point in time, you must list all acceptable 'object'
 # types.
 [ policy_anything ]
 countryName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= optional
 stateOrProvinceName&nbsp;&nbsp;&nbsp;&nbsp; = optional
 localityName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= optional
 organizationName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = optional
 organizationalUnitName&nbsp; = optional
 commonName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= supplied
 emailAddress&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= optional
 &nbsp;
 ####################################################################
 <A NAME="req"></A>[ req ]
 default_bits&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 1024
 default_keyfile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= privkey.pem
 distinguished_name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = req_distinguished_name
 attributes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= req_attributes
 x509_extensions = v3_ca # The extensions to add to the self signed
cert
 &nbsp;
 [ req_distinguished_name ]
 countryName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Country Name (2 letter code)
 countryName_default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= PL
 countryName_min&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 2
 countryName_max&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 2
 &nbsp;
 stateOrProvinceName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= State i Prowincja
 stateOrProvinceName_default&nbsp;&nbsp;&nbsp;&nbsp; = State-Prowincja
domyslna
 localityName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Locality Name (eg, city)
 localityName_default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Lodz
 &nbsp;
 0.organizationName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Organization Name (eg, company)
 0.organizationName_default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Nawza
Organizacji
 &nbsp;
 # we can do this but it is not needed normally :-)
 #1.organizationName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Second Organization Name (eg, company)
 #1.organizationName_default&nbsp;&nbsp;&nbsp;&nbsp; = World Wide
Web Pty Ltd
 organizationalUnitName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Organizational Unit Name (eg, section)
 organizationalUnitName_default&nbsp; = Unit
name domyslny
 &nbsp;
 commonName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Common Name (eg, YOUR name)
 commonName_max&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 64
 &nbsp;
 emailAddress&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= Email Address
 emailAddress_max&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= 40
 &nbsp;
 # SET-ex3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= SET extension number 3
 &nbsp;
 [ req_attributes ]
 challengePassword&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= A challenge password
 challengePassword_min&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = 4
 challengePassword_max&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = 20
 &nbsp;
 unstructuredName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= An optional company name
 &nbsp;
 <A NAME="usr_cert"></A>[ usr_cert ]
 &nbsp;
 # These extensions are added when 'ca' signs a request.
 &nbsp;
 # 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.
 &nbsp;
 basicConstraints=CA:FALSE
 &nbsp;
 # Here are some examples of the usage of nsCertType. If it is omitted
 # the certificate can be used for anything *except* object signing.
 &nbsp;
 <A NAME="server"></A># This is OK for an SSL server.
 #nsCertType&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= server
 &nbsp;
 # For an object signing certificate this would be used.
 #nsCertType = objsign
 &nbsp;
 <A NAME="klient"></A># For normal client use this is typical
 nsCertType = client, email
 &nbsp;
 # This is typical also
 &nbsp;
 keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 &nbsp;
 nsComment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= "OpenSSL Generated Certificate"
 &nbsp;
 # PKIX recommendations
 subjectKeyIdentifier=hash
 authorityKeyIdentifier=keyid,issuer:always
 # Import the email address.
 &nbsp;
 subjectAltName=email:copy
 &nbsp;
 # Copy subject details
 &nbsp;
 issuerAltName=issuer:copy
 &nbsp;
 #nsCaRevocationUrl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= http://www.domain.dom/ca-crl.pem
 #nsBaseUrl
 #nsRevocationUrl
 #nsRenewalUrl
 #nsCaPolicyUrl
 #nsSslServerName
 &nbsp;
 [ v3_ca]
 &nbsp;
 # Extensions for a typical CA
 &nbsp;
 # It's a CA certificate
 basicConstraints = CA:true
 &nbsp;
 # PKIX recommendation.
 &nbsp;
 subjectKeyIdentifier=hash
 &nbsp;
 authorityKeyIdentifier=keyid:always,issuer:always
 &nbsp;
 # This is what PKIX recommends but some broken software chokes on
critical
 # extensions.
 #basicConstraints = critical,CA:true
 &nbsp;
 # Key usage: again this should really be critical.
 keyUsage = cRLSign, keyCertSign
 &nbsp;
 # Some might want this also
 nsCertType = sslCA, emailCA, objCA
 &nbsp;
 # Include email address in subject alt name: another PKIX recommendation
 subjectAltName=email:copy
 # Copy issuer details
 issuerAltName=issuer:copy
 &nbsp;
 # 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
 &nbsp;
 [ crl_ext ]
 &nbsp;
 # CRL extensions.
 # Only issuerAltName and authorityKeyIdentifier make any sense in
a CRL.

issuerAltName=issuer:copy
 authorityKeyIdentifier=keyid:always,issuer:always
 ################################################################################
 ########## koniec pliku openssl.cnf

<A NAME="koniec openssl.cnf"></A>Jak wida� zmiany s� praktycznie kosmetyczne.&nbsp;
Nale�y zwr�cic jedynie uwag� na opcj� <A HREF="#req">default_bits</A> 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 <A HREF="http://www.fortify.net/">Fortify</A>.
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'
 <A NAME="pem_pass"></A>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 <A HREF="#pem_pass">has�em</A> 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.
 &nbsp;

Tworzenie certyfikatu dla stunnela i innych serwer�w
 &nbsp;

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&nbsp; 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";
 &nbsp;

Natomiast w pliku /usr/local/ssl/lib/openssl_serv.cnf nalezy&nbsp;
w sekcji <A HREF="#usr_cert">usr_cert</A> "zahashowa�" linijk�
 <A HREF="#klient">nsCertType = client, email</A>&nbsp; oraz "odhashowa�"
linijk� <A HREF="#server">nsCertType&nbsp;&nbsp; = server</A> . 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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:PRINTABLE:'PL'
 stateOrProvinceName&nbsp;&nbsp; :PRINTABLE:'Kraina latajacych scyzorykow'
 localityName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:PRINTABLE:'Sielpia'
 organizationName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :PRINTABLE:'Bar Sloneczko'
 organizationalUnitName:PRINTABLE:'Kuflownia'
 commonName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:PRINTABLE:'adas.pl'
 emailAddress&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: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
 &nbsp;

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-----
 &nbsp;Tu s� magiczne dane
 -----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----
 &nbsp; 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.
 &nbsp;

Generowanie i importowanie certyfikat�w klienckich
do Netscape Communikatora.
 &nbsp;
 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.&nbsp; 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.&nbsp; 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:
 &nbsp;

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).&nbsp; 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.&nbsp;
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&nbsp; 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

####################################################################
 [ ca ]
 default_ca&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = CA_default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# The default ca section

####################################################################
 [ CA_default ]
 &nbsp;
 dir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= /tmp/ssl/demoCA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where everything is kept
 certs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
= $dir/certs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where the issued certs are kept
 crl_dir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/crl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# Where the issued crl are kept
 database&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = $dir/index.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# database index file.
 new_certs_dir&nbsp;&nbsp; = $dir/newcerts&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
# default place for new certs.
 &nbsp;
 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� &lt;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).
 &nbsp;

#!/usr/bin/perl
 #ca.pl

$config&nbsp;&nbsp; = "/tmp/ssl/openssl.cnf";
 $capath&nbsp;&nbsp; = "/usr/local/ssl/bin/openssl ca";
 $certpass = "tu_jest_haslo";
 $tempca&nbsp;&nbsp; = "/tmp/ssl/cli".rand 10000;
 $tempout&nbsp; = "/tmp/ssl/certtmp".rand 10000;
 $caout&nbsp;&nbsp;&nbsp; = "/tmp/ssl/certwynik.txt";
 $CAcert&nbsp;&nbsp; = "/tmp/ssl/demoCA/cacert.pem";
 ...
 &nbsp;

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.

<A NAME="usuwanie"></A>Jak wynika z powy�szego opisu bezpieczniejszym
i polecanym przeze mnie jest spos�b pierwszy. Jego powa�n� wad�
 jest&nbsp; fakt �e cz�owiek generuj�cy certyfikaty znajduje si� w posiadaniu
klucza prywatnego osoby wyst�puj�cej o
 certyfikat.&nbsp; Oczywi�cie uczciwy CA powinien
skasowa� go, zaraz po utworzeniu. W takim wypadku metoda pierwsza
 spe�nia&nbsp; wszelkie wymogi. Spos�b drugi pr�cz samych wad ma jedn�
acz ogromn� zalet�. Mianowicie klucz prywatny
 klienta&nbsp; 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.&nbsp;
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.
 &nbsp;

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&nbsp; 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&nbsp; nazwie mytrusted, poczym skopiowa� do niego
certyfikat klienta czyli jan.pem. <A HREF="#usuwanie">Uwaga: z pliku
jan.pem</A>
 <A HREF="#usuwanie">MUSISZ usun�� klucz prywatny</A> !!! Czyli&nbsp;
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.&nbsp;
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.
 &nbsp;
</BODY>
</HTML>