tajemnice certyfikatów cz.3 - wracamy do podstaw

tajemnice certyfikatów cz.3 - wracamy do podstaw

  • Comments 2
  • Likes

Obsługa certyfikatów

Bry!

Kolejny kawałek dotyczący certyfikatów i zgodnie z tematem - opiszę bardzo podstawową czynność: samą operację żądania certyfikatu. Ponieważ jednak jestem z natury przewrotny, skomplikuję trochę scenariusz:

Zwykły użytkownik [tudzież niezwykły admin] potrzebuje specjalnego certyfikatu - np. certyfikat SAN, certyfikat dla serwera WWW z nazwą inną, niż domenowa, certyfikaty KRA itd... w pierwszej kolejności na serwerze musi być przygotowany i opublikowany szablon, ale to, co odróżnia takie certyfikaty to wymaganie zatwierdzenia przez managera certyfikatów

...oczywiście można utworzyć szablon i wyłączyć tą opcję, ale to mało rozsądne, a nie chcąc zapędzać się w dyskurs filozoficzny - po prostu przyjmijmy, że ta opcja jest włączona.

Jak teraz wygląda proces enrollmentu?

  1. użytkownik żąda certyfikatu
  2. cert pojawia się jako oczekujący na serwerze
  3. manager musi go zatwierdzić
  4. użytkownik musi zaciągnąć zatwierdzoną część publiczną i sparować z prywatną.

Trywialne? pozostaje odpowiedzieć - jak każdy z tych kroków zrobić. Oto jakie pojawiają się problemy i możliwości:

ad.1. Są co najmniej trzy sposoby aby wygenerować żądanie:

  • Za pomocą interfejsu WWW. Problemy jakie się pojawiają to:
    • trzeba znać adres - wcale nie takie oczywiste!
    • wynikają niekompatybilności - problematyczne zwłaszcza, jeśli ktoś jeszcze nie zmigrował CA co najmniej do Windows 2oo8
    • nie wszystkie szablony da się opublikować na WWW
  • Za pomocą narzędzi generujących request PKCS#10. Z tą metodą są same problemy - od samego wygenerowania poprawnego żądania, przez jego dostarczenie aż po wybór narzędzi. To metoda dobra jeśli rozmawiamy z zewnętrznym CA na jakimś paskudnym, opensource'owym systemie (; ogólnie raczej dla sys adminów/developerów niż użytkowników.
  • Za pomocą MMC 'certificates'. Łatwe, proste, przyjemne, na każdym komputerze, automatycznie zaciąga dostępne szablony - same zalety! czy aby napewno? do tego problemu za chwilę wrócę.

ad.2. Skąd manager certyfikatów ma wiedzieć, że pojawił się nowy certyfikat? Tutaj założę, że po prostu pełniący funkcję jest rzetelny i sprawdza czy są nowe żądania. W żyjącym środowisku przydałby się jednak jakiś automat powiadamiający... trzeba oprogramować CA. nie ma niestety standardowych mechanizmów.

ad.3. Tutaj nasz CM ma co najmniej dwa sposoby:

  • może skorzystać z GUI w postaci snap-ina "Certification Authority". Łatwe, przyjemne, dostępne na każdej stacji z RSAT - nie ma co się rozwodzić.
  • dla geeków jest certutil, który pozwala certyfikat zatwierdzić. znów skryptowanie.

ad.4. W zasadzie pomysł na ten wpis pojawił się właśnie dla tego punktu - jak taki certyfikat pobrać?! jeśli żądanie było przez stronę WWW, to wystarczy potem sprawdzić czy już został zatwierdzony i stamtąd pobrać. Ale w MMC Certificates nie ma opcji 'pobierz certyfikat'. Jedynym ze sposobów jest oczywiście aby CM wyeksportował certyfikat i przesłał nam mailem. Okazuje się, że użytkownik - nawet ambitny i świadomy, nie jest w stanie takiego certyfikatu pobrać bez pomocy. w sukus znów przychodzi kombinacja skryptowania i linii poleceń... to jeszcze za chwilę.

Linia poleceń

Ten wpis ma status 'podstawy' więc nie będzie tego dużo. Opiszę tylko kilka podstawowych operacji związanych z rządaniem certyfikatów.

Zatwierdzony przez administratora certyfikat można tak na prawdę pobrać - nawet zwykły user. trzeba jednak znać Request ID.

Jeśli mamy uprawnienia administratora na Issuing CA, to możemy się go zdalnie odpytać o 'pending certificates'. Tu jednak kolejna niespodzianka - niestety aby polecenie zadziałało wymagane jest zainstalowanie RSAT dla CA ): a w takim przypadku, jeśli nie wymagamy autoamtyzacji, wygodniej to zrobić z GUI. niemniej:

certutil -view -config "<CA_SERVER_NAME>\<CA_NAME>" -Restrict "Request Disposition=9" -out "Request ID, Request Submission Date, Request Common Name, Requester Name, Request Email Address, Request Distinguished Name, CertificateTemplate, Request Disposition" 

Znając ID można pobrać certyfikat za pomocą drugiego, podstawowego narzędzia - certreq:

certreq.exe -retrieve -config "<CA_SERVER_NAME>\<CA_NAME>" <OutPutCertFile.cer>

I na koniec zostaje sklejenie tak otrzymanej częsci publicznej z prywatną. Oczywiście aby to zrobić musimy być zalogowani na tym samym koncie i komputerze, na którym generawany był request:

certreq -accept <OutPutCertFile.cer>

W Windows 8/Server 2o12 jest nowy moduł Powershell - PKI. Jak to z powershell - jest łatwiej i przyjemniej. Jest również polecenie get-Certificate, które również wiele automatyzuje - niestety statystyki pokazują, że póki co w8 stanowi mały procent klientów w domenach firmowych. Trzeba zatem jeszcze chwilę poczekać - i migrować ASAP (:

 

Drobna ciekawostka na koniec  - gdzie przechowywany jest klucz prywatny po wygenerowaniu requestu?

a fizycznie są to dwa miejsca:

  • $env:userprofile\AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates
  • HKCU\Software\Microsoft\SystemCertificates\REQUEST\CRLs

 

Podsumowanie

  • Z windows 8/Server 2o12 świat staje się prostszy
  • Brakuje standardowych automatów dla CA.
  • Najlepszym wyborem dla użytkownika pozostaje interfejs WWW

Refs

 eN.

autor: nExoR

 

Comments
  • Re #4

    na końcówce wystarczy zrobić

    certutil.exe -pulse

    i podpisany klucz publiczny sam się pobiera

    zamiast narzekać, wystarczy znać się na rzeczy przed pisaniem na blogu

  • o, super! skoro tak świetnie się znasz to pomóż i napisz jak korzystać 'certutil -pulse' do pobrania requestów bez flagi 'autoenroll'? i jak uruchomić go przez użytkownika bez uprawnień administratora lokalnego dla certów użytkownika?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment