7:39
1/4/2010

Poniższy artykuł powstał w celu pokazania krok po kroku, co należy zrobić, aby twój serwis internetowy zaczął rozmawiać ze światem przy użyciu bezpiecznego protokołu HTTPS i zaufanego, komercyjnego certyfikatu. Pokażemy jak wyrobić i gdzie zakupić certyfikat SSL oraz jak poprawnie skonfigurować serwer WWW do pracy z certyfikatem.

Na początek trochę teorii…

Szyfrowanie to proces przekształcania tekstu z postaci jawnej, czytelnej dla człowieka na postać “zabezpieczoną”, której nie da się wprost odczytać. Jeśli intruz przechwyci niezaszyfrowaną transmisję danych, może łatwo odczytać wszystkie przesyłane w niej informacje (por. błąd w formularzach zmiany haseł w polskich portalach).

Przechwytywanie hasła do e-maila

Wyobraźmy sobie logowanie do poczty przez interfejs WWW. Użytkownik uwierzytelnia się podając swój login oraz hasło. W tej samej sieci czai się intruz, którego zadaniem jest przechwycenie tajnych danych dostępowych użytkownika.

Do przechwytywania transmisji danych w sieci Ethernet służą narzędzia nazywane snifferami. Najpopularniejsze z nich to tcpdump, tcpflow, wireshark. Jeśli sieć oparta jest o switche, a nie huby, atak jest odrobinę trudniejszy ponieważ przed użyciem sniffera należy wykonać dodatkowe czynności (np. wysłać odpowiednio zmodyfikowane pakiety ARP, lub przepełnić tablicę CAM switcha).

Przechwycone przy użyciu sniffera dane wymieniane pomiędzy przeglądarką ofiary a serwerem poczty mogą wyglądać tak:

Transmisja nieszyfrowana -- login i hasło widoczne

Na powyższym rysunku widać, że podsłuchanie transmisji niezaszyfrowanej, ujawnia nasze dane przesyłane do panelu logowania. Gdyby serwer poczy do którego loguje się użytkownik posiadał certyfikat SSL oraz szyfrował transmisję, intruz nie byłby w stanie podejrzeć żadnych danych, a przechwycona transmisja wyglądałyby tak:

Certyfikat SSL obecny, transmisja szyfrwana -- login i hasło nie do podejrzenia

Czy potrzebuję SSL-a?

Przesyłając w Internecie jakiekolwiek dane zawierające niepubliczne (poufne) informacje, zawsze powinniśmy wykorzystywać transmisję szyfrowaną. Pozwoli to nam uniknąć sytuacji, w której informacje zostaną odczytane przez osoby postronne. Mechanizm SSL zapewnia szyfrowanie danych przesyłanych między serwerem a klientem, dodatkowo daje możliwość zweryfikowania tożsamości serwera.

Jak to wygląda od strony technicznej? Certyfikat używany do szyfrowania danych jest podpisany elektronicznie przez zaufane centrum certyfikacji — to poświadcza jego autentyczność i pozwala na obsługę konkretnej domeny (tej dla której został wygenerowany).

Chcę szyfrować transmisję, jak mogę zdobyć certyfikat?

Aby zdobyć certyfikat SSL ptrzebujemy dwóch rzeczy: klucza prywatnego naszego hosta i tzw. żądania certyfikatu (ang. CSR: Certificate Signing Request). Obie wygenerujemy przy pomocy OpenSSL — darmowego, opensourceo’wego i multiplatformowego narzędzia. W naszych przykładach użyjemy domeny www.varlog.pl.

Aby wygenerować prywatny klucz hosta wykonujemy polecenie:
# openssl genrsa -des3 -out www.varlog.pl.key 2048

OpenSSL podczas generowania klucza prywatnego poprosi o podanie hasła, którym zostanie zaszyfrowany klucz. Dlaczego? Żeby nawet po przechwyceniu klucza, atakujący nie mógł z niego tak łatwo skorzystać.

Mając klucz, możemy wygenerować CSR, czyli żądanie certyfikatu:
# openssl req -new -key www.varlog.pl.key -out www.varlog.pl.csr

Podczas generowania żądania certyfikatu, nasz klucz zawarty w pliku www.varlog.pl.key musi zostać na chwilę odszyfrowany, tak więc pojawi się prośba o wprowadzenie hasła. W rezultacie otrzymamy plik www.varlog.pl.csr, który po podpisaniu przez zaufane centrum certyfikacji stanie się certyfikatem i będzie mógł zostać użyty do szyfrowania transmisji.

Innym sposobem na wygenerowanie prywatnego klucza i żądania certyfikatu jest skorzystanie z gotowych skryptów CA.pl (perl) lub CA.sh (bash), ale wtedy najprawdopodobniej zostaniemy zmuszeni do zmiany konfiguracji przez plik openssl.conf (/etc/ssl/openssl.cnf), ponieważ domyślnie openssl generuje 1024 bitowy klucz prywatny, a ten może okazać się za słaby dla niektórych wystawców certyfikatów.

Najpierw zlokalizujmy skrypt CA.pl w naszym systemie (najczęściej skrypty znajdują się w katalogu: /usr/lib/ssl/misc/)
# locate CA.pl

A następnie odpalmy go z parametrem -newreq (new request), który spowoduje, że wygenerujemy żądanie certyfikatu
# CA.pl -newreq

W rezultacie otrzymamy 2 pliku, newreq.pem który jest żądaniem oraz newkey.pem — nasz klucz prywatny.

Niezależnie od wybranej metody generowania CSR, podczas generowania żądania certyfikatu zostaniemy poproszeni o podanie kilku informacji:

Country = PL # kraj
State = Malopolskie # województwo
Localization = Krakow # miasto
Organization = VarLog # nazwa naszej firmy, jednostka organizacyjna
Common Name = www.varlog.pl # jest to bardzo ważne pole, to właśnie CN decyduje dla jakiej domeny będzie wygenerowane żądanie (podanie www w nazwie domeny, oznacza, że certyfikat będzie ważny zarówno dla www.varlog.pl jak i varlog.pl)
emailAddress = patryk.kuzmicz@gmail.com # jest adresem e-mail służącym do kontaktu w sprawie certyfikatu

Po wygenerowaniu CSR na wszelki wypadek powinniśmy sprawdzić, czy nie ma w nim żadnej pomyłki. Do sprawdzenia służy polecenie:
# openssl req -in www.varlog.pl.csr -text

Podpisywanie certyfikatu przez centrum certyfikacji

Tak przygotowany CSR możemy wysyłać do centrum certyfikacji..

Centrum certyfikacji musi zweryfikować nasze żądanie — w tym celu musimy udowodnić, że faktycznie jesteśmy właścicielem serwera dla którego staramy się o certyfikat. Proces weryfikacyjnego składa się z dwóch etapów:

  • umieszczenie pliku na serwerze lub umieszczenie ciągu znaków na stronie w domenie dla której staramy się o certyfikat
  • wysłanie maila z domeny (np. admin@varlog.pl, sysadmin@varlog.pl, root@varlog.pl), maile są zdefiniowane i mamy wybór spośród kilku opcji

Jeśli weryfikacja się powiedzie, otrzymamy na podany adres e-mail identyfikator. Dzięki niemu będziemy mogli pobrać przez WWW podpisany certyfikat.

Dane certyfikatu możemy wyświetlić przy użyciu polecenia openssl:
# openssl x509 -in www.varlog.pl.crt -text

Każdy podpisany certyfikat posiada okres ważności, termin ten jest zawarty w sekcji Validity:
Not Before: Mar 17 13:58:12 2010 GMT
Not After : Mar 18 13:58:12 2011 GMT

Dlaczego należy podpisywać certyfikaty w zaufanym centrum certyfikacji?

Przecież można wygenerować własne CA (“jednostę certyfikującą”) i za jej pomocą podpisać swoje żądanie… Problem w tym, że tzw. root certificate naszego własnego CA nie będzie obecny w przeglądarkach internetowych i systemach innych użytkowników na świecie (zarówno w Windows, Linux, Mac OS, jak i Firefox, Opera, IE, Chrome, Safari). Jego brak spowoduje, że użytkownik odwiedzający nasz serwer posiadający certyfikat podpisany za pomocą naszego własnego CA zobaczy błąd, mówiący iż certyfikat nie jest podpisany przez zaufane cetrum autoryzacji.

Sesja HTTPS zestawiona przy pomocy certfikatu niepodpisanego przez zaufane centrum certyfikacji

Od użytkownika będzie się wymagało ręcznego dodania naszego certyfikatu jako zaufanego (co może budzić obawy co do bezpieczeństwa połączenia, abstrahując już od tego, że zdecydowanie nie jest profesjonalne podejście do klienta). Tego typu błąd nie pojawi się, jesli certyfikat jest podpisany przez centrum certyfikacji.

Sesja HTTPS zestawiona przy pomocy certyfikatu wydanego przez zaufane centrum certyfikacji. Kłódka obecna, ostrzeżeń przeglądarki brak.

Root CA jest obecne w przeglądarkach, co łatwo możecie sami sprawdzić, wyświetlając certyfikaty przeglądarki. Jak to zrobić, opisaliśmy w tekście ochrona przed backdoorami, czyli podpis spotyka kod.

Magazyn certyfikatów w przeglądarce

Certyfikat dla domeny www.varlog.pl został podpisany przez “Unizeto, Certum Level II CA”, które znajduje się w sekcji „organy autoryzacji”. Tak podpisany certyfikat sprawia, że nasz serwer będzie rozpoznawany przez przeglądarki internetowe jako bezpieczny i zweryfikowany.

Szyfrowane połączenie do serwera WWW

Zestawianie szyfrowanego połączenia można podzielić na 7 kroków:

  1. klient łączy się z serwerem
  2. serwer odpowiada wraz z certyfikatem (x509)
  3. klient weryfikuje ważność certyfikatu, domenę
  4. klient generuje klucz symetryczny i szyfruje go asymetrycznie za przy pomocy klucza publicznego serwera (z certyfikatu)
  5. klient przesyła klucz symetryczny w postaci zaszyfrowanej do serwera
  6. serwer weryfikuje dane i odszyfrowuje klucz
  7. od tej pory transmisja odbywa się w sposób szyfrowany

Dodawanie certyfikatu do serwera WWW

Istnieje kilka sposobów na podpięcie certyfikatu do serwera WWW. Możemy skorzystać z stunnel‘a (klient SSL → proxy SSL → serwer pracujący bez SSL), lub bezpośrednio podpiąć certyfikat pod serwer Apache, Lighttpd, Nginx. Poniżej przedstawiamy sposób przygotowania serwera Apache serii 1.3.X oraz 2.2.X.

Zasadnicza rożnica w przypadku obsługi SSL pomiędzy Apache serii 2.x a 1.x jest taka, że Apache 1.x nie zawiera sam w sobie obsługi protokołu SSL i należy dodatkowo doinstalowywać moduł mod_ssl.

Konfiguracja certyfikatu dla Apache 1.3.42

Poniższy opis zawiera wszystkie kroki jakie należy wykonać by uruchomić szyfrowanie przy użyciu SSL. Opis będzie opierał się o kompilację ze źródeł, w przypadku instalacji z pakietów binarnych, wymagane paczki są zależne od dystrybucji, ale na pewno niezbędny będzie mod_ssl oraz serwer Apache ;-)

1. Pobieramy źródła:
# wget http://archive.apache.org/dist/httpd/apache_1.3.42.tar.gz

2. Pobieramy mod_ssl:
# wget http://www.modssl.org/source/mod_ssl-2.8.31-1.3.41.tar.gz

3. Rozpakowujemy źródła Apache oraz mod_ssl:
# tar zxvf apache_1.3.42.tar.gz
# tar zxvf mod_ssl-2.8.31-1.3.41.tar.gz

4. Patchujemy źródła Apache:
cd mod_ssl-2.8.31-1.3.41/
./configure --with-apache=../apache_1.3.42/ --force

Musimy użyć przełącznika –force, ponieważ ostatnia dostępna wersja mod_ssl na dzień dzisiejszy jest dla Apache 1.3.41.

5. Konfigurujemy serwer Apache z obsługą mod_ssl:
cd ../apache_1.3.42/
./configure --prefix=/usr/local/apache-1.3.42 –enable-module=ssl

Powinniśmy zobaczyć informacje:
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.8.31
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
+ SSL library path: [SYSTEM]
+ SSL library version: OpenSSL 0.9.8g 19 Oct 2007
+ SSL library type: installed package (system-wide)

Komunikat ten potwierdza kompilację z obsługą SSL.

6. Kompilacja i instalacja:
# make
# make install

Jeśli używamy kompilatora gcc 4.4.x, może pojawić się problem związany z podwójną deklaracją funkcji getline():
htpasswd.c:101: error: conflicting types for 'getline'
/usr/include/stdio.h:651: note: previous declaration of 'getline' was here
make[2]: *** [htpasswd.o] Error 1
make[2]: Leaving directory `/home/jamzed/niebezpiecznik/new/apache_1.3.42/src/support'
make[1]: *** [build-support] Error 1
make[1]: Leaving directory `/home/jamzed/niebezpiecznik/new/apache_1.3.42'
make: *** [build] Error 2

Apache napisało własną funkcję getline(), ale w systemowej bibliotece stdio.h już taka istnieje. Rozwiązaniem na to jest zmiana nazwy funkcji getline() w plikach: src/support/htdigest.c, src/support/htpasswd.c, src/support/logresolve.c na inną. Jeśli nie chcesz robić tego ręcznie, sprawdź przygotowany przez nas patch

7. Nałożenie poprawki związanej z duplikacją funkcji getline():
# wget http://www.varlog.pl/wp-content/uploads/2010/03/apache-getline.patch.gz
# gzip -d apache-getline.patch.gz
# patch -p0 < apache-getline.patch

W wyniku zobaczymy informację o patchowaniu plików:
patching file src/support/htpasswd.c
patching file src/support/htdigest.c
patching file src/support/logresolve.c

Mając już nałożoną poprawkę wykonujemy jeszcze raz krok 6.

8. Jeśli wszystkie powyższe kroki zostały wykonane poprawnie, powinniśmy mieć skompilowany i gotowany do konfiguracji serwer Apache. Serwer został zainstalowany w katalogu /usr/local/apache-1.3.42/, konfiguracja znajduje się w pliku /usr/local/apache-1.3.42/conf/httpd.conf. Nasz certyfikat oraz klucz kopiujemy do lokalizacji:
# cp www.varlog.pl.crt /usr/local/apache-1.3.42/conf/ssl.crt/
# cp www.varlog.pl.key /usr/local/apache-1.3.42/conf/ssl.key/

9. Jeśli nie chcemy aby Apache przy starcie pytał o hasło do klucza, należy umieścić w katalogu ssl.key klucz odszyfrowany, możemy to zrobić tak (odszyfrowany klucz będzie miał nazwę www.varlog.pl.dec.key):
# openssl rsa -in /usr/local/apache-1.3.42/conf/ssl.key/www.varlog.pl.key > /usr/local/apache-1.3.42/conf/ssl.key/www.varlog.pl.dec.key

10. Uruchamiamy ulubiony edytor i przechodzimy do konfiguracji.
# vi /usr/local/apache-1.3.42/conf/httpd.conf

Sekcja odpowiedzialna za konfigurację szyfrowania nazywa się, SSL Virtual Host Context, odnajdujemy ją (linia 1029). Domyślna konfiguracja wygląda następująco:
SSLEngine on # włączenie obsługi SSL
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # jest to lista dozwolonych metod szyfrowania
SSLCertificateFile /usr/local/apache-1.3.42/conf/ssl.crt/www.varlog.pl.crt # ścieżka do pliku z certyfikatem (www.varlog.pl.crt)
SSLCertificateKeyFile /usr/local/apache-1.3.42/conf/ssl.key/www.varlog.pl.dec.key # ścieżka do pliku z kluczem hosta

Te dyrektywy są wystarczające do uruchomienia serwera, natomiast czasami występuje sytuacja, że należy dodać dodatkowe certyfikaty centrum autoryzacyjnych.
# wget www.certum.pl/keys/ca-bundle.crt -O /usr/local/apache-1.3.42/conf/ssl.crt/ca-certum.crt

i dodajemy do konfiguracji kolejny parametr:
SSLCACertificateFile /usr/local/apache-1.3.42/conf/ssl.crt/ca-certum.crt

Cała konfiguracja może wyglądać następująco:
<IfDefine SSL>
<VirtualHost _default_:443>
DocumentRoot "/usr/local/apache-1.3.42/htdocs"
ServerName www.varlog.pl
ServerAdmin jamzed@varlog.pl
ErrorLog /usr/local/apache-1.3.42/logs/error_log
TransferLog /usr/local/apache-1.3.42/logs/access_log
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /usr/local/apache-1.3.42/conf/ssl.crt/www.varlog.pl.crt
SSLCertificateKeyFile /usr/local/apache-1.3.42/conf/ssl.key/www.varlog.pl.dec.key
SSLCACertificateFile /usr/local/apache-1.3.42/conf/ssl.crt/ca-certum.crt
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /usr/local/apache-1.3.42/logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Jest to minimalna konfiguracja mod_ssl, (więcej informacji można znaleźć na stronie domowej mod_ssl), oraz w sekcji dotyczącej samego modułu mod_ssl.c (linia: 975).

11. Mając konfigurację analogiczną do powyższej możemy spróbować uruchomić serwer:
# /usr/local/apache-1.3.42/bin/apachectl startssl
/usr/local/apache-1.3.42/bin/apachectl startssl: httpd started

12. Sprawdźmy w przeglądarce czy działa poprawnie, wchodząc na naszą stronę:

Przeglądarka nie zgłasza błedu certyfikatu, a wyświetlając jego szczegóły widzimy, że połączenie jest szyfowane a serwer zweryfikowany

Jak widać, wszystko się udało, transmisja jest szyfrowana, a my bezpiecznie możemy przesyłać dane.

Kofiguracja certyfikatu dla Apache 2.2.x

1. Pobieramy źródła:
# wget http://ftp.tpnet.pl/vol/d1/apache/httpd/httpd-2.2.15.tar.gz

2. Rozpakowanie źródeł:
# tar zxvf httpd-2.2.15.tar.gz

3. Kompilacja i instalacja:
# cd httpd-2.2.15/
# ./configure --enable-ssl –prefix=/usr/local/apache-2.2.15
# make
# make install

Po zainstalowaniu przechodzimy do konfiguracji:
# vi /usr/local/apache-2.2.15/conf/httpd.conf

Odhashowujemy linię:
Include conf/extra/httpd-ssl.conf

To spowoduje, że do konfiguracji Apache zostanie dołączona obsługa SSL'a, teraz możemy przygotować niezbędne pliki:
# mkdir /usr/local/apache-2.2.15/ssl/ # stwórzmy katalog SSL, w którym umieścimy plik certyfikatu oraz klucz
# cp www.varlog.pl.dec.key /usr/local/apache-2.2.15/ssl/ # kopiowanie klucza
# cp www.varlog.pl.crt /usr/local/apache-2.2.15/ssl/ # kopiowanie certyfikatu
# cp ca-certum.crt /usr/local/apache-2.2.15/ssl/ # kopiowanie certyfikatów naszego CA

oraz analogicznie do konfiguracji Apache 1.3.X uzupełniamy dane:
# vi /usr/local/apache-2.2.15/conf/extra/httpd-ssl.conf
SSLCertificateFile "/usr/local/apache2/ssl/www.varlog.pl.crt"
SSLCertificateKeyFile "/usr/local/apache2/ssl/www.varlog.pl.dec.key"
SSLCACertificateKeyFile "/usr/local/apache2/ssl/ca-certum.crt"

Jest to minimalna konfiguracja SSL'a, dająca możliwość szyfrowania transmisji, więcej informacji można znaleźć na http://httpd.apache.org/docs/2.0/mod/mod_ssl.html.

Po wykonaniu wszystkich powyższych elementów, można wystartować Apache'a i dumnie obsługiwać użytkowników w sposób bezpieczny
# sudo /usr/local/apache2/bin/apachectl restart

Zniżka na certyfikaty SSL

Przypominamy też, że z racji tego iż naszym marcowym sponsorem była firma CERTUM, możecie na lepszych warunkach niż inni skorzystać ze wszystkich Certyfikatów SSL. Wystarczy, że wypowiecie magiczne słowo "NIEBEZPIECZNIK", składając zamówienie na infolinii 0 801 540 340 (dla połączeń stacjonarnych) lub +48 91 4801 340 (dla dzwoniących z tel. komórkowych) i czeka na was 10% zniżki.


Powyższy artykuł powstał we współpracy z serwisem www.varlog.pl. Varlog.pl to krakowski serwis pisany przez administratorów nie tylko dla administratorów :-)

 


Przeczytaj także:



19 komentarzy

Dodaj komentarz
  1. To by był całkiem fajny art, gdyby nie ilość linków do jednego centrum weryfikacji i całkowitego braku wzmianek o istnieniu innych. A np. StartSSL (startssl.com) daje certyfikaty znacznie taniej, zaczynając od darmowych.

    Poza tym, wypadałoby wspomnieć, że jeśli komuś zależy tylko na bezpiecznej komunikacji, a nie weryfikacji, to opłata za certyfikat mija się z celem.

    • Krzaq: ten art jest na przykładzie Certum (polecenia, opisy, instrukcje). Jeśli inni wystawcy certyfikatów zgłoszą się do nas udostepniajac za darmo ich certyfikaty, to tez z chęcią umiescimy ich opis na Niebezpieczniku ;)

  2. Witam,
    Proponowałbym raczej konfigurowanie Apache z modułem GnuTLS do obsługi HTTPS.
    Niewątpliwą zaletą GnuTLS jest poza bezpieczeństwem, możliwość “podpięcia” pod jednym adresem ip wielu Virtual hosts z własnymi certyfikatami, czego Openssl do dziś nie potrafi.

    Porównanie: http://www.gnu.org/software/gnutls/comparison.html

  3. Z jedną rzeczą nie mogę się zgodzić. Piszesz: “podanie www w nazwie domeny, oznacza, że certyfikat będzie ważny zarówno dla http://www.varlog.pl jak i varlog.pl” (w komentarzu do pola CN; Common Name).
    Jeżeli wygenerujesz certyfikat dla “www.varlog.pl”, zainstalujesz go na witrynie i wejdziesz na adres:
    https://varlog.pl

    dostaniesz komunikat informujący o niezgodności nazw, domeny (varlog.pl) i CN certyfikatu (www.varlog.pl).

    Istnieje wprawdzie, odpowiednio droższy, tzw. certyfikat wildcard, gdzie CN to np. *.varlog.pl. Taki certyfikat pasuje do wszelkich subdomen, np. http://www.varlog.pl, http://ftp.varlog.pl, itp., ale już dla samego “varlog.pl” – nie pasuje.

  4. Wprawdzie nie na temat ale widze, ze panu ‘Gynvaelowi’ z pobocznej sekcji NB: “Polecamy” jakies dzieci wyhaczyly strone.
    Pomijajac edukacyjny walor deface’a, to nigdy nie zrozumiem dlaczego ci ludzie sa tak potwornymi analfabetami. “Niezadzialal”? a co to znaczy? nie znam takiego slowa. A juz takie kwiatki, jak pokemonowe “xDDDDDDDD” wskazuja dokladnie na wiek autora, lub stopien jego intelektualno-emocjonalnego rozwoju [lub na to, ze jedno nie nadaza za drugim]. Sick, sad world.

  5. @Łukasz: zauważ, że w x509v3 istnieje coś takiego jak Subject Alternative Name, gdzie możesz podać kilka domen które będą obsługiwane, Certum robi akurat to domyślnie jeśli podasz jako CN *www*.domena.pl, na przykładzie certyfikatu dla varlog.pl, wygląda to tak:

    X509v3 Subject Alternative Name:
    DNS:www.varlog.pl, DNS:varlog.pl

    Certyfikaty typu wildcard to zupełnie odrębna bajka.

  6. Ja bym jednak zastanowił się głębiej sugerując taką postać dyrektywy SSLCipherSuite, szczególnie jeśli chodzi o +LOW, +EXPORT nie mówiąc już o połączeniu SSLv2 (downgrade attack) z eNULL…

    http://www.openssl.org/docs/apps/ciphers.html

  7. @jamzed: Faktycznie, v3 pozwala zdefiniować dodatkowe nazwy, URI bądź adresy e-mail. Generowanie CSRa jest wtedy nieco bardziej “zakręcone”, ale da się.

  8. @Heinrich Ta script kiddies. Sprawdziłeś jaki miał login i hasło?

    @piko Mogliście napisać ” W naszym przypadku, korzystamy z usług firmy CERTUM.” A w nawiasie inne firmy “podpisujące”. Lub wymienić firmy i powiedzieć polecamy naszego sponsora CERTUM

    Pozdrawiam

  9. W przypadku home.pl X509v3 Subject Alternative Name nie przechodzi w tej postaci, co w Certum.

  10. to moze ktos wyjasni w jaki sposób za pomocą jednego certyfikatu podłączanego pod rozne subdomeny w obrębie jednej będę mogł je wszystkie zabiezpieczyc? Tzn jaki cert wykupic jak chcę miec SSLa na:

    domena.pl
    http://www.domena.pl
    http://ftp.domena.pl
    kasia.domena.pl
    http://ftp.kasia.domena.pl

    a i dlaczego caly art tyczy sie linucha? nic o windzie? pozdrawiam

  11. pytajnik, na:
    domena.pl
    http://www.domena.pl
    kasia.domena.pl
    http://ftp.domena.pl, odpowiedny byłby certyfikat Wildcard.

    Natomiast na:
    http://ftp.kasia.domena.pl, musiałbyś wykupić osobny certyfikat. Może to być np. Commercial lub Enterprise, z tego względu że Wildcard zabezpiecza tylko pierwszy stopień subdomen.

  12. […] Nie działa tu niestety żadna magia, i jeśli strona nie wspiera połączeń szyfrowanych (brak SSL na serwerze), to dodatek do niczego się nie […]

  13. Witam jeśli chodzi o opcję “subjectAltName” to aby różne wpisy działały trzeba wy go wypełnić w ten sposób:
    DNS:domena.pl,DNS:www.domena.pl,DNS:domena.com,DNS:www.domena.com
    Taki wpis pozwala na używanie ssl dla nazwy serwera:

    domena.pl , domena.com – z www i bez
    Jeśli zastosujemy tą opcję to przeglądarka będzie sprawdzać w tym polu domeny i jesli będą one poprawne do wpisanej uzna to za poprawną składnię i SSL nie poda błędu.
    Sam używam tej składni dla certyfikatów x509v3.

    Jeśli ktoś ma np. domena.pl, domena.eu, domena.com może zostosować tą opcję zmieniając tylko domenę najwyższego poziomu taki wpis wyglądał by:

    DNS:domena.pl,DNS:domena.eu,DNS:domena.com – bez www
    DNS:www.domena.pl,DNS:www.domena.eu,DNS:www.domena.com – z www

    W ten sposób nie trzeba kupować odzielnych certyfikatów dla poszczególnych domena czy subdomen czy nawet subdomen w innej subdomenie. Możemy wpisać tak:

    DNS:domena.pl,DNS:www.domena.pl,DNS:*.domena.pl

    Jak wpiszemy domena.pl to wyświetli się ssl dla domena.pl, jak wpiszemy http://www.domena.pl to wyświetli się http://www.domena.pl a jak wpiszemy http://ftp.domena.pl to wyświetli się *.domena.pl

    Twórcy certyfikatów przewidzieli to że z biegiem czasu będziemy potrzebować 1 certyfikatu ssl ale dla wielu wielu domen. opcja subjectAltName załatwia to wszystko.

    Dziękuję za powyższy tekst objaśniający. Jeśli macie jakieś pytania co do SSL proszę pisać.

  14. Ziew, podpisywanie certyfikatów, czyli nabijanie kasy dziwnym firmom za pseudo-bezpieczeństwo, eh… ;]

  15. Witam,

    a jak zrobić żeby w okienku potwierdzenia certyfikatu było “obsługiwany przez NAZWA FIRMY”? Mam Comodo standard SSL za 90 zł.

  16. Mam pytanie dotyczące szyfrowania połączenia do serwera www, a konkretnie punktu
    6. serwer weryfikuje dane i odszyfrowuje klucz
    Jakie dane weryfikuje serwer?

  17. Witam, ja zupełnie nie wiem o co chodzi z certyfikatami, a co najgorsze w najbliższym czasie będę musiał się z tym zmierzyć.

    • @Grzegorz – nie chcemy tu “szerzyć komercji” :) ale zupełnie serio i chętnie pomożemy w temacie – skontaktuj się z nami (na końcu artykułu znajdziesz namiary i korzystne informacje), zmierzymy się wspólnie z tematem!

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: