|
wersja 0.2 |
|
Spis treści |
1. Po kiego ? 2. OpenSSL 3. CA 4. Postfix + TLS 5. Apache + mod_ssl 6. Stunnel 7. OpenSSH 8. vsftpd 9. MySQL 10. OpenLDAP 11. PostgreSQL Posłowie |
| 1. Po kiego ? |
Często zdarza się tak, że po raz dwudziesty instalujesz jakiś soft. Robisz swoje i chcesz to mieć jak najszybciej z głowy. Nagle się zacinasz... W którym miejscu ? Gdy trzeba wygenerować jakieś certyfikaty. To boli, jak drzazga w fiucie. Zaczynasz latać po Necie i dwie godziny szukasz trzech głupich linijek tekstu opisującego generowanie certyfikatów dla określonego softu. Ten dokument ma być zbieraniną gotowych poleceń. Może od razu przejdę do rzeczy, nie jestem dziś w nastroju... |
| 2. OpenSSL |
Spójrzmy prawdzie w oczy: bez tego softu możesz sobie generować. Klocka na klopie. Dbaj o to, abyś miał jego aktualną wersję. Dość często znajdowane są w nim dziury o strategicznym znaczeniu (nie przychodzi mi do głowy inny przymiotnik). Ale miało być na szybkiego... Pobierz ostatnią (z ang. latest :) wersję: http://www.openssl.org/source/ W chwili, gdy powstawał ten dokument byłem w wyjątkowo chujowym nastroju. Znowu odchodzę od tematu. W chwili, gdy powstawał ten dokument ostatnią wersją była 0.9.7d. Czas na instalację. Po rozpakowaniu tałatajstwa wydaj następujące polecenia: ./config make make install To ostatnie jako root. No i znowu piszę o duperelach. Chwilę to potrwa. Domyślnie nasz soft ląduje w /usr/local/ssl/. Bez zadawania pytań zrób, co następuje:
|
| 3. CA |
Aby Twoje certyfikaty były coś warte, muszą zostać podpisane. A ponieważ nie masz kasy na podpisanie ich przez odpowiednie firmy (podobnie jak ja), będziesz je podpisywał sam. A czym podpisuje się certyfikaty ? Innymi certyfikatami. Tak więc na początku musisz wygenerować je sobie. Ta czynność wykonywana jest jednorazowo - tworzysz certyfikat którym podpisywał/a będziesz inne. Dla każdego softu, który ich wymaga. Jeśli więc podpiszesz nim certyfikat dla Apacza, ktoś wejdzie na Twoją stronę przez https, i kliknie "pokaż właściwości certyfikatu" lub coś w tym stylu, zobaczy: "podpisane przez: ......". Tam gdzie te kropeczki będzie to, co zaraz wpiszesz. W skórcie: aby podpisywać certyfikaty, musisz najpierw wygenerować sobie to, czym je będziesz podpisywał. Czyli staniesz się CA (ang. Certificate Authority). Jeśli zainstalowałeś OpenSSL tak, jak to opisałem wcześniej, wejdź do katalogu /usr/local/ssl/misc/. Znajduje się w nim plik CA.sh. Wrzuć go do jakiegoś edytora i znajdź definicję zmiennej DAYS (zaraz na początku skryptu). Zmień wartość 365 na większą, np. 1850. Chodzi o to, żeby certyfikat CA ważny był dłużej, niż to, co będziesz podpisywał. Zmień i nie marudź, zapisz zmiany. Teraz tak: ./CA.sh -newca Nazwę pliku możesz zostawić domyślną. Następnie wymyśl dobre hasło. I zapamietaj je :) Hasłem tym będzie zaszyfrowany Twój prywatny certyfikat CA. Następnie wypełnij dane "jednostki certyfikującej": nazwa państwa, firmy, wydział, nazwisko - bzdury, które będą widoczne pod "właściwościami CA, wystawiono przez" itp. Jeśli przyjąłeś domyślne wartości, powstał katalog demoCA (/usr/local/ssl/misc/demoCA), w którym znajduje się wszystko, co trzeba żeby być CA. Mamy więc plik cacert.pem, który jest publicznym kluczem CA oraz pasującym do niego, zaszyfrowanym plikiem cakey.pem znajdującym się w podkatalogu private. Pozostałe katalogi to pierdy, może do nich wrócimy. Jesteś CA. Możemy przejść do sedna... |
| 4. Postfix + TLS |
Przygotowania: tworzymy katalog docelowy oraz kopiujemy certyfikat CA: mkdir /etc/ssl/postfix cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/postfix/ca.pem Tworzymy certyfikat dla Postfixa: cd /usr/local/ssl/misc/ /usr/local/ssl/bin/openssl req -new -nodes -keyout key.pem -out newreq.pem mv key.pem /etc/ssl/postfix/ ./CA.sh -sign mv newcert.pem /etc/ssl/postfix/cert.pem Sprzątamy po sobie: rm newreq.pem chmod 0600 /etc/ssl/postfix/* Fragment konfiguracji Postfixa (main.cf) odpowiedzialny za ścieżki do certyfikatów: smtpd_tls_key_file = /etc/ssl/postfix/key.pem smtpd_tls_cert_file = /etc/ssl/postfix/cert.pem smtpd_tls_CAfile = /etc/ssl/postfix/ca.pem Po szczegóły odsyłam do odpowiedniego dokumentu. |
| 5. Apache + mod_ssl |
Przygotowania: tworzymy katalog docelowy oraz kopiujemy certyfikat CA: mkdir /etc/ssl/apache cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/apache/ca.pem Tworzymy "prośbę" o certyfikat dla Apacza: cd /usr/local/ssl/misc/ ./CA.sh -newreq Wpisujemy dane właściwe dla naszej strony internetowej. Ważne: w polu COMMON NAME wpisujemy pełną nazwę domeny pod którą będzie nasza szyfrowana strona, np. poczta.serwer.pl. Wymyślamy i wpisujemy hasło dla apaczowego certyfikatu oraz je zapamiętujemy :) Na pytania o dodatkowe 'extra' hasła i takie tam odpowiadamy Enterem. Podpisujemy naszą prośbę (przy pomocy certyfikatu CA) a w rezultacie otrzymujemy certyfikat dla naszego Apacza: ./CA.sh -sign mv newreq.pem /etc/ssl/apache/ mv newcert.pem /etc/ssl/apache/cert.pem Ściągamy hasło z klucza prywatnego: cd /etc/ssl/apache/ openssl rsa -in newreq.pem -out req.pem rm newreq.pem chmod 0600 * Tia, to by było na tyle. Fragment konfiguracji Apacza (np. definicji wirtualnego hosta) odpowiedzialny za ścieżki do certyfikatów: SSLCertificateFile /etc/ssl/apache/cert.pem SSLCertificateKeyFile /etc/ssl/apache/req.pem SSLCACertificateFile /etc/ssl/apache/ca.pem W ten oto sposób mamy z głowy Apacza. |
| 6. Stunnel |
Stunnel to taka sprytna bestia, że przy jego pomocy można szyfrować połączenie do Apacza, eftepa, MySQLa itd. Tworzymy katalog docelowy: mkdir /etc/ssl/stunnel cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/stunnel/ca.pem W miejscu, w którym rozpakowaliśmy źródełka programu, w podkatalogu tools znajduje się plik stunnel.cnf. cp stunnel.cnf /etc/ssl/stunnel/ cd /etc/ssl/stunnel/ openssl req -new -x509 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem Mamy to, co chcieliśmy: stunnel.pem. Sprzątamy po sobie: rm stunnel.cnf rm stunnel.rnd chmod 0600 * Fragment konfiguracji Stunnel (stunnel.conf) odpowiedzialny za ścieżki do certyfikatów: CAfile = /etc/ssl/stunnel/ca.pem cert = /etc/ssl/stunnel/stunnel.pem Po szczegóły odsyłam do odpowiedniego dokumentu.d |
| 7. OpenSSH |
Gdyby ktoś uznał, że potrzebuje nowe klucze dla swojego serwera: mkdir /etc/ssl/ssh Klucze RSA dla pierwszej wersji SSH: ssh-keygen -t rsa1 -f /etc/ssl/ssh/ssh1_rsa.key Klucze RSA dla drugiej wersji SSH: ssh-keygen -t rsa -f /etc/ssl/ssh/ssh2_rsa.key Klucze DSA dla drugiej wersji SSH: ssh-keygen -t dsa -f /etc/ssl/ssh/ssh2_dsa.key Na pytanie o hasło wciskamy Enter (zostawiamy je puste) lub do każdego z powyższych wywołań ssh-keygen dopisujemy na końcu -N "" Fragment konfiguracji OpenSSH (sshd_config) odpowiedzialny za ścieżki do kluczy: HostKey /etc/ssl/ssh/ssh1_rsa.key HostKey /etc/ssl/ssh/ssh2_rsa.key HostKey /etc/ssl/ssh/ssh2_dsa.key To by było na tyle... |
| 8. vsftpd |
Od drugiej wersji serwer vsftpd obsługuje szyfrowanie. Może ono dotyczyć np. samego momentu zalogowania się, pomijając szyfrowanie przesyłanych danych. Mniejsza z tym. mkdir /etc/ssl/vsftpd cd /etc/ssl/vsftpd Sedno sprawy: openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem A teraz fragment konfiguracji vsftpd (vsftpd.conf) odpowiedzialny za ścieżkę do klucza: rsa_cert_file=/etc/ssl/vsftpd/vsftpd.pem Syćko :) |
| 9. MySQL |
I połączenia z bazą danych mogą być szyfrowane... (wystarczy skompilować soft z odpowiednimi opcjami). mkdir /etc/ssl/mysql cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/mysql/ca.pem Teraz potrzebujemy tylko wygenerować certyfikat i klucz dla naszego serwera. cd /usr/local/ssl/misc ./CA.sh -newreq ./CA.sh -sign openssl rsa -in newreq.pem -out key.pem rm newreq.pem mv key.pem /etc/ssl/mysql/key.pem mv newcert.pem /etc/ssl/mysql/cert.pem Fragment konfigu odpowiedzialny za konfiguracje ścieżek do certyfikatów dla serwera MySQL: [mysqld] ................... ssl-ca = /etc/ssl/mysql/ca.pem ssl-cert = /etc/ssl/mysql/cert.pem ssl-key = /etc/ssl/mysql/key.pem W analogiczny sposób należy wygenerować certyfikaty dla klientów i umieścić je w sekcji [mysql]. Aby połączenie szyfrowane było wymagane, należy przy udzielaniu uprawnień (polecenie GRANT) dopisać REQUIRE SSL. |
| 10. OpenLDAP |
Tworzymy katalog docelowy oraz kopiujemy certyfikat CA: mkdir /etc/ssl/ldap cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/ldap/ca.pem Tworzymy certyfikat: cd /usr/local/ssl/misc/ /usr/local/ssl/bin/openssl req -new -nodes -keyout key.pem -out newreq.pem mv key.pem /etc/ssl/ldap/ ./CA.sh -sign mv newcert.pem /etc/ssl/ldap/cert.pem A oto fragment konfiguracji LDAPa (slapd.conf) odpowiedzialny za ścieżki do certyfikatów: TLSCACertificateFile /etc/ssl/ldap/ca.pem TLSCertificateFile /etc/ssl/ldap/cert.pem TLSCertificateKeyFile /etc/ssl/ldap/key.pem Aby demon nasłuchiwał także na szyfrowanym porcie, należy przy jego wywołaniu skorzystać z dodatkowej opcji, np. w ten sposób: /usr/local/libexec/slapd -4 -h "ldap:/// ldaps:///" |
| 11. PostgreSQL |
Nic tak nie boli jak zjebana dokumentacja. Prawie nic... Zaczynamy klasycznie: mkdir /etc/ssl/psql cp /usr/local/ssl/misc/demoCA/cacert.pem /etc/ssl/psql/root.crt Należy teraz wygenerować certyfikat i klucz dla naszego serwera. cd /usr/local/ssl/misc ./CA.sh -newreq ./CA.sh -sign openssl rsa -in newreq.pem -out key.pem rm newreq.pem mv key.pem /etc/ssl/psql/server.key mv newcert.pem /etc/ssl/psql/server.crt Chciałoby się powiedzieć That's it!, jednak nie tym razem :) Postgres wymaga aby utworzone przed chwilą pliki znajdowały się w katalogu $PGDATA serwera (domyślnie: /usr/local/pgsql/data) pod nazwami, które przed chwilą stworzyliśmy (root.crt server.crt server.key). Ponieważ nie chcemy zburzyć naszej fajnej struktury z kluczami, wykorzystujemy teraz linki (aka sznurki) symboliczne: ln -s /etc/ssl/psql/root.crt /usr/local/pgsql/data/root.crt ln -s /etc/ssl/psql/server.crt /usr/local/pgsql/data/server.crt ln -s /etc/ssl/psql/server.key /usr/local/pgsql/data/server.key Oczywiście katalog w którym Postgres trzyma swoje dane może być u Ciebie inny. Jeszcze tylko prawa: u mnie baza pracuje z prawami użtkownika pgsql, u Ciebie może to być np. postgres. Wyczaj to i zrób tak: cd /etc/ssl/psql/ chmod 0600 * chown pgsql * Oczywiście nie muszę pisać, że zamiast "pgsql" powinieneś użyć swojego usera... prawda? :) Czas na fragment konfigów. W tym samym katalogu, co wspomniane przed chwilą pliki, znajdują się inne. W postgresql.conf należy umieścić zapis ssl = true, w pliku pg_hba.conf należy natomiast odpowiednio umieścić słowo kluczowe hostssl (odpowiednik słowa host) definiujące wyłącznie połączenie szyfrowane. To wszystko pod warunkiem, że nasz Postgres został skomilowany z SSL... |
| Posłowie |
Napisz do mnie, jaki soft pominąłem. Lub który opis nie działa. Lub jaki Twój życiowy problem... Jest to pierwsza wersja tego dokumentu i zawiera pewnie jakieś błędy/niedoróbki/potknięcia itp. Będę bardzo wdzięczny za wszelkie uwagi, komentarze, poprawki, wyrazy wdzięczności. Z góry przepraszam za powyższe i mam nadzieję, że będziecie mnie informować w których miejscach coś nie gra. Jako (częściowe) wytłumaczenie przedstawiam fakt, że większość tej pracy powstawała w późnych godzinach nocnych. Ostatnia wersja tego dokumentu znajduje się pod niżej wymienionym adresem. Kontakt ze mną: linio@terramail.pl Wesprzyj finansowo autora - kliknij tutaj |
|
=============================== Henryk Liniowski, Poznań 2004 http://linio.terramail.pl =============================== |