ASN.1 i DER

W poprzednim wpisie pokazałem, jak dostać się do typowych, wspieranych przez .NET, rozszerzeń certyfikatów wersji 3. Wśród wspieranych brakuje jednak np. tak ważnego rozszerzenia jak informacje o punktach dystrybucji CRL. Bez dodatkowych bibliotek możemy zobaczyć tylko wersję „RAW” tego rozszerzenia, czyli tak na prawdę ciąg liczb 16-bitowych.

Jest to dobry moment, żeby zajrzeć do RFC opisującego budowę rozszerzenia i przyjrzeć się notacji ASN.1 oraz spróbować na tej podstawie zdekodować format DER, w którym zapisane jest to rozszerzenie.

Czytaj dalejASN.1 i DER

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.

Czytaj dalejPKI – budowa certyfikatu (2) – rozszerzenia

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.

Czytaj dalejPKI – budowa certyfikatu (1)

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.

Czytaj dalejPKI – podstawy

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.

Czytaj dalejMassTransit i RabbitMQ – nazwy kolejek, exchange i wiadomości

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).

Czytaj dalejMassTransit i RabbitMQ- zdarzenia i komendy

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.

Czytaj dalejMassTransit i RabbitMQ

Zasoby i środowiska w Azure DevOps

Bazując na dokumentacji MS, środowiska (environments) są logicznymi kontenerami, które grupują zasoby. Zasoby, w tym kontekście, tak na prawdę oznaczają systemy, na których możliwe jest wykonanie wdrożenia aplikacji (deployment targets). Typowo definiuje się środowiska Dev, Test, Production itp., jednak logika jest tu dowolna.

Posiadając zdefiniowaną strukturę środowisk i poszczególnych zasobów, można ich używać w Pipeline (zarówno jednych jak i drugich) do wykonania jakiś operacji na systemach docelowo hostujących nasze aplikacje. Dodatkowo środowiska pozwalają na śledzenie historii wdrożeń wraz z informacją o commitach, na podstawie których dokonano konkretnego wdrożenia. Dokumentacja wskazuje również aspekty związane z diagnostyką i bezpieczeństwem.

W momencie pisania tego tekstu, Azure DevOps wspiera dwa typy zasobów – Kubernetes i Maszyny wirtualne. Te drugie (mimo swojej nazwy) to tak na prawdę dowolne systemy operacyjne, na których jesteśmy w stanie zainstalować oprogramowanie agenta. Właśnie instalacji agenta i przykładowej konfiguracji Pipeline chcę poświęcić ten wpis.

Czytaj dalejZasoby i środowiska w Azure DevOps

Lokalny, zdockerzyowany agent budowania Azure DevOps

Wraz z modułem Pipeline usługi Azure DevOps, posiadamy dostęp do agentów budowania, zlokalizowanych w chmurze Microsoftu. Jest to całkiem przydatne, bo nie wymaga żadnej konfiguracji z naszej strony. Ma jednak kilka ograniczeń. Przede wszystkim limitowany jest czas dostępu do takich agentów. Dodatkowo, z racji swojej lokalizacji w chmurze, nie będą mogły one w swobodny sposób komunikować się z systemami on-premise.

Czytaj dalejLokalny, zdockerzyowany agent budowania Azure DevOps