Tag .net

PKI – budowa certyfikatu (2) – rozszerzenia

Przedstawione poprzednio certyfikaty w wersji 1 oraz 2 są dosyć ubogie biorąc pod uwagę informacje w nich zapisane. Tak na prawdę znajdziemy tam tylko daty ważności oraz nazwy podmiotu i jednostki, która podpisała certyfikat.

W wersji 3 certyfikatów znajduje się pole z rozszerzeniami. Są to dodatkowe atrybuty. Mogą zawierać np. informacje ułatwiające identyfikację podmiotu, do którego należy certyfikat albo informacje o możliwościach kryptograficznych. Ten wpis będzie właśnie o nich.

PKI – budowa certyfikatu (1)

Poprzednio opisałem podstawowe pojęcia dotyczące infrastruktury klucza publicznego. Teraz chciałbym bliżej zająć się samym certyfikatem. Tym jaką on ma budowę, które elementy są ważne, a które opcjonalne.

Będzie to bardzo ogólny opis dotyczący podstawowych elementów certyfikatów. Po więcej mogę odesłać do RFC 5280. Natomiast w temacie rozszerzeń planuję dedykowany wpis.

PKI – podstawy

Znajomi i współpracownicy wiedzą, że mam lekkiego jobla w temacie certyfikatów i pki. 😉 Wracam do tego tematu bardzo często od czasów studiów. Zawodowo można powiedzieć, że opiekuję się dwoma firmowymi infrastrukturami klucza publicznego – zarówno windowsowym (w ramach ad) jak i w oparciu o OpenSSL. Jednocześnie bardzo nie podobają mi się szeroko dostępne aplikacje GUI służące do zarządzania tymi. Narzędzia CLI są zaś mocno uciążliwe.

Dlatego od bardzo dawna myślę o napisaniu czegoś przyjemniejszego w obyciu.

Ten dokument, mam nadzieje, otworzy serie wpisów o programowych zabawach pki z poziomu .net i C#. Nie wiem czy finalnie uda się napisać żyjącą aplikację, ale mam zamiar popełnić kilka testów i prototypów.

Na start trochę teorii omawiającej czym jest PKI i banalny program, żeby chociaż trochę kodu się pojawiło.

MassTransit i RabbitMQ – nazwy kolejek, exchange i wiadomości

Logika nazywania kolejek i exchange była dla mnie na początku mocno niezrozumiała. Nie mogłem też znaleźć w dokumentacji nic, co by to jasno wyjaśniało.

W tym tekście postaram się opisać kilka przykładów, które pokazują jak to działa.

Pierwszy przykład to najprostsza konfiguracja – aplikacja publikująca wiadomości, aplikacja konsumująca wiadomości i współdzielony projekt z definicją rekordów wiadomości.

Drugi przykład jest podobny, jednak brak jest wspólnego projektu, a każdy z programów ma własną definicje rekordów wiadomości.

Trzeci przykład pokazuje jak skonfigurować exchange i kolejki pozwalające na użycie większej ilości konsumentów.

MassTransit i RabbitMQ- zdarzenia i komendy

W systemach komunikujących się za pomocą wiadomości i systemów kolejkowych, wyróżnia się dwa typy wiadomości – komendy (commands) i zdarzenia (events). Ich obsługa przez system powinna się nieco różnić.

Przedstawiony tym razem przykład obejmuje jeden program publikujący wiadomości będące komendami i zdarzeniami oraz dwa programy konsumujące te wiadomości.

Wiadomości-zdarzenia powinny trafić do wszystkich zainteresowanych konsumentów. Wiadomości-komendy powinny zaś zostać odebrane i przetworzone przez jednego konsumenta (tak, żeby nie zostały przetworzone wielokrotnie).

MassTransit i RabbitMQ

Do tej pory używałem bibliotek dostarczanych wraz z RabbitMQ, jednak jakiś czas temu, przy okazji jednego z projektów, zaproponowano mi użycie MassTransit do obsługi wymiany wiadomości miedzy mikroserwisami. Okazało się, że jest to całkiem ciekawe rozwiązanie.

MassTransit to otwarty framework wprowadzający warstwę abstrakcji nad systemem wymiany komunikatów. Oficjalnie wspierane są RabbitMQ, Azure Service Bus i Amazon SQS.

Poniżej przykład użycia w aplikacji producenta i konsumenta wiadomości.