Tryag File Manager

//proc/self/root/usr/share/doc/stunnel-4.15/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 extentions 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 extentions 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>