HashiCorp Vault PKI & ACME

11 listopada 2024 Jarek

W dzisiejszym wpisie pokażę w jaki sposób używać silnika PKI w HashiCorp Vault do zamawiania certyfikatów. Na wstępie omówię w jakich sytuacjach może nam się przydać ten silnik, a następnie przejdziemy do konfiguracji trzech przypadków. W pierwszym z nich Vault będzie pełnił rolę zarówno ROOT, jak i intermediate CA, natomiast w drugim wykorzystamy offline ROOT CA. W ostatniej części wpisu za pomocą protokołu ACME oraz narzędzia Certbot połączymy nasze rozwiązanie tak, aby automatycznie zarządzać pełnym cyklem życia certyfikatu. Zapraszam do lektury!

Spis treści

Vault PKI Secret enginie

Vault PKI (Public Key Infrastructure) odnosi się do infrastruktury klucza publicznego — mechanizmu dobrze znanego i szeroko stosowanego do zabezpieczania stron internetowych. Dzięki PKI możemy nawiązać bezpieczne, szyfrowane połączenie mając pewność, że witryna, z którą komunikuje się nasza przeglądarka jest autentyczna.

W tym mechanizmie kluczową rolę odgrywają certyfikaty oraz klucze szyfrujące. Vault oferuje secret engine, który pozwala na generowanie certyfikatów. Co więcej począwszy od wersji 1.14 Vault obsługuje protokół ACME (Automatic Certificate Management Environment) co znacznie upraszcza zarządzanie certyfikatami.

Use Case Vault PKI

Vault PKI secret engine jest najczęściej wykorzystywany do zabezpieczania serwerów za pomocą certyfikatów potwierdzających ich autentyczność. Poza tym podstawowym zastosowaniem mechanizm ten można użyć także w innych obszarach takich jak:

Uwierzytelnianie bezhasłowe
Automatyczne zarządzanie certyfikatami domeny
Podpisywanie kodu
Własny urząd certyfikacji (CA)
Authentykacja IoT

Więcej informacji na temat potencjalnych zastosowań możemy znaleźć w tym miejscu.

HashiCorp Vault PKI przykłady

Dzięki silnikowi PKI w Vault możemy utworzyć własny Certificate Authority (CA), co jest niezwykle przydatne gdy chcemy mieć pełną kontrolę nad certyfikatem ROOT. Przykładowo gdy mamy do czynienia z prywatną siecią. Choć w przypadku serwerów webowych może to być mniej użyteczne Vault PKI jest bardzo elastyczne. Pozwala na wystawienie podpisanego certyfikatu pośredniego (Intermediate Certificate Authority, ICA), który możemy wykorzystać do wydawania certyfikatów dla naszych serwisów. Taki sposób zarządzania certyfikatami gdy ROOT CA jest poza naszą kontrolą nazywa się „offline root„.

INFORMACJE DOTYCZĄCE MECHANIZMU DZIAŁANIA CERTYFIKATÓW

W tym wpisie nie będę szczegółowo wyjaśniał do czego służą urzędy certyfikujące, czym jest łańcuch certyfikacji („Chain of Trust”) ani jakie są różnice między kluczami symetrycznymi i asymetrycznymi. Aby maksymalnie wykorzystać ten materiał zachęcam do przeczytania mojego wcześniejszego wpisu: Po co nam certyfikaty SSL / TLS? Jeśli znasz już odpowiedzi na te pytania możesz pominąć tę wskazówkę.

Vault PKI jako ROOT CA

Zaczynamy od uruchomienia Vault w trybie developerskim używając polecenia vault server -dev -dev-root-token-id root. Następnie włączamy silnik PKI vault secrets enable pki.

W tym przykładzie używam Vault w trybie developerskim ponieważ celem jest pokazanie możliwości silnika PKI, a nie pełnej konfiguracji serwera Vault. Jeśli chcesz dowiedzieć się w jaki sposób korzystać z Vault w środowisku produkcyjnym zapraszam Cię do wpisu, w którym znajdziesz rozwiązania dedykowane dla produkcji: HashiCorp Vault – centrum zarządzania sekretami.

Certyfikat Root

Uruchamiamy pierwszy silnik PKI pod domyślną ścieżką /pki. W tej lokalizacji umieścimy nasz ROOT CA. Następnie konfigurujemy maksymalny czas ważności certyfikatu na 10 lat używając polecenia: vault secrets tune -max-lease-ttl=87600h

Kolejnym krokiem będzie wygenerowanie certyfikatu dla naszego ROOT CA i zapisanie go do pliku. Vault automatycznie wygeneruje klucz prywatny oraz certyfikat, a następnie go podpiszę.

vault write -field=certificate pki/root/generate/internal \
     common_name="red-devops.pl" \
     issuer_name="red-devops" \
     ttl=87600h > red-devops_ca.crt

Po wykonaniu tego kroku dodaliśmy wystawcę (issuer) do naszej ścieżki. Informacje na jego temat możemy odczytać zarówno za pomocą CLI jak również w interfejsie użytkownika (UI) Vaulta.

Vault wymaga aby do zamawiania certyfikatów używać ról. Dzięki rolom możemy dostosować parametry zamówionych certyfikatów, takie jak: możliwość wystawiania certyfikatów dla subdomen, wildcardów czy ustawienie czasu ważności certyfikatu. Opcji jest naprawdę wiele, więc po szczegóły odsyłam do dokumentacji Vaulta.

W naszym przypadku tworzę rolę, która ma bardzo szerokie uprawnienia: vault write pki/roles/red-devops-servers allow_any_name=true

Następnie ustawiamy URL-e dla CA i CRL. Są to kluczowe adresy: pierwszy ca, który pozwala sprawdzić, czy certyfikat (w tym przypadku certyfikat ROOT) jest podpisany. Drugi crl, zwraca listę wygasłych certyfikatów. Gdy aplikacja będzie chciała zweryfikować certyfikat wówczas znajdzie te adresy w „chain of trust” i będzie mogła je odpytać celem potwierdzenia ich autentyczności.

vault write pki/config/urls \
     issuing_certificates="$VAULT_ADDR/v1/pki/ca" \
     crl_distribution_points="$VAULT_ADDR/v1/pki/crl"

To już wszystko jeśli chodzi o konfigurację ROOT CA. Teraz skonfigurujemy intermediate certificate authority (ICA). Ścieżka, pod którą uruchamiamy silnik PKI jest istotna, ponieważ możemy utworzyć wielu wystawców (issuerów) w ramach tego samego mounta. Moglibyśmy przykładowo stworzyć nową domenę z certyfikatem dla blue-devops.pl pod ta samą ścieżką /pki.

Jednak problem polega na tym, że adresy URL dla CA i CRL byłyby wspólne dla obu domen, które musiałyby się nimi dzielić. Dobrą praktyką jest separacja domen, co też zrobimy w przypadku ICA.

Certyfikat ICA

Kroki konfiguracji będą bardzo podobne do tych zastosowanych w przypadku ROOT CA dlatego też ograniczę się do wklejenia ich wszystkich w jednym bloku kodu.

vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int
vault write -format=json pki_int/intermediate/generate/internal \
     common_name="red-devops.pl Intermediate Authority" \
     issuer_name="red-devops-dot-pl-intermediate" \
     | jq -r '.data.csr' > pki_intermediate.csr
vault write pki_int/config/urls \
     issuing_certificates="$VAULT_ADDR/v1/pki_int/ca" \
     crl_distribution_points="$VAULT_ADDR/v1/pki_int/crl"

Certyfikat pośredni musi mieć krótszy okres ważności niż certyfikat ROOT dlatego też ustawimy go na 5 lat. Certyfikat ten wymaga podpisania, więc Vault zwraca nam Certificate Signing Request (CSR), który następnie prześlemy do ROOT CA w celu podpisania.

Ustawiamy również URL-e, aby uniknąć ostrzeżeń o ich braku podczas wgrywania certyfikatu.

vault write -format=json pki/root/sign-intermediate \
     issuer_ref="red-devops" \
     csr=@pki_intermediate.csr \
     format=pem_bundle ttl="43800h" \
     | jq -r '.data.certificate' > intermediate.cert.pem
vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
vault write pki_int/roles/red-devops-dot-com \
     issuer_ref="$(vault read -field=default pki_int/config/issuers)" \
     allowed_domains="red-devops.com" \
     allow_subdomains=true \
     max_ttl="720h"

Pierwsze polecenie podpisuje certyfikat, wysyłając wniosek do wystawcy red-devops. Następnie wgrywamy certyfikat z powrotem do ścieżki pki_int. Na koniec tworzymy rolę, która pozwala na tworzenie subdomen dla red-devops.pl, co kończy konfigurację ICA.

Certyfikat końcowy

Na koniec pozostaje nam złożyć wniosek o certyfikat. Na potrzeby testu spróbujemy zmienić nazwę domeny, dla której żądamy certyfikatu, tak aby była nieprawidłowa.

vault write pki_int/issue/red-devops-dot-pl common_name="test.blue-devops.pl" ttl="24h"
Error writing data to pki_int/issue/red-devops-dot-pl: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/pki_int/issue/red-devops-dot-pl
Code: 400. Errors:

* common name test.blue-devops.pl not allowed by this role

Oczywiście otrzymujemy błąd, ponieważ blue-devops.pl to niepoprawna domena. Naprawmy to korzystając z właściwej nazwy.

vault write pki_int/issue/red-devops-dot-pl common_name="test.red-devops.pl" ttl="24h"

Vault zwróci odpowiedź z następującymi polami: ca_chain, certificate, expiration, issuing_ca, private_key, private_key_type i serial_number. Użyjmy numeru seryjnego certyfikatu, aby pobrać go z Vault i sprawdzić jego poprawność. Aby pobrać certyfikat używamy polecenia:
vault read -field=certificate pki_int/cert/<serial_number> > certificate.pem.

Następnie możemy sprawdzić jego szczegóły za pomocą OpenSSL:
openssl x509 -in certificate.pem -text -noout

Certyfikat został wystawiony dla domeny test.red-devops.pl i jest ważny przez 24 godziny. Jego wystawcą jest nasz ICA.

W dodatkowych informacjach znajdują się także dane o endpointach, z których wystawca udostępnia informacje o autentyczności tego certyfikatu, a także lista wygasłych lub odwołanych certyfikatów.

Vault PKI z offline ROOT

Przejdźmy do kolejnego scenariusza, w którym zamiast własnego ROOT CA posiadamy jedynie intermediate CA w Vault. Certyfikat odsyłamy następnie do publicznego ROOT CA w celu uwierzytelnienia. Taki scenariusz jest bardziej odpowiedni kiedy nasze serwery są dostępne publicznie, ponieważ umożliwia zewnętrznym podmiotom zaufanie naszym serwisom.

Ten przykład nie będzie się znacznie różnił od poprzedniego, poza tym, że skorzystamy tylko z jednego montowania dla ICA. Certyfikat ROOT zasymulujemy generując go ręcznie, a następnie użyjemy go do podpisania certyfikatu pośredniego stworzonego przez Vault. Gdy ICA będzie poprawnie skonfigurowany wówczas będziemy mogli wykorzystywać go do zamawiania certyfikatów.

Offline Root

W pierwszej kolejności stwórzmy i podpiszmy zewnętrzny certyfikat ROOT CA. Generujemy klucz prywatny, który posłuży nam do podpisania certyfikatu używając polecenia: openssl genrsa -out rootCA.key 4096 Następnie generujemy żądanie CSR z pliku konfiguracyjnego: openssl req -new -key rootCA.key -out rootCA.csr -config rootCA.cnf

[ req ]
default_bits        = 4096
default_md          = sha256
prompt              = no
distinguished_name  = req_distinguished_name

[ req_distinguished_name ]
C             = PL
ST            = Slaskie
L             = Ruda Slaska
O             = Red-DevOps
OU            = DevOps
CN            = Root CA

Na koniec podpisujemy wygenerowane żądanie CSR za pomocą polecenia:
openssl x509 -req -in rootCA.csr -signkey rootCA.key -out rootCA.crt -days 3650 -sha256

Wnioskodawca (Subject) oraz wystawca (Issuer) są identyczni, więc możemy użyć tego certyfikatu ROOT CA do podpisania certyfikatu pośredniego utworzonego przez Vault.

Certyfikat ICA

Wykorzystam tę samą konfigurację pki_int co w poprzednim przykładzie, dlatego przejdziemy od razu do podpisania certyfikatu ICA z Vault:
openssl x509 -req -in pki_intermediate.csr -CA rootCA.crt -CAkey rootCA.key -extfile pki_intermediate.cnf -CAcreateserial -out pki_intermediate.crt -days 1825 -sha256
Do podpisania certyfikatu będziemy potrzebować pliku CSR, certyfikatu ROOT CA, jego klucza prywatnego oraz pliku konfiguracyjnego pki_intermediate.cnf z parametrem basicConstraints=CA:TRUE. Bez tego parametru certyfikat pośredni nie będzie mógł być używany do podpisywania innych certyfikatów.

Widzimy, że wnioskodawca to red-devops.pl Intermediate Authority, a wystawiającym certyfikat jest ROOT CA. Tak podpisany certyfikat możemy ponownie wgrać do Vaulta i wykorzystać go w ostatnim kroku.

Zwróćmy uwagę, że bez parametru basicConstraints=CA:TRUE Vault nie pozwoli wykorzystać tego certyfikatu jako pośredniego do podpisywania certyfikatów końcowych. Aby wgrać podpisany certyfikat, używamy polecenia:
vault write pki_int/intermediate/set-signed certificate=@pki_intermediate.crt

Poniżej znajduje się potwierdzenie, że certyfikat został prawidłowo podpisany i wgrany. Teraz możemy go wykorzystać do wystawiania certyfikatów końcowych. Ta czynność nie różni się od tej pokazanej w poprzednim przykładzie, dlatego ją pomijam.

Zagadnienie PKI jest bardzo obszerne, dlatego ten wpis należy traktować jako prezentację możliwości, a nie artykuł w pełni wyczerpujący temat. Skupiamy się na podstawowych aspektach, jedynie powierzchownie poruszając wybrane treści. Zanim rozpoczniemy pracę z Vault PKI Secret Engine zalecam zapoznanie się z dodatkową dokumentacją, która wyjaśnia na co należy zwrócić uwagę podczas projektowania rozwiązania opartego na tym silniku.

Automatic Certificate Management Environment (ACME)

Do tej pory poznawaliśmy, jak korzystać z Vault PKI do tworzenia CA, ICA oraz wnioskowania o certyfikaty. W tej części chciałbym zapoznać Was z protokołem ACME, który pozwala całkowicie zapomnieć o zarządzaniu certyfikatami. Dzięki niemu możemy automatycznie pobierać, śledzić, odnawiać i instalować certyfikaty. Jest to standardowe podejście do automatyzacji provisioningu certyfikatów.

Na początek opowiem o samym rozwiązaniu, a następnie wykorzystamy Vault PKI jako serwer ACME. Z pomocą Certbota pokażę, jak skonfigurować środowisko do automatycznej pracy. Dodam, że ACME jest otwartym standardem, wspieranym przez dużą społeczność i uznawanym za najlepszą praktykę w zakresie dostarczania certyfikatów.

W Internecie, poza protokołem ACME i Certbot spotykamy często nazwę Let’s Encrypt. Warto wiedzieć, że Let’s Encrypt to darmowy urząd certyfikacji, do którego Certbot domyślnie wysyła żądania jeśli chcemy uzyskać certyfikat. To bardzo popularne rozwiązanie, które jest powszechnie używane w Internecie. Blog, który właśnie czytasz, korzysta z tego rozwiązania. Możesz to sprawdzić, otwierając opcje certyfikatu strony.

Protokół ACME składa się z dwóch elementów: klienta wnioskującego o certyfikat (najpopularniejszym jest Certbot, ale oczywiście dostępne są także inne narzędzia) oraz serwera CA, który wystawia certyfikaty. Certyfikaty wystawiane z pomocą protokołu ACME mogą być ważne maksymalnie 90 dni natomiast certyfikaty z własnego urzędu certyfikacji, na przykład z Vaulta możemy konfigurować na krótsze okresy ważności.

Urząd certyfikacji, aby autoryzować nasze zapytanie o certyfikat posługuje się wyzwaniami (challenges), które mają na celu sprawdzenie, czy jesteśmy właścicielem danej domeny lub strony. Do wyboru mamy trzy rodzaje wyzwań: HTTP-01, DNS-01 oraz TLS-ALPN-01.

HTTP-01 to najczęściej stosowane wyzwanie. Polega na tym, że serwer CA przesyła token do klienta ACME, który musi umieścić go w specjalnym miejscu na serwerze. Następnie serwer CA przez port 80 na maszynie klienta sprawdza, czy token znajduje się we wskazanym miejscu.
DNS-01 jest używane, gdy chcemy uzyskać m.in. certyfikaty wildcard. Polega to na tym, że musimy udowodnić, że mamy kontrolę nad domeną, umieszczając w rekordzie DNS specjalny token TXT. Sprawdzanie tego wyzwania odbywa się poprzez odczytanie rekordu DNS.
TLS-ALPN-01 jest bardziej skomplikowane i stosowane, gdy port 80 jest zamknięty, a potrzebujemy wygenerować certyfikat dla serwera. W tym przypadku zamiast HTTP proces weryfikacji odbywa się przez port 443 z wykorzystaniem protokołu ALPN.

Wiecej na temat wyzwań w dokumentacji.

Automatyczne zamawianie certyfikatów z ACME

Teraz gdy zdobyliśmy już wiedzę na temat Vault PKI Secret Engine i protokołu ACME połączmy te elementy, aby stworzyć rozwiązanie, które automatycznie zadba o pobieranie i odnawianie certyfikatów.

Na początek skonfigurujemy Vault PKI, aby działał jako serwer ACME, a następnie zainstalujemy Certbota i ustawimy go tak, aby pobierał certyfikaty z naszego własnego urzędu certyfikacji. Poniżej znajdziesz schemat naszego rozwiązania.

Nasze środowisko buduję w chmurze AWS. Decyzję o umieszczeniu rozwiązania w chmurze AWS podjąłem z powodu pełnej kontroli nad DNS resolverem, który będzie niezbędny podczas realizacji wyzwań związanych z protokołem ACME. Dzięki tej kontroli będziemy mogli łatwo zarządzać wymaganiami dotyczącymi weryfikacji domeny przez ACME.

Poniżej znajdziesz skrypt, który skonfiguruje Vault do działania jako CA + ICA dla protokołu ACME.

#!/bin/bash

set -euxo pipefail

# Setting up CA ROOT
vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki
vault write -field=certificate pki/root/generate/internal \
   common_name="red-devops.pl" \
   issuer_name="red-devops" \
   ttl=87600h > red-devops_ca.crt
vault write pki/config/cluster \
   path=http://127.0.0.1:8200/v1/pki \
   aia_path=http://127.0.0.1:8200/v1/pki
vault write pki/roles/red-devops-servers \
   allow_any_name=true \
   no_store=false
vault write pki/config/urls \
   issuing_certificates={{cluster_aia_path}}/issuer/{{issuer_id}}/der \
   crl_distribution_points={{cluster_aia_path}}/issuer/{{issuer_id}}/crl/der \
   ocsp_servers={{cluster_path}}/ocsp \
   enable_templating=true

# Setting up ICA
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int
vault write -format=json pki_int/intermediate/generate/internal \
   common_name="red-devops.pl Intermediate Authority" \
   issuer_name="red-devops-dot-pl-intermediate" \
   | jq -r '.data.csr' > pki_intermediate.csr
vault write -format=json pki/root/sign-intermediate \
   issuer_ref="red-devops" \
   csr=@pki_intermediate.csr \
   format=pem_bundle ttl="43800h" \
   | jq -r '.data.certificate' > intermediate.cert.pem
vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
vault write pki_int/config/cluster \
   path=http://127.0.0.1:8200/v1/pki_int \
   aia_path=http://127.0.0.1:8200/v1/pki_int
vault write pki_int/roles/red-devops-dot-pl \
   issuer_ref="$(vault read -field=default pki_int/config/issuers)" \
   allowed_domains="red-devops.pl" \
   allow_subdomains=true \
   max_ttl="720h" \
   no_store=false
vault write pki_int/config/urls \
   issuing_certificates={{cluster_aia_path}}/issuer/{{issuer_id}}/der \
   crl_distribution_points={{cluster_aia_path}}/issuer/{{issuer_id}}/crl/der \
   ocsp_servers={{cluster_path}}/ocsp \
   enable_templating=true

# Setting up ACME
vault secrets tune \
      -passthrough-request-headers=If-Modified-Since \
      -allowed-response-headers=Last-Modified \
      -allowed-response-headers=Location \
      -allowed-response-headers=Replay-Nonce \
      -allowed-response-headers=Link \
      pki_int
vault write pki_int/config/acme enabled=true

Warto zwrócić uwagę, że w przypadku konfiguracji Vault do pracy z ACME zamiast domyślnych URLi issuing_certificates i crl_distribution_points musimy ustawić odpowiednio path i aia_path w konfiguracji PKI. Na koniec należy dodać odpowiednie nagłówki do odpowiedzi i włączyć obsługę protokołu ACME.

Po skonfigurowaniu Vaulta przechodzimy do instalacji Certbota. Instrukcję w jaki sposób zainstalować Certbota znajdziesz tutaj. Następnie tworzymy plik konfiguracyjny dla Certbota, aby zamiast Let’s Encrypt korzystał z Vaulta jako serwera ACME.

email = jaroslaw.czerwinski.it@gmail.com
server = http://127.0.0.1:8200/v1/pki_int/acme/directory

Po zainstalowaniu Certbota wykonujemy polecenie: sudo certbot certonly --standalone --config ./cli.ini -d example.red-devops.pl

Certbot wysyła żądanie o certyfikat do Vaulta prosząc o podpisanie domeny example.red-devops.pl. Następnie Vault sprawdza, pod jakim adresem IP znajduje się ta domena. W trakcie tworzenia infrastruktury dodałem odpowiedni rekord DNS do AWS Route 53, który wskazuje na adres IP, z którego Certbot wysłał żądanie. Vault szuka odpowiedniego tokenu na zwróconym przez AWS Route 53 adresie. Dzięki temu spełniamy wyzwanie HTTP-01, a Vault przyznaje nam podpisany certyfikat. Poniżej znajduje się fragment kodu Terraform.

...
resource "aws_route53_zone" "private" {
  name = "red-devops.pl"
  vpc {
    vpc_id      = module.vpc.vpc_id
  }
}

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.private.zone_id
  name    = "example.red-devops.pl"
  type    = "A"
  ttl     = 300
  records = [aws_instance.ec2.private_ip]
}

Sprawdźmy nasz certyfikat:
sudo openssl x509 -in /etc/letsencrypt/live/example.red-devops.pl/fullchain.pem -text -noout

Certyfikat został wystawiony na 30 dni, ponieważ ustawiliśmy max_ttl na 720 godzin dla roli, której użyliśmy. W przypadku chęci odnowienia certyfikatu za pomocą polecenia sudo certbot renew, system nie pozwoli na jego odnowienie gdyż certyfikat jest „zbyt świeży”.

Proszę nie zwracać uwagi na stare biblioteki Pythona w logach – nie usunąłem ich celowo, aby komenda była w pełni widoczna.

Oczywiście, jeśli odwołamy certyfikat z poziomu Vault będziemy mogli od razu pobrać nowy. W tym celu używamy polecenia:
vault write pki_int/revoke serial_number=<serial_number>

Istnieje również możliwość wymuszenia rotacji certyfikatu bezpośrednio z poziomu Certbota, używając polecenia: sudo certbot renew --force-renewal. Na koniec warto dodać, że Certbot po pobraniu certyfikatu automatycznie dba o jego odnawianie. Tworzy zadanie cron, które regularnie sprawdza, kiedy certyfikat wygasa i czy można już pobrać jego następcę.

Więcej informacji o zadaniu cron, które zostało utworzone przez Certbota można uzyskać za pomocą poniższej komendy: systemctl show snap.certbot.renew.timer

ACME z pluginem AWS

ACME posiada wiele wtyczek do wyzwania DNS-01. Jedna z nich, o której chcę napisać współpracuje z AWS Route53. Umożliwia to przyznawanie certyfikatów typu wildcard, a także certyfikatów dla serwerów znajdujących się na innych hostach niż wnioskujący agent. Proces polega na tym, że Certbot dynamicznie dodaje rekord TXT do AWS Route53 dla serwera ACME, a po zakończeniu procesu automatycznie go usuwa. W ten sposób udawadniamy, że mamy pełną kontrolę nad domeną.

Oczywiście, aby Certbot mógł wykonać tę operację musimy udzielić mu odpowiednich uprawnień. Więcej informacji na ten temat znajduje się w dokumentacji.

Wnioski i materiały dodatkowe

W tym wpisie zaprezentowałem w jaki sposób Vault PKI Secret Engine, protokół ACME oraz Certbot współpracują ze sobą tworząc rozwiązanie do automatycznego zarządzania certyfikatami. Dzięki integracji Vault z ACME możemy stworzyć własny serwer certyfikatów, który podpisuje zapytania o certyfikaty, umożliwiając łatwe wdrażanie i odnawianie certyfikatów SSL/TLS dla naszych serwisów.

Po omówieniu podstaw Vault PKI i protokołu ACME pokazałem, jak skonfigurować Vault do działania jako ACME oraz jak używać Certbota do automatycznego pobierania certyfikatów z Vault. Certbot działający w połączeniu z Vault PKI pozwala na wygodne wnioskowanie o certyfikaty i ich odnawianie.

Podsumowując, Vault PKI w połączeniu z ACME i Certbot stanowi potężne narzędzie do zarządzania certyfikatami, umożliwiając pełną automatyzację i elastyczność w obsłudze certyfikatów SSL/TLS. Poniżej znajdziecie kilka dodatkowych materiałów, które mogą okazać się pomocne bardziej dociekliwym czytelnikom:

Jeśli macie jakieś pytania lub potrzebujecie pomocy zapraszam do kontaktu na linkedin lub mailowo: jaroslaw.czerwinski.it@gmail.com. Do usłyszenia! 🙂