Skip to Content

IT nieuczesane.
category

Category: PKI

Tajemnicze Certyfikaty

wpis na blogu technet. nie ma w nim ‚q’ (;

eN.

There is a problem with this website’s security certificate

standardowy komunikat IE informujący, że coś jest nie tak z certyfikatem. dodatkowo dwie opcje: wejdź lub wyjdź. opcja kontynuacji obarczona jest informacją żeby tego raczej nie robić, że to niebezpieczne i tak dalej…

no dobra… ale chciałbym zobaczyć ten certyfikat żeby móc podjąć decyzję i co w ogóle jest nie w porządq. tylko żeby go zobaczyć muszę najpierw wejść.. czyli teoretycznie jest już za późno…

jaka w tym logika?

eN.

Szyfrowanie poczty certyfikatem x5o9

*UPDATED…again*

pamiętam, że na uczelni – czyli ponad dekadę temu – każdy gówniarz, włączając mnie, wiedział co to PGP, miał certyfikat i się tym bawił. oczywiście ponieważ nasze dane były bardziej super fajne niż super tajne, po dwóch-trzech miesiącach każdy się nudził zabawą i certyfikaty poszły w zapomnienie… a było tak:

Projekt PGP został zapoczątkowany w 1991 przez Philipa Zimmermanna i rozwijany z pomocą społeczności programistów z całego świata[1].

Wydarzenie to stało się pewnym przełomem – po raz pierwszy zwykły obywatel dostał do ręki narzędzie chroniące prywatność, wobec którego pozostawały bezradne nawet najlepiej wyposażone służby specjalne.

Wikipedia

Ponad 2o lat temu powstała idea, aby przeciętny obywatel mógł zabezpieczyć swoją pocztę.wtedy chodziło o zabezpieczenie się przed rządem – to było jeszcze echo po zimnej wojnie. po tylu latach bezpieczeństwo jest niemal wbudowane w każdy produkt i dostępne wszem i wobec, więc można przyjąć, że bułka z masłem coś takiego skonfigurować…

podstawowym problemem PGP jest zaufanie do certyfikatu, które opiera się na wymianie kluczy – nawzajem lub przez jakieś ‘zaufane miejsca’. mało wygodne przy użyciu ‘publicznym’ – lepiej skorzystać z zaufanych serwerów Root CA, które poświadczają tożsamość. w sumie na oddzielną dywagację, bo standardowy certyfikat można wystawić na “reksia kosmonautę” – i tak nikt nie wyryfiqje tożsamości przy najniższej klasie bezpieczeństwa… ale o nie o taki cel wpisu. chodzi o ideę szyfrowania wiadomości jako-takiego, oraz o weryfikację na ile to jest zadanie proste po 2o latach od rozgłosu, jaki osiągnęło PGP…

testy dotyczyć będą certów x5o9.

 

Ceryfikat

po pierwsze okazuje się, że zniknęły z rynq praktycznie wszystkie portale wydające darmowe certyfikaty do poczty z firm, które są globalnie w Trusted Root CAs. zostało comodo i masa ‘odsprzedawaczy’ którzy kierują na stronę comodo. jak dłużej się poszuka, znajdzie się “coś tam”:

  • CAcert – ale jak można ufać komuś, kto nawet nie potrafi ustawić kodowania znaków na stronie? poza tym RootCA jest dystrybuowany społecznie, a więc trzeba go ręcznie importować
  • startssl – początkowo go nie znalazłem, wymaga podania sporej ilości danych, rejestracja nie jest automatyczna.

no więc niech będzie comodo – w sumie co za różnica…. potem przetestowałem na certyfikacie startssl – i nawet się udało… ale to za chwilę.

Klient

po drugie żadna poczta publiczna webmail nie obsługuje certyfikatów – gmail, live/hotmail czy inne wynalazki. a więc pozostaje to poza zasięgiem większości userów. warto byłoby zerknąć na klienty na urządzenia mobilne, ale to zostawiam innym [będę wdzięczny za informacje – może korzystacie z jakiegoś klienta wspierającego szyfrowanie?]. więc przetestujmy na najpopularniejszych stacjonarnych klientach poczty.

dla testu stworzyłem dwa konta na jakieś tam skrzynki i wygenerowałem certyfikaty comodo i startssl. dwa konta w windows, oczywiście zaimportowane na krzyż po certyfikacie prywatnym jednego i publicznym drugiego. bułka z masłem…

[po trzecie] no może nie do końca – nie dla common-usera. ponieważ windows nie pozwala ani przesłać pliku .cer, ani kiedy się go zzipuje, rozpakować. trzeba wejść we właściwości i go odblokować – kolejne utrudnienie, które dla kogoś z IT może być śmieszne, ale dla przeciętnej osoby wymaga sporo wysiłku. pozostaje jeszcze jedna sprawa – skąd taki cer wziąć. i znów – dla mnie oczywiste jak wyeksportować część publiczną – ale nie jest to metoda ‘użytkownikowa’. raczej zaliczyłbym to do ‘zadań administracyjnych’.

idziemy dalej. odpalam Windows Live Mail 2o12 – bez trudu konfiguruje się własny certyfikat. drugi – publiczny, już zaimportowany i sprawdzony – siedzi w other users i wszystko się zgadza, cały łańcuch weryfikowalny, email ok. szyfruję wiadomość, wysyłam… i dupa “Digital ID is missing”. godzina ślęczenia, sprawdzania, bez szans. po prostu się nie da. wszędzie opisy jak wyłączyć szyfrowanie, nigdzie jak je skonfigurować – owszem, gdzieniegdzie opisy jak skonfigurować swój, ale nigdzie jak prawidłowo zaimportować czyjś. brak instrukcji. mam wrażenie, że robię coś źle – więc weryfiqję dalej.

testuje outlooka 2o1o. qrva – to samo! nie do wiary. nie mówiąc o tym, że sama konfiguracja czy szyfrowanie wymaga trochę umiejętności, ze względu na to przez ile okien trzeba się przeklikać w outlooku żeby to skonfigurować – przeciętny user się obsra a tego nie znajdzie. no ale to raczej korpo-aplikacja.
może głupi jestem – nie wykluczam, poza tym jest późno, a ja pracuje 17tą godzinę [ale update piszę następnego dnia i nadal nie jestem pewien – co robię źle?]… jeszcze jeden test:

‘by the book’, czyli tak, jak w zamyśle powinna wyglądać wymiana kluczy… najpierw z certami comodo.
wysyłam z jednego konta podpisaną wiadomość. dochodzi do nadawcy i .. jest prawidłowo zweryfikowana. dodaję kontakt do książki adresowej przez opcje tegoż zweryfikowanego kontaktu… – już trochę mniej oczywiste i trzeba się nieźle przeklikiwać ale w końcu działa! nic dodać nic ująć – super intuicyjny system, security w każdym domu! no to teraz to samo w drugą stronę – dla Live Mail… podpisuje wiadomość, wysyłam, przychodzi, zweryfikowana, przekilqje się przez info o certach i znajduję opcję “dodaj do książki”… i dupa. kontakt jest ale certu nie ma. następnego dnia zrobiłem ten sam test ale z certami startssl: ZADZIAŁAŁO! i to z Live Maile po obu stronach. nie będę już testował czy wczoraj coś namodziłem, czy certy comodo są do d. ale jest jedna rzecz, która mnie bardzo zastanawia: czemu zaimportowany cer nie jest rozpoznawany??

postanowiłem wyciągnąć ciężką artylerię. stawiam własny CA i tworzę template dla szyfrowania poczty. generuję cert z tym samym mailem, exportuję część publiczną instaluję… nie ma żadnych problemów z importem – zarówno outlook jak live mail łykają taki cert bez mrugnięcia ekranem. porównuję certy żeby zobaczyć różnicę:

  • key usage: dla comodo digital signature i key encipherment; dla mojego – tylko key encipherment.
  • enhanced key usage: w obu Secure Email. comodo ma jeszcze własny OID do logowania na swoich stronach. nieważne.
  • CN – ten sam, czyli E=email
  • Application policies: brak w certach z zewnętrznych CA. MCA dodaje ‘Secure Email’

o co c’mon? certutil weryfikuje bez zajęknięcia. jedyna różnica jaką znalazłem to to, że w wygenerowanym przez MCA jest Application Policy, którego nie ma w certach zewnętrznych – ale to nie powinno mieć znaczenia. tej części nie udało mi się rozwiązać.

na koniec biorę pod młotek thunderbirda…

nie lubię tego produktu – jest toporny, brzydki i nie korzysta z systemowego cert stora. o ile kojarzę to dodatkowo TB i FF mają oddzielne cert story! ale pal to licho – nie o to chodzi. próbuję dodać publiczny email cert – dupa. niezaufany. okazuje się, że brakuje ostatniego ogniwa zaufania – dla COMODO email. exportuję ze stora systemowego, dodaję do TB. działa.

Konkluzja

na jakim poziomie trzeba być userem, żeby zacząć korzystać z szyfrowania poczty? można x5o9 zastąpić openpgp czy GNUPG i szyfrowanie wiadomości z linii poleceń. tak, wiem, jest jakiś dodatek do systraya, który jakoś to automatyzuje – ale co z tego? target użycia pozostaje ten sam. zresztą opinię czy jest łatwiejsze czy trudniejsze pozostawię – może będę miał siłę to przetestować?

pomimo dwóch dekad – szyfrowanie poczty pozostaje instytucjom i zdesperowanym. zwykłym, ani nawet trochę mniej zwykłym userom, po prostu się to nie uda. być może drążyłbym jakąś teorię spisq – ale raczej projektu opensource typu mozilla nie podejrzewałbym o przyłączenie się do niego. żaden klient nie ułatwia wymiany kluczy, o ile w ogóle je obsługuje… a może nie ma się co dziwić? ostatnio częściej się słyszy o uzależnieniu od porali społecznościach – ludzi, którzy mają na bieżąco publikowane swoje położenie odczytane z GPS, każda myśl przelana od razu pro publico… ale czy bono to już wątpię. ‘jestem na wakacjach’, ‘właśnie wylało mi się mleko, cholera ale się pobrudziłem’, ‘ale walnąłem kloca! [+zdjęcie]’ … minęło 2o lat i ze skrajnej paranoi i strachu przez rządem, ludzie przenieśli się w epokę totalnej publikacji siebie.

tego nie rozumiałem wczoraj, będąc zmęczony, a dziś wydaje mi się oczywiste – nie ma popytu – nie ma podaży. kto potrzebuje – kupi, albo się nauczy.

eN.

SSTP czy L2TP?

od wersji w2k8 jest nowy, ‘wbudowany’ typ VPN – Secure Socket Tunneling Protocol, czyli Microsoftowa implementacja SSL VPN dla Windows. ogólnie świetny pomysł – świat sieci generalnie zmierza w kierunku ‘all-over-443’, pojedynczy otwarty port, nie ma konieczności obsługi GRE na brzegu czy innych protokołów wspierających, czyli łatwość działania w fajerłolowanych środowiskach (;

no więc przestawiać się w pełni na SSTP czy pozostać przy starym dobrym L2TP? pomimo, iż od wprowadzenia SSTP minęło już kilka lat, ma niestety zbyt wiele wad beniaminka:

  • natywnie wspierany tylko przez systemy Vista SP1+
    • szczęśliwie są aplikacje firm 3cich, obsługujące SSTP dla Linux i Windows XP.
  • wymaga certyfikatu serwera – nie jest to problem w środowisku domenowym, gdzie cert CA jest dystrybuowany via GPO jednak robiąc VPN dla osób ‘z zewnątrz’ trzeba pamiętać aby przesłać im cały cert chain do zaimportowania, ew. mieć wykupiony cert podpisany przez komercyjny CA
  • dodatkowym warunkiem są dostępne listy CRL. zazwyczaj wewnętrzne CA mają skonfigurowane AIA i CRL wyłącznie z wewnętrznymi adresami. ciężko powiedzieć czy to błąd czy nie – zależnie od założeń, ale dla VPN to krytyczne. VPN zestawia się zazwyczaj z Internetu, a to oznacza, że nie będzie dostępu do CRL i AIA. standardowo SSTP VPN weryfikuje CRL i nie mogąc ich sprawdzić odrzuci połączenie. są opcje:
    • albo poprawi się certyfikaty, umieszczając CRL dostępny z Internetu – co może być dość pracochłonne w ‘żywym’ PKI
    • albo wyłączy się weryfikację CRL dla SSTP VPN. to również może być dość upierdliwe – zarówno dla własnych klientów jak zewnętrznych
    • to, czego nie testowałem, to czy całość zadziała z jakimś certyfikatem self-signed z pustym CRL. to by ułatwiło, ale nie wiem czy jest wykonalne.
  • brak klientów dla urządzeń mobilnych – nawet na Windows Phone. być może będzie klient dla Android – ale to tryb przypuszczający w czasie przyszłym /:

w efekcie: standardowo – jeśli nie wiadomo która opcja, najlepiej użyć obu na raz i włączyć zarówno L2TP jak SSTP. dzięki temu, przy prawidłowej konfiguracji [zwłaszcza w kwestii certyfikatów] klienci firmowi z w7 będą mieli dostęp do sieci LAN nawet będąc gdzieś gdzie są puszczone tylko 80/443, a pracownicy zewnętrzni oraz userzy z XP będą mieli protezę w postaci standardowego L2TP.

eN.

Certificate request processor: object already exists. 0×8009000f (-2146893809)

podczas generowania certyfikatu przy pomocy certreq można natknąć się na taki ciekawy błąd. ciekawy – ponieważ nie mogłem go nigdzie wygooglać a natrafiałem na niego dość często.

błąd pojawia się w momencie, jeśli rozpocznie się generowanie certyfikatu ale z jakiś-tam powodów nie uda się zakończyć. certyfikaty to dziwne zwierzęta i mają legowiska w różnych miejscach systemu. w tym konkretnym przypadku za pierwszym razem wpisałem złą nawę szablony w pliq ini. za drugim wyglądało to tak:

>certreq –new certreq.inf user.req
Active Directory Enrollment Policy
   {GUID}
   ldap:
DumpVarianStringWorker: 0: “…” Certificate request processor: object already exists. 0x8009000f (-2146893809).

i nigdzie odpowiedzi. okazało się, że te konkretne requesty nie są przechowywane jak pan gejst przykazał w rejestrze tylko w %userprofile%AppDataRoamingMicrosoftCryptoRSA{UserSID} – usunięcie tego katalogu wywaliło tymczasowe informacje o starym requescie i całość zahulała

gdzie jeszcze indziej są fragmenty związane z certyfikatami:

  • cache CRL można usunąć ręcznie nie czekają na automatyczne przedawnienie przy pomocy certutil –crlcache * delete
  • klucze prywatne i certy trzymane są w %userprofile%AppDataRoamingMicrosoftSystemCertificates
  • są tam też przechowywane erquesty wygenerowane za pomocą MMC – czyli m.in. klucz prywatny. requesty zresztą widać w MMC ‘certmgr.mmc’ w gałęzi ‘Certificates Enrollment Requests’
  • no i teraz okazuje się że jest jeszcze ten CryptoRSA… o kórym nigdzie się nie doczytałem wcześniej.

eN.

unizeto

kontynuując piątkowe walenie głową w ścianę muszę się jeszcze wyrzygać na Unizeto. znajomy poprosił mnie o pomoc przy wygenerowaniu i instalacji certyfikatu SSL. pierwszy odruch – chłopaq, bierz w thawte. korzystałem z tego z ich usług kilqkrotnie i nie miałem żadnych problemów. niestety – płatność tylko w peelenach i w ogóle ze względów politycznych firma polska. nie za bardzo wiedząc co robię postanowiłem zaufać Unizeto – Certum. czy to firma państwowa? bo cały ten portal wygląda jak napisany przez syna pana prezesa i ‘dla oszczędności’ postawiony na opensource’owych rozwiązaniach konfigurowanych przez studentów. kilka przykładów:

pierwsze kroki standard: zaqp przez WWW, wysłanie faktury, płatność, weryfikacja doqmentów. so far so good. no ale skoro zostały zaqpione certy to teraz chciałbym się zalogować do jakiegoś panelu zarządzania certyfikatami. po kilqnastu minutach walki postanawiam skorzystać z ‘chat z konsultantem’. dostaję odpowiedź ‘nie ma panelu zarządzania. dostaje pan zdrapkę i to się wpisuje <blablabla>’. jak nie ma panelu zarządzania to jak się nimi zarządza? poza tym wpisywałem jakieś hasło i login… to po co? ach. potem okazuje się, że jednak jest jakiś-tam panel i jest to e-koszyk w sklepie. super. na stronie głównej jest guzik ‘masz już konto w e-sklepie? zaloguj się’. ale logowanie się nie udaje. po jakiś dziwnych manewrach trafiam na inną stroną [potem już wiem, że jest druga strona, bo linka do niej jakoś niełatwo znaleźć] – i tam logowanie o dziwo działa [nie wiem w końcu czy są dwa sklepy…?] następnego dnia nie działa – odkrywam, że nazwa użytkownika, którym jest email, jest case-sensitive. od kiedy maile są case-sensitive nie wiem. śmierdzi linuxem q: dobra. umiem się zalogować – sukces! ale w wyniq tych wszystkich operacji klucz prywatny nie chce się sparować z publicznym [zapytanie pkcs generowałem ich interfejsem]. muszę zrevokować cert. zaczyna się jazda czyli komunikacja z działem reklamacji – ponieważ proces revoke, jak w każdym szanującym się systemie działającym przez WWW jest w pełni automatyczny, czyli wymaga telefonu, pani Kasi po drugiej strony, dwóch adresów mailowych i dużo cierpliwości. i teraz kolejne ułatwienie. w klepie dostaje się cert o numerze seryjnym np. 34590876. kiedy się go dostaje wygenerowanego ma juz numer 0x345678, kiedy się go odwołuje – dostaje się info, że cert o numerze seryjnym 3430008 został odwołany. qrva mać! no szybkie przeliczenie i przynajmniej jeden numer – przy odwołaniu – po przeliczeniu DEC-HEX się zgadza. fajnie się też koresponduje z reklamacjami kiedy pytają o numer seryjny – sami chyba mają problemy ze zorientowaniem się o który chodzi.

wnioski:

  • NIDY WIĘCEJ
  • używaj openSSL
  • polska… polska… to gdzieś w afryce?

jeśli macie doświadczenia z innymi urzędami w polsze to plz o wpis w komentarzu bo następnym razem.. szkoda zdrowia po prostu.

eN.

Zaufany certyfikat za darmo?

Ostatnio dużo sie zmienia w świecie zaufanych wystawców certyfikatów. Najpierw GoDaddy przepuścił ofensywę na pozycje, na których okopały się Thawte, Verisign czy Equifax, wypuszczając najprostsze zaufane certyfikaty za 50$ rocznie (a nie jak inni >150$). Po jakimś czasie ceny spadły nawet < 30$ rocznie, co skutecznie wykosiło konkurencje dla najtańszych certyfikatów. Odstraszać jedynie może niezbyt „poważna” nazwa wystawcy.

Ale to nie wszystko – 22 sierpnia Microsoft do listy zaufanych urzędów certyfikacji dopuścił StarCom. Oznacza to, że wszystkie wersje Windows 2008 R2 oraz Windows 7 mają już wbudowanego tego wystawcę. A starsze systemy operacyjne automatycznie dostają aktualizacje za pomocą Windows Update.

Co nam daje StarCom? Darmowe certyfikaty poziomu 1. Zaufane przez większość przeglądarek z IE, oraz także przez Google Chrome, Mozillę FireFox, czy Safari na jabłku . Niestety brakuje jeszcze wsparcia dla zaufania w Operzę, czy istnienia w domyślnych magazynach na Windows Mobile.

Oczywiście certyfikaty poziomu 1mają wady – weryfikowana jest tylko nazwa domeny wystawcy, a informacje o organizacji nie są wyświetlane przy certyfikacie.

Ale i tak lepszy certyfikat poziomu 1, niż lokalny. W szczególności, kiedy jest za darmo.

https://www.startssl.com/

tworzenie website certSrv

jeśli zainstaluje się rolę Server Certificate nie mając IIS – site ten nie jest później generowany automatycznie. Jakoś ciężko było wygooglać w jaki sposób go odtworzyć, więc w związku z tym:

certutil -vroot

trywialne, he? (: niestety nie przyjmuje żadnych parametrów, a więc jeśli chce się np. aby site działał na niestandardowym porcie, trzeba całość zrobić ręcznie:

  • załóż nowy site na wybranym porcie, fizycznie wskazujący na pusty katalog. potem można tam umieścić plik przekierowania na /certsrv
  • załóż wewnątrz tego siteu katalog wirtualny, wskazujący na %windir%system32certsrv . katalog musi mieć możliwość odpalania skryptów (script only).
  • załóż pulę aplikacyjną dla tego katalogu (powinna się pojawić .netowa ikonka, że to aplikacja)
  • załóż dwa site’y virtualne dla katalogów %windir%system32certsrvcertEnroll i %windir%system32certsrvcertControl (nie powinny być jako aplikacja)

et voila!

%d bloggers like this: