Szablonowy certyfikat dla Pingwina : Microsoft Certificates Services

Usługi certyfikacyjne Microsoftu działają w oparciu o szablony certyfikatu, w których zawarte są informacje dotyczące przeznaczenia certyfikatu wydanego na jego podstawie, atrybutów zabezpieczeń związanych z możliwością wydawania i użytkowania certyfikatu i tym podobnych rzeczy powiązanych z użytkowaniem Centrum Certyfikacji w strukturach Active Directory.
Bardzo często w takim środowisku musi się pojawić system działający pod kontrolą linuxa. Ot, choćby VMware ESX, które są hostowane przez Red Hat’a. W takich systemach wszelkie operacje związane z certyfikatami wykonywane jest przez pakiet openssl. Potrafi on niezmiernie dużo zrobić z automatu, jednakże jego funkcjonalność ogranicza się do działań kryptograficznych, jako że nie jest to narzędzie przeznaczone do integracji z Active Directory. Na szczęście jednak Microsoft swoje rozwiązanie automatyzujące wydawanie certyfikatów zmieścił w ramach standardu, i przy niewielkich modyfikacjach pliku konfiguracyjnego można także w Żądaniu Certyfikatu (Certificate Request) generowanym przy pomocy tego narzędzia umieścić także pole odpowiedzialne za szablon przy pomocy którego CA utworzy certyfikat.
Aby takie rozszerzenie dodać, trzeba przede wszystkim poinformować openssl’a o tym, że taki mechanizm istnieje. Robi się to przez rejestrację w pliku konfiguracyjnym openssl’a oid’u wykorzystywanego przez Microsoft do oznaczenia szablonu certyfikatu. W tym celu należy umieścić w sekcji

1
[ new_oids ]

linię

1
CertificateTemplate = 1.3.6.1.4.1.311.20.2

oraz zarejestrować tę sekcję jako definiującą niestandardowe oidy za pomocą linii

1
oid_section     = new_oids

umieszczonej na początku pliku, gdzie definiuje się zmnienne i sekcje. (obszar ten jest zbiorem wpisów podobnych do przytoczonego) Następnie koniecznym jest zdefiniowanie zestawu szablonów możliwych do wykorzystania przez openssl’a przy tworzeniu żądań certyfikatów. Wykonuje się to przez przypisanie zarejestrowanemu wcześniej oid’owi odpowiedniej nazwy szablonu. Jest to realizowane przy pomocy definicji sekcji nazwanej zgodnie z nazwą szablonu o następującej strukturze:

1
2
[ Template Name ]
CertificateTemplate     = ASN1:PRINTABLESTRING:Template Name

Przytoczona sekcja definiuje szablon o nazwie „Template Name”. Liczba sekcji nie jest ograniczona, należy je dla zachowania przejrzystości pliku konfiguracyjnego umieszczać bezpośrednio po sekcji

1
[ req ]

która odpowiedzialna jest za opcje związane z żądaniami certyfikatu.

Ostatnim krokiem jest sama generacja klucza prywatnego oraz żądania certyfikatu poświadczającego klucz publiczny z nim skojarzony. Wykonuje się to poprzez wydanie komendy:

1
openssl genrsa -out RSAkey.pem -des3 2048

celem utworzenia klucza, oraz następnie

1
openssl req -outform DER -out RSAreq.req -new -key RSAkey.pem -reqexts "Template Name"

Jak widać, poza typowymi argumentami podawanymi do komendy req występuje parametr

1
-reqexts

który odpowiada za wybór odpowiedniego szablonu certyfikatu który zostanie wykorzystany przez CA do utworzenia Certyfikatu.

Następnie pozostaje wysłać Request do Urzędu Certyfikacji i przetworzyć odpowiedź. Niestety na razie nie znam metody na wykonanie tego prosto spod Linuxa, więc należy się uciec do narzędzi windows’owych (np. certreq.exe), ale prace trwają.
O efektach będę informował 🙂

Microsoft Certification Services : Web Enrollment with Alternate Name

Certyfikaty to potężna tarcza. Stojący za protokołem ssl kryptosystem RSA daje mocną gwarancję pochodzenia danych i konkretną identyfikację osoby/maszyny z którą się komunikujemy. Problem jednak pojawia się wtedy, gdy pod jednym adresem IP, pod jednym domyślnym portem ssl 443 chcemy umieścić więcej niż jedną stronę. Gdy potrzebujemy więcej nazw dns dla naszych portali. Dlaczego? Ponieważ „Nazwa Tematu Certyfikatu” (Certificate Subject Name) może zawierać tylko jedną nazwę. I w przypadku certyfikatów ssl jest to nazwa dns. Oczywiście dla innych zastosowań może być to inna nazwa.
Szukając jakiejś wskazówki odnośnie metody utworzenia certyfikatu opiewającego na większą ilość nazw, zwróciłem się w stronę Windows Certificates Web Enrollment Service. Kreator w sumie przyjemny, szybciutko się wypełnia formularz, formatka activeX tworzy żądanie i wysyła do serwera. Jednak nic o zaawansowanych zastosowaniach nie ma tam wspomniane.
Po głębszym dochodzeniu odnalazłem pole żądania opisane jako „Atrybuty”. Niestety jak na złość w takich sytuacjach nigdzie na wierzchu dokumentacji do tego pola nie było. Po żmudnych poszukiwaniach udało mi się odnaleźć stronę. Dociekliwym polecam lekturę, tutaj przytaczam sedno sprawy.
Mianowicie pole to umożliwia dodanie do żądania dowolnych pól atrybutów zdefiniowanych standardem x509. Niestety, jak to często bywa, i w tym przypadku składnia nie jest wcale oczywista. Aby nasz certyfikat mógł poświadczać więcej niż jedną nazwę umieszczoną na tym samym porcie pod tym samym adresem IP musimy skorzystać z atrybutu „Alternatywnej Nazwy Tematu Certyfikatu” (Certificate Subject Alternate Name).
Na tę okoliczność Panowie z Redmont przygotowali następującą składnię:

1
san:dns=dns.name[&dns=dns.name]

na przykład:

1
san:dns=wawszczak.pr0.pl

czy

1
san:dns=wawszczak.pr0.pl&dns=poezja.pr0.pl

dla certyfikatu poświadczającego witrynę główną pr0.pl.
Aby jednak wszystko chodziło poprawnie nie należy zapomnieć o dodaniu do SAN także nazwy głównej witryny przedstawionej w polu CN (Common Name) certyfikatu.

Podsumowując, wraz z prostym interfacem Web’owym znów otrzymujemy bogatą funkcjonalność, szkoda tylko że właściwie w wersji instant.

Speech Control in Vista – czyli jak pogadać sobie z komputerem

Ostatnio w ramach odkrywania ciekawych zakamarków Visty, i szukania (momentami trochę na siłę) powodów uzasadniających przesiadkę z Windowsa XP na Viste znalazłem bardzo ciekawe uzupełnienie dla standardowego interface’u użytkownika. Mianowicie moduł rozpoznawania mowy. Działa on (dla użytkowników spoza anglosaskiego społeczeństwa, niestety) jedynie w oparciu o barbarzyński język galów, jednakże nie umniesza to jego funkcjonalności.

Ustrojstwo to pozwalana na wykonanie praktycznie dowolnej akcji związanej z interfacem użytkownika za pomocą głosu. Od tak elementarnych zadań jak zmiana aktywnego okna, wykonywanie akcji w oknach dialogowych czy uruchamianie programów z menu Start aż po tak wyrafinowane umiejętności jak dopasowanie wymówionego tekstu do umieszczonych na witrynie sieci Web linków i przejście na wskazaną stronę. Ponadto umożliwia edycję tekstów, a i w tym zakresie znane z Windows XP/2003 SAPI może się schować. Nie tylko bardzo rozbudowana gramatyka angielska, nie tylko możliwość literowania słów za pomocą funkcji „Spell it” ale też korekcja na bierząco, zaznaczanie, zmienianie, formatowanie. I to wszystko bez dotknięcia klawiatury.

Niestety rozwiązanie to wciąż nie jest wolne od wad. Jedną z najbardziej dokuczliwych jest częste wzbudzanie się systemu z powodu prowadzonych w języku polskim rozmów w obecności komputera z włączonym modułem. Innym problemem jest brak umiejętności odfiltrowania tego co mówi sam komputer od tego, co intencjonalnie mówi do komputera użytkownik. Ta wada sprawia, że na razie swobodna konwersacja z komputerem jest jeszcze nie możliwa.

Myślę, że ten krótki przegląd możliwości tego narzędzia daje choć wątły argument ZA Vistą.