tajemnice certyfikatów cz.3 - wracamy do podstaw

Obsluga certyfikatów

Bry!

Kolejny kawalek dotyczacy certyfikatów i zgodnie z tematem - opisze bardzo podstawowa czynnosc: sama operacje zadania certyfikatu. Poniewaz jednak jestem z natury przewrotny, skomplikuje troche scenariusz:

Zwykly uzytkownik [tudziez niezwykly admin] potrzebuje specjalnego certyfikatu - np. certyfikat SAN, certyfikat dla serwera WWW z nazwa inna, niz domenowa, certyfikaty KRA itd... w pierwszej kolejnosci na serwerze musi byc przygotowany i opublikowany szablon, ale to, co odróznia takie certyfikaty to wymaganie zatwierdzenia przez managera certyfikatów

...oczywiscie mozna utworzyc szablon i wylaczyc ta opcje, ale to malo rozsadne, a nie chcac zapedzac sie w dyskurs filozoficzny - po prostu przyjmijmy, ze ta opcja jest wlaczona.

Jak teraz wyglada proces enrollmentu?

1. uzytkownik zada certyfikatu
2. cert pojawia sie jako oczekujacy na serwerze
3. manager musi go zatwierdzic
4. uzytkownik musi zaciagnac zatwierdzona czesc publiczna i sparowac z prywatna.

Trywialne? pozostaje odpowiedziec - jak kazdy z tych kroków zrobic. Oto jakie pojawiaja sie problemy i mozliwosci:

ad.1. Sa co najmniej trzy sposoby aby wygenerowac zadanie:

• Za pomoca interfejsu WWW. Problemy jakie sie pojawiaja to:
  • trzeba znac adres - wcale nie takie oczywiste!
  • wynikaja niekompatybilnosci - problematyczne zwlaszcza, jesli ktos jeszcze nie zmigrowal CA co najmniej do Windows 2oo8
  • nie wszystkie szablony da sie opublikowac na WWW
• Za pomoca narzedzi generujacych request PKCS#10. Z ta metoda sa same problemy - od samego wygenerowania poprawnego zadania, przez jego dostarczenie az po wybór narzedzi. To metoda dobra jesli rozmawiamy z zewnetrznym CA na jakims paskudnym, opensource'owym systemie (; ogólnie raczej dla sys adminów/developerów niz uzytkowników.
• Za pomoca MMC 'certificates'. Latwe, proste, przyjemne, na kazdym komputerze, automatycznie zaciaga dostepne szablony - same zalety! czy aby napewno? do tego problemu za chwile wróce.

ad.2. Skad manager certyfikatów ma wiedziec, ze pojawil sie nowy certyfikat? Tutaj zaloze, ze po prostu pelniacy funkcje jest rzetelny i sprawdza czy sa nowe zadania. W zyjacym srodowisku przydalby sie jednak jakis automat powiadamiajacy... trzeba oprogramowac CA. nie ma niestety standardowych mechanizmów.

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

• moze skorzystac z GUI w postaci snap-ina "Certification Authority". Latwe, przyjemne, dostepne na kazdej stacji z RSAT - nie ma co sie rozwodzic.
• dla geeków jest certutil, który pozwala certyfikat zatwierdzic. znów skryptowanie.

ad.4. W zasadzie pomysl na ten wpis pojawil sie wlasnie dla tego punktu - jak taki certyfikat pobrac?! jesli zadanie bylo przez strone WWW, to wystarczy potem sprawdzic czy juz zostal zatwierdzony i stamtad pobrac. Ale w MMC Certificates nie ma opcji 'pobierz certyfikat'. Jedynym ze sposobów jest oczywiscie aby CM wyeksportowal certyfikat i przeslal nam mailem. Okazuje sie, ze uzytkownik - nawet ambitny i swiadomy, nie jest w stanie takiego certyfikatu pobrac bez pomocy. w sukus znów przychodzi kombinacja skryptowania i linii polecen... to jeszcze za chwile.

Linia polecen

Ten wpis ma status 'podstawy' wiec nie bedzie tego duzo. Opisze tylko kilka podstawowych operacji zwiazanych z rzadaniem certyfikatów.

Zatwierdzony przez administratora certyfikat mozna tak na prawde pobrac - nawet zwykly user. trzeba jednak znac Request ID.

Jesli mamy uprawnienia administratora na Issuing CA, to mozemy sie go zdalnie odpytac o 'pending certificates'. Tu jednak kolejna niespodzianka - niestety aby polecenie zadzialalo wymagane jest zainstalowanie RSAT dla CA ): a w takim przypadku, jesli nie wymagamy autoamtyzacji, wygodniej to zrobic 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" 

Znajac ID mozna pobrac certyfikat za pomoca drugiego, podstawowego narzedzia - certreq:

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

I na koniec zostaje sklejenie tak otrzymanej czesci publicznej z prywatna. Oczywiscie aby to zrobic musimy byc zalogowani na tym samym koncie i komputerze, na którym generawany byl request:

certreq -accept <OutPutCertFile.cer>

W Windows 8/Server 2o12 jest nowy modul Powershell - PKI. Jak to z powershell - jest latwiej i przyjemniej. Jest równiez polecenie get-Certificate, które równiez wiele automatyzuje - niestety statystyki pokazuja, ze póki co w8 stanowi maly procent klientów w domenach firmowych. Trzeba zatem jeszcze chwile poczekac - i migrowac ASAP (:

 

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

a fizycznie sa to dwa miejsca:

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

 

Podsumowanie

• Z windows 8/Server 2o12 swiat staje sie prostszy
• Brakuje standardowych automatów dla CA.
• Najlepszym wyborem dla uzytkownika pozostaje interfejs WWW

Refs

• disposition values
• certificates tools and settings
• PKI cmdlet's [w8/w12]
• PKI cmdlets on codeplex
• certutil management examples

 eN.

autor: nExoR

Comments

• Anonymous
  January 01, 2003
  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?

• Anonymous
  March 26, 2013
  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