Bezpieczeństwo systemów komputerowych, r.

Transkrypt

1 Bezpieczeństwo systemów komputerowych, r. Zadanie1 a) W pierwszym kroku proszę przeanalizować plik konfiguracji dla CA b) Przygotować strukturę katalogów określoną w pliku konfiguracyjnym CA c) Utworzyć CA, tworząc klucz prywatny, publiczny oraz certyfikat OpenSSL znajduje się w katalogu /etc/ssl/ Plik konfiguracyjny OpenSSL nazywa się openssl.cnf, i znajduje się w katalogu: /etc/ssl/openssl.cnf Tworzenie Urzędu Certyfikacyjnego składa się z dwóch czynności: 1) Wygenerowania klucza prywatnego Urzędu Certyfikacji 2) Wygenerowanie certyfikatu Urzędu Certyfikacji (jest to klucz publiczny) My jednak podejdziemy do tego inaczej nie będziemy korzystać z pliku openssl.cnf, stworzymy nasz własny plik konfiguracyjny, a potem to już łatwo stworzymy nasze CA :) Na początku trochę przypomnienia z ćwiczeń: (Opcje konfiguracji dla pliku konfiguracyjnego oraz ich krótkie omówienie): HOME =. [ca] - sekcja konfiguracji CA default ca = CA default [CA default] dir =./CA crl_dir = $dir/crl database = $dir/index.txt new_certs dir = $dir/newcerts certificate = $dir/cert.pem serial = $dir/serial.txt crl = $dir/crl.pem private_key = $dir/private/pk.pem RANDFILE = $dir/rand # katalog domowy dla OpenSSL'a # Domyślny CA (W pliku mogą być konfiguracje # dla różnych CA) # Katalog z danymi # Katalog dla list CRL # Plik zawierający listę wydanych certyfikatów # Katalog dla nowowydanych certyfikatów # Plik w którym jest certyfikat CA # Aktualny numer seryjny wydawanego # certyfikatu # Aktualna lista CRL # Klucz prywatny CA # Plik dla generatora liczb pseudolosowych # Dane dotyczące wydawanych certyfikatów default_days = 365 # Ważność certyfikatu

2 default_crl_days= 30 default_md = md5 preserve = no policy = policy_1 # Czas pomiędzy kolejnymi listami CRL # Używana funkcji skrótu # zachowywanie kolejności wg. DN (nazwy # wyróżniającej) # Dane dotyczące wymaganych pól dla zgłoszeń #Dane dotyczące zgłoszęń certyfikacji [req] default_bits = 1024 # Długość bitów klucza default_keyfile = PK.pem # Nazwa pliku z kluczem prompt = no # Dane zgłoszeniowe wpisywane z lini komend string_mask = nombstr # Format wprowadzanych danych distinguished_name = req_distinguished_name # nazwa sekcji dotyczącej danych w # zgłoszeniu certyfikatu x509_extensions = req_x509_ext # nazwa sekcji dla autocertyfikatów # (samopodpisanych) [req_x509_ext] subjectkeyidentifier = hash authoritykeyidentifier = keyid:always,issuer:always basicconstraints = CA:true # Bedzie można podpisywać inne certyfikaty nscerttype = sslca keyusage = crlsign,keycertsign # Użycie klucza: podpisywanie list CRL, # podpisywanie innych certyfikatów nscomment = Lab - Audyt IT # Komentarz dodawany do podpisywanego # certyfikatu #Dane zawarte w zgłoszeniach do certyfikacji [req distinguished name] countryname = PL localityname = Lublin organizationname = UMCS organizationalunitname = II commonname = Institute of Computer Science Certificate Autority commonname max = 64 address = ccadmin@umcs.lublin.pl [policy_1] countryname = supplied localityname = optional organizationname = supplied organizationalunitname = optional commonname = supplied # wymagane # opcjonalne

3 surname = supplied address = supplied [crl ext] authoritykeyidentifier = keyid:always,issuer:always #opcje dla CRLi 1. Tworzymy osobny katalog, w którym będziemy przechowywać pliki naszego CA, niech nazywa się np. myownca :D mkdir myownca 2. Tworzymy nasz plik konfiguracyjny, niech nazywa się on CA.config. w pliku konfiguracyjnym możliwe jest zdefiniowanie parametrów dla kilku centrów certyfikacji, właściwości zgłoszeń certyfikacyjnych itp. touch CA.config

4 3. Plik CA.config będzie zawierał informacje konfigurujące nasze CA. Jednakże, przed jego utworzeniem, należy stworzyć kilka katalogów i plików, które będą niezbędne przy generowaniu CA. Etap ten często nazywany jest przygotowaniem środowiska. Omówienie etapu tworzenia środowiska: Katalogi : private, crl, newcerts Pliki : index.txt, serial Katalog private tam znajdować się będzie kopia klucza prywatnego CA. Klucz ten musi być szczególnie dobrze chroniony przed nieautoryzowanym dostępem, dlatego należy zablokować innym użytkownikom dostęp do tego katalogu. W rzeczywistych, krytycznych zastosowaniach klucz prywatny centrum nie powinien być w ogóle przechowywany w podłączonym do sieci systemie dobrym rozwiązaniem jest składowanie go sprzętowo, Katalog newcerts katalog dla nowowydanych certyfikatów, Katalog crl katalog dla list CRL, Plik index.txt - plik zawiera informacje o wszystkich certyfikatach, jakie zostały wydane przez nasze CA. W tym momencie żadnego certyfikatu jeszcze

5 nie wydano. Jeśli pliku nie będzie, OpenSSL zakończy swe działanie błędem należy zatem przygotować plik pusty, Plik serial - przechowuje numer seryjny, jaki posłuży do oznaczenia kolejnego wydanego certyfikatu. Numer jest unikalny w ramach CA. OpenSSL wymaga, aby ten plik istniał, a ponadto, aby zawierał co najmniej dwa znaki dlatego plik należy zainicjalizować łańcuchem 01. Zawartość pliku traktowana jest jako liczba w formacie heksadecymalnym, Właściwy etap przygotowania środowiska: Tworzymy 3 katalogi : newcerts, private, crl : mkdir newcerts private crl

6 Dla katalogu private ustawiamy prawa dostępu tak, aby tylko użytkownik root mógł do niego wejść była mowa o tym wcześniej, ponieważ w tym katalogu będziemy przechowywać klucz prywatny naszego CA, logicznym jest, że do tego katalogu prawo dostępu powinien mieć tylko użytkownik root: chmod 700 private Jeśli zwykły użytkownik będzie chciał wejść do katalogu private, zobaczy taki komunikat, jak na screenie poniżej, i do katalogu nie wejdzie. Wiadomo, nie jest to idealne zabezpieczenie najlepiej byłoby przechowywać klucz prywatny naszego CA np. na płycie CD lub Pendrivie.

7 Wchodzimy do katalogu private na razie jest on pusty: cd private

8 Będąc w katalogu private, tworzymy w nim ukryty plik o nazwie rand (czyli w rzeczywistości.rand) będzie to plik dla generatora liczb pseudolosowych: touch.rand Przechodzimy poziom wyżej (cd..) do katalogu naszego CA (/home/kasiula/myownca) i tworzymy 2 pliki: index.txt oraz serial touch index.txt serial

9 Plik index.txt powinien być plikiem pustym, ponieważ będzie on naszą bazą danych przechowującą informacje o o wystawionych certyfikatach Plik serial to plik pomocniczy, z bieżącym numerem inkrementowany po każdym wystawieniu certyfikatu, przechowuje aktualny numer seryjny wydawanego certyfikatu - dlatego też, do pliku należy wpisać wartość 01 - pierwszy wydany przez nas certyfikat będzie miał wtedy numer seryjny równy 01, drugi 02, i tak dalej

10 Wpisujemy numer 01 do pliku serial, np. tak:) : echo '01' > serial Czas teraz na konfigurację pliku CA.config. Edytujemy plik CA.config, na początku będzie on oczywiście pusty : mcedit CA.config Omówienie budowy pliku CA.config: Pierwsze 3 linie naszego pliku to komentarz. Komentarz, jak widzimy, rozpoczyna się od znaku #. Możemy tutaj wpisać swoje imię i nazwisko, na dowód tego, że to my go napisaliśmy. Oczywiście komentarz jest opcjonalny, a jego treść dowolna. W zasadzie nie musimy tego pisać. No ale niech będzie : # # Katarzyna Mazur CA configuration file #

11 HOME =. - wskazuje nam domowy katalog dla OpenSSL'a U nas będzie to, jak widać, katalog bieżący (kropka -. oznacza katalog bieżący, czyli u mnie /home/kasiula/myownca) [ ca ] jest to specjalna etykieta, informująca nas o tym, że po niej następuje podanie ustawień dla naszego CA, rzeczywiście, poniżej tej etykiety ustawiamy, które z zawartych w pliku konfiguracyjnym ma być naszym domyślnym CA w rzeczywistości, jest to polecenie ca narzędzia linii komend OpenSSL plik konfiguracyjny OpenSSL zawiera sekcje nazwane analogicznie do poleceń korzystających z tego pliku. Jest więc konieczne dodanie sekcji [ ca ] W sekcji [ ca ] musi znaleźć się klucz o nazwie default_ca i wartości określającej nazwę kolejnej sekcji definiującej dalsze parametry CA, np. nasze_ca default_ca = CA_default default_ca klucz, określający domyślny dla tego pliku konfiguracyjnego CA, CA_default wartość dla tego klucza, czyli po prostu nazwa sekcji, określającej ustawienia dla domyślnego CA [ CA_default ] - jest to sekcja konfiguracji naszego własnego (w tym przypadku także i domyślnego CA w sekcji [ CA_default ] definiujemy klucze i przypisujemy im wartości klucze to np. dir, database, czy serial wartości to np. /home/kasiula/myownca (dla klucza dir) czy $dir/index.txt (dla klucza database) Pierwszy pęk kluczy wygląda tak: dir = /home/kasiula/myownca - katalog, w którym trzymamy wszystkie pliki naszego CA crl_dir = $dir/crl katalog dla list CRL database = $dir/index.txt baza danych naszego CA, jest to plik zawierający listę wydanych przez nasze CA certyfikatów new_certs_dir = $dir/newcerts katalog dla nowowydanych certyfikatów certificate = $dir/cacert.pem plik, w którym będzie zapisany certyfikat naszego CA, czyli w rzeczywistości klucz publiczny naszego CA serial = $dir/serial aktualny numer seryjny wydawanego certyfikatu, wartość numeru, który jest wpisany do pliku, jest inkrementowana (zwiększana o 1) po każdym wystawieniu certyfikatu crl = $dir/crl.pem aktualna lista CRL private_key = $dir/private/privkey.pem klucz prywatny CA, zostanie wygenerowany po wydaniu polecenia tworzącego CA, samopodpisany certyfikat

12 naszego CA RANDFILE = $dir/private/.rand plik dla generatora liczb pseudolosowych (może być pusty, ale lepiej wpisać do niego jakieś śmieci) Ok, ale co to właściwie jest CRL? Certificate Revocation List = CRL = lista unieważnionych certyfikatów Kwestia list CRL jest sama w sobie dość złożona, należy jednak powiedzieć, że listy służą do poinformowania użytkowników danej PKI, które z certyfikatów nie mogą być uznane dłużej za zaufane, np. z powodu kompromitacji klucza prywatnego Pęk kluczy zawierający dane dotyczące wydawanych certyfikatów: default_days = 365 ważność certyfikatu, domyślny okres ważności certyfikatu, klucz default_days określa domyślny czas ważności certyfikatu (w dniach), w tym wypadku jeden rok default_crl_days = 30 - domyślny okres pomiędzy kolejnymi listami CRL, klucz default_crl_days określa (w dniach) okres pomiędzy publikacją kolejnych wersji

13 list CRL. Najczęstszą praktyką jest aktualizacja list co tydzień. Jeżeli zasadna jest publikacja list więcej niż raz dziennie, można wymiennie użyć klucza default_crl_hours. default_md = md5 - default_md wskazuje, jaka funkcja skrótu będzie użyta przy podpisywaniu certyfikatów i list CRL. Obecnie powinno unikać się stosowania algorytmów MD5 oraz SHA1 preserve = no - zachowywanie kolejności wg. DN (nazwy wyróżniającej) policy = mypolicy - określenie sekcji dotyczącej właściwości zgłoszeń certyfikacyjnych, (polityka dla zgłoszeń certyfikacyjnych), klucz policy zawiera nazwę sekcji, która określać będzie sposób analizy nazwy wyróżniającej w żądaniu certyfikatu np. mypolicy. Wskazywana sekcja zawiera grupę kluczy, których nazwy odpowiadają polom zawartym w definicji nazwy wyróżniającej. Klucze te mogą przyjmować różne wartości: match oznacza, że wartość pola w żądaniu certyfikatu musi być identyczna jak w nazwie wyróżniającej głównego certyfikatu CA. Dla przykładu, jeżeli zakłada się, że wydawać będziemy certyfikaty jedynie dla wskazanej jednostki organizacyjnej, w ramach której działa CA i żądający certyfikatów znają odpowiednią postać nazwy, można podać wartość match dla klucza organizationname. Pola wymagane i identyczne co do treści (ich zmiana podczas generowania zgłoszenia certyfikacyjnego spowoduje uniemożliwienie wystawienia certyfikatu) supplied pole musi występować w żądaniu certyfikatu, ale jego wartość nie jest w żaden szczególny sposób ograniczona, optional pole może, ale nie musi, występować w żądaniu certyfikatu. Przykładem pola może być nazwa jednostki organizacyjnej w ramach obsługiwanej infrastruktury (być może niektóre certyfikaty trudno będzie przyporządkować określonej jednostce) czy adres owy.

14 [ req ] - sekcja dotycząca zgłoszeń certyfikacji, odpowiada za stworzenie głównego certyfikatu, samopodpisanego, służącego do podpisywania innych certyfikatów i list CRL, właściwie jest to polecenie openssl req. Nasze CA potrzebuje certyfikatu, którym będzie podpisywać inne, wystawione przez siebie, certyfikaty (oraz listy CRL). Można do tego u żyć dowolnego certyfikatu skonfigurowanego do tych właśnie czynności. Na potrzeby prywatnego CA możemy sami taki certyfikat wygenerować. Jego wydanie rozpoczyna się od przygotowania żądania certyfikatu przy pomocy polecenia openssl req. Stąd wniosek, że należy utworzyć w naszym pliku konfiguracyjnym dodatkową sekcję o tej właśnie nazwie default_bits = ustanawia długość klucza szyfrującego dla certyfikatu. Domyślna wartość wynosi 512 i nie jest obecnie uznawana za bezpieczną. Rekomenduje się stosowanie klucza o długości przynajmniej 1024, a najlepiej 2048 bitów. Wartości te niosą za sobą daleko wyższy poziom bezpieczeństwa, a nie powodują znaczących narzutów obliczeniowych, default_keyfile = privkey.pem - określa ścieżkę, pod którą zapisany będzie utworzony klucz prywatny. Należy zwrócić uwagę na fakt, że jest to ta sama ścieżka, jaka występuje w konfiguracji całego CA. Niestety, nie można wykorzystać makra zdefiniowanego w sekcji [ ca ], ponieważ jest ono lokalne dla

15 tamtej sekcji. Można redefiniować makro albo użyć jednego, globalnego dla całego pliku konfiguracyjnego distinguished_name = req_distinguished_name sekcja odpowiedzialna za nazwę wyróżniającą CA, jest to nazwa sekcji dotyczącej danych w zgłoszeniu certyfikatu. Podmiot występujący o certyfikat identyfikowany jest przez nazwę wyróżniającą (distinguished name DN). Składa się ona z pewnej liczby pól, wśród których możemy wyróżnić obowiązkowe i opcjonalne. To, jak będziemy traktować poszczególne pola, konfigurujemy ustalając politykę naszego centrum Najczęściej spotykane pola wymieniono poniżej: - Country (C) państwo, - State or Province (ST) stan, prowincja itp. (województwo, region), - Locality (L) położenie (np. -iasto), - Organization (O) nazwa firmy lub organizacji, - Organization Unit (OU) nazwa jednostki podrzędnej w ramach firmy lub organizacji, np. pojedynczy dział lub zespół, - Common Name (CN) nazwa podmiotu ubiegającego się o certyfikat (np. imię i nazwisko pracownika, pełna kwalifikowana nazwa domenowa serwera itp.). Dla dalszego zobrazowania przykładu przyjmiemy, że nasze CA pracuje w Poznaniu, w firmie Nasza Firma. Przykładowa nazwa wyróżniająca mogłaby mieć następującą postać: /C=PL/ST=Wielkopolska/L=Poznan/O=Nasza Firma/OU=Wydzial Certyfikatow/CN=Nasze CA/ Address=nasze_ca@naszafirma.com.pl string_mask = nombstr - Format wprowadzanych danych x509_extensions = req_x509_ext - nazwa sekcji dla autocertyfikatów (samopodpisanych)

16 [ req_x509_ext ] - nazwa sekcji dla autocertyfikatów (samopodpisanych) basicconstraints = CA:true - Będzie można podpisywać inne certyfikaty, Wartość klucza, CA:false, oznacza, że nie będą one mogły być wykorzystane do podpisywania innych certyfikatów. Innymi słowy, żaden z wydanych certyfikatów nie będzie nadawał się do prowadzenia podrzędnego centrum certyfikacyjnego certyfikowany podmiot jest użytkownikiem końcowym. nscerttype = sslca keyusage = crlsign,keycertsign - Użycie klucza: podpisywanie list CRL, podpisywanie innych certyfikatów nscomment = Lab - Audyt IT - Komentarz dodawanydo podpisywanego certyfikatu subjectkeyidentifier = hash authoritykeyidentifier = keyid:always,issuer:always

17 [ req_distinguished_name ] - Dane zawarte w zgłoszeniach do certyfikacji, będziemy je musieli podać, jeśli będziemy chcieli otrzymać certyfikat od CA. Pola, które musimy wypełnić, to nazwy bez prefixu _default jeśli nic nie wpiszemy, jako domyślne wartości dla tych pól zostaną wpisane wartości zmiennych z prefiksem _default w nazwie czyli np. dla pola countryname domyślną wartością będzie PL. To CA nam, jako jednostce podrzednej będzie wydawało certyfikaty. Zaufana strona trzecia urząd certyfikacyjny (certification authority, CA) potrafi powiązać konkretny klucz publiczny z unikalną nazwą podmiotu, określaną mianem nazwy wyróżniającej (distinguished name, DN). Czyni to przy pomocy certyfikatu podpisanego przy pomocy swojego klucza prywatnego. Klucz publiczny wystawcy certyfikatu jest oczywiście jawny i każdy, kto chce przy jego pomocy sprawdzić tożsamość podmiotu, na który wystawiono certyfikat, powinien klucz ten przedtem pobrać lub co najmniej zweryfikować przy pomocy zaufanego medium (napastnik może próbowaćpodstawić swoją parę kluczy publiczny prywatny jako klucze strony trzeciej). countryname = Nazwa kraju countryname_default = PL

18 localityname = Lokalizacja localityname_default = Lublin organizationname = Nazwa organizacji organizationname_default = UMCS organizationalunitname = Nazwa jednostki organizationalunitname_default = II commonname = Nazwa wydzialu commonname_default = Institute of Computer Science commonname_max = 64 address = ccadmin@umcs.lublin.pl [ mypolicy ] - sekcja odpowiezialna za politykę wydawania certyfikatów przez CA. Jest to sekcja, która określać będzie sposób analizy nazwy wyróżniającej w żądaniu certyfikatu countryname = supplied - pole oznaczone jako supplied musi występować w żądaniu certyfikatu, ale jego wartość nie jest w żaden szczególny sposób ograniczona localityname = optional pole oznaczone jako optional musi występować w

19 żądaniu certyfikatu, ale jego wartośćnie jest w żaden szczególny sposób ograniczona organizationname = supplied organizationalunitname = optional commonname = supplied address = supplied [ crl_ext ] authoritykeyidentifier=keyid:always,issuer:always 4. Kolejny etap na drodze do budowy naszego własnego CA to stworzenie naszego głównego certyfikatu certyfikat ten będzie certyfikatem typu self-signed (samopodpisany) Ok, więc za pomocą poniższego polecenia tworzymy nasze CA jego klucz publiczny, oraz prywatny: openssl req -config CA.config -new -x509 -out CA.cert

20 Przy tworzeniu zostaniemy poproszeni o nadanie hasła do klucza prywatnego Po potwierdzeniu hasła klucz zostanie zapisany w pliku privkey.pem Następnie, jest generowany certyfikat którym będziemy posługiwać się do podpisywania innych certyfikatów (np. dla klientów)

21 Zostaniemy poproszeni o podanie kilku pól zawartych w certyfikacie. Potem certyfikat zostanie zapisany w pliku CA.cert Widzimy, że został stworzony nasz klucz prywatny (klucz prywatny CA) oraz

22 nasz certyfikat jednocześnie będący kluczem publicznym CA Tak się prezetuje certyfikat naszego własnego CA :D : openssl x509 -in CA.cert -text -noout Po wydaniu opisanej uprzednio komendy narzędzie openssl generuje na standardowe wyjście strumień danych. Najważniejsze pola widoczne na zrzucie ekranowym to kolejno: numer seryjny: certyfikat tworzony przy pomocy przełącznika x509 polecenia req otrzymuje zawsze numer seryjny 0, chyba że zastosuje się przełącznik set_serial z pożądanym innym numerem, algorytm szyfrowania: dla celów przykładu użyto algorytmu MD5. W rzeczywistych zastosowaniach należy tego unikać, wystawca pełna nazwa wyróżniająca. Najpierw podawane są wszystkie pola obligatoryjne (stosownie do konfiguracji polityki centrum certyfikacyjnego), następnie po znaku / wszystkie pola opcjonalne (w tym wypadku jest takie jedno adres ) data ważności (początek i koniec okresu ważności) certyfikat jest ważny od 10 stycznia 2011 roku, a stanie się nieważny 9 lutego 2011 roku,

23 podmiot również pełna nazwa wyróżniająca w identycznym formacie, co nazwa wystawcy. Na zrzucie ekranowym wyróżniono pola opisujące wydawcę (issuer) i podmiot (subject) certyfikatu. Mają one tę samą nazwę wyróżniającą certyfikat jest więc samopodpisany, gdyż nasze CA nie ma już jednostki nadrzędnej, informacje o kluczu publicznym podmiotu (większa część tych danych nie została pokazana) 5. Nasze centrum certyifkacyjne już działa i może wystawiać certyfikaty zgłaszającym się podmiotom. Procedura działania jest następująca: najpierw generowane jest tzw. żądanie certyfikatu (powiązane z utworzeniem pary kluczy publicznego i prywatnego dla klienta ubiegającego się o certyfikat). Przygotowanie żądania certyfikatu nie jest w zasadzie zadaniem centrum certyfikacyjnego. Można zastosować jednak dwa podejścia: - generowanie żądania certyfikatu na maszynie CA. W takim przypadku klucz prywatny klienta znajduje się na komputerze centrum. Administrator powinien go przekazać klientowi poprzez zaufane medium, a następnie trwale wykasować, - generowanie żądania na komputerze klienta. Klucz prywatny klienta nie opuszcza jego maszyny, natomiast trzeba przekazać żądanie certyfikatu do centrum certyfikacyjnego przy pomocy na tyle zaufanego medium, na ile wymaga tego sytuacja. Należy także zapewnić, że osoba, która będzie takie żądanie przygotowywać, potrafił nadać mu formę akceptowalną przez CA można np. opublikować stosowne porady na stronie WWW czy też (w ramach mniejszej jednostki) wydać odpowiednią instrukcję 6. Teraz już możemy wygenerować certyfikat dla użytkownika składa się to z 2 etapów:) : Złożenie do CA wniosku o wystawienie certyfikatu Wystawienie (przez CA) certyfikatu dla klienta Gdy klient ma własny plik konfiguracyjny: Generowanie certyfikatów może wyglądać w taki sposób : klient przygotowuje plik konfiguracyjny dla OpenSSL'a, jako źródło danych konfiguracyjnych gdzie wprowadza wszystkie wymagane informacje. Wtedy generowanie zgłoszenia certyfikacji będzie wyglądać w taki sposób: openssl req -new -config user.conf -keyout key.pem -nodes -out csr.pem

24 Gdzie: user.conf to plik konfiguracyjny przygotowany przez użytkownika, Źródło danych konfiguracyjnych wskażemy tym razem przy pomocy przełącznika config, za którym następuje ścieżka do pliku. Przyjmujemy, że osoba ubiegająca się o certyfikat przygotowała taki zbiór i zapisała go w bieżącym katalogu pod nazwą user.conf key.pem to klucz prywatny klienta ubiegającego się o certyfikat, jest generowany przez CA administrator CA powinien przesłać (lub w inny bezpieczny sposób) przekazać klientowi jego klucz prywatny i natychmiast potem usunąć go z katalogu CA! csr.pem żądanie certyfikatu Gdy klient nie posiada własnego pliku konfiguracyjnego: Wtedy musi wypełnić pola podane w naszej polityce CA, oczywiście zmieni się także komenda składania wniosku o wystawienie certyfikatu : openssl req -new -keyout key.pem -nodes -out csr.pem key.pem to klucz prywatny klienta ubiegającego się o certyfikat, jest generowany przez CA administrator CA powinien przesłać (lub w inny bezpieczny sposób) przekazać klientowi jego klucz prywatny i natychmiast potem usunąć go z katalogu CA! csr.pem żądanie certyfikatu Dla naszego przykładu załóżmy, że nie posiadamy własnego pliku konfiguracyjnego należy więc użyć poniższego polecenia: Składamy wniosek o wystawienie certyfikatu: openssl req -new -keyout key.pem -nodes -out csr.pem

25 wypełniamy dane pola :

26 widzimy, że katalogu naszego CA zostały utworzone 2 pliki, key.pem oraz csr.pem, omówione dokładniej wcześniej:

27 Obejrzenie utworzonego żądania certyfikatu nie jest skomplikowane. Wystarczy ponownie skorzystać z narzędzia openssl req, tym razem definiując dane wejściowe przy pomocy przełącznika in, za którym następuje utworzony przed chwilą plik z żądaniem. Format danych zdefiniowany zostanie przez opcję text. Ponieważ chcemy uzyskać wyłącznie dane na standardowym wyjściu, przekazujemy również przełącznik noout. Przeglądając wydruk, można porównać np. czy nazwa wyróżniająca osoby ubiegającej się o certyfikat jest identyczna z wprowadzoną wcześniej. Można także przekonać się, że w żądaniu znajdują się informacje o kluczu publicznym potencjalnego właściciela certyfikatu Oglądamy nasze żądanie certyfikatu sprawdzając jednocześnie, czy wszystko się zgadza: openssl req in csr.pem text -noout Zakładamy, że CA posiada już żądanie certyfikatu. Kolejne działania wykonywane będą oczywiście na maszynie centrum certyfikacyjnego. Trzeba zatem pamiętać, aby zastosować odpowiedni zestaw danych konfiguracyjnych.

28 Na potrzeby przykładu zastosowany będzie plik konfiguracyjny CA.config znajdujący się w bieżącym katalogu Do utworzenia certyfikatu skorzystamy z polecenia openssl ca, które służy do zarządzania centrum certyfikacyjnym Zastosowane zostaną standardowe przełączniki: -in, wskazujący źródło danych wejściowych (a więc żądanie certyfikatu csr.pem), -out, definiujący miejsce docelowe danych (plik wynikowy z certyfikatem, np. mycert.pem), -config, wskazujący położenie pliku konfiguracyjnego oraz notext, który blokuje wyświetlenie zawartości certyfikatu (obejrzymy go później) Generacja certyfikatu odbywa się domyślnie w interakcji z użytkownikiem (w tym przypadku jest to administrator CA). Na początku musi on podać hasło do klucza prywatnego CA. Następnie weryfikuje dane podmiotu (nazwa wyróżniająca, okres ważności certyfikatu) i potwierdza podpisanie certyfikatu kluczem prywatnym CA W końcowej fazie procesu generowania certyfikatu wymagane jest jeszcze jedno potwierdzenie. Zakładając, że wszystko przebiega bez błędów, po utworzeniu pliku z certyfikatem w odpowiedni sposób zostają uaktualnione wewnętrzne dane centrum Jeśli wszystko jest ok, możemy już przystąpić do wygenerowania certyfikatu dla stworzonego wcześniej żądania Na początku należy skopiować klucz prywatny naszego CA do katalogu private: cp privkey.pem /home/kasiula/myownca/private/

29 Wydajemy polecenie generujące certyfikat na podstawie stworzonego wcześniej żądania wydania certyfikatu: openssl ca -config CA.config -in csr.pem -out mycert.pem

30 Po wydaniu komendy w katalogu bieżącym (czyli katalogu CA : /home/kasiula/myownca/) zostanie utworzony plik mycert.pem, który jest certyfikatem wydanym dla klienta: Po wystawieniu certyfikatu centrum certyfikacyjne musi uaktualnić swoje wewnętrzne struktury danych, aby uniknąć późniejszych niejasności i błędów przy obsłudze kolejnych klientów Przede wszystkim tworzony jest nowy plik z certyfikatem. Niezależnie od pliku wynikowego wskazanego przełącznikiem out wystawiony certyfikat zawsze zapisywany jest w katalogu wskazanym w pliku konfiguracyjnym CA. Nazwa pliku z certyfikatem jest równa jego numerowi seryjnemu, a rozszerzenie (dla formatu PEM) to.pem. Zatem tak naprawdę nie trzeba specyfikować pliku wyjściowego zrobiliśmy to, żeby nie trzeba było odszukiwać właściwego pliku przed przekazaniem go klientowi tylko na podstawie jego numeru seryjnego Oznacza to, że niezależnie od tego, jaką nazwę pliku z certyfikatem podamy, to i tak w katalogu /home/kasiula/myownca/newcert zoastanie zapisana kopia wydanego certyfikatu będzie to dokładnie taki sam plik, z taką samą zawartością jak plik mycert.pem. Jego nazwa będzie równa numerowi seryjnemu, czyli pierwszy wydany certyfikat będzie nazywał się 01.pem, drugi

31 02.pem, itd.

32 Nasz plik z bazą danych certyfikatów także zostanie zmodyfikowany plik index.txt zawiera informacje o wydanym przed chwilą certyfikacie Pewne dane o utworzonym certyfikacie (status, zakodowane (...), numer seryjny, część nazwy wyróżniającej) dopisane są również do pliku index.txt Poprzednia kopia tego pliku zostaje zapisana pod nazwą index.txt.old Następną oznaką aktualizacji wewnętrznej bazy danych jest zmiana zawartości pliku serial. Zawiera on teraz liczbę 02, który to numer seryjny otrzyma kolejny certyfikat

33 Numer seryjny ostatnio wystawionego certyfikatu wędruje natomiast do pliku serial.old (ponieważ CA wygenerowało teraz w ogóle pierwszy certyfikat kliencki, plik ten wcześniej nie istniał i został utworzony)

34