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>