Sovereign Certificate Authority

Sovereign Certificate Authority to wewnętrzne Certificate Authority, które przenosi doświadczenie Let’s Encrypt 1:1 do własnej sieci: protokół ACME, automatyczny cert-enrollment, automatyczne odnawianie — dla wszystkich wewnętrznych usług, subdomen i urządzeń pracowników. W produkcyjnym użyciu.

  flowchart LR
    A[Wewnętrzna usługa] -->|Request ACME| B[Sovereign CA]
    B -->|Challenge| C[HTTP-01 / DNS-01]
    C -->|udane| D[Wystawienie certyfikatu 90 dni]
    D --> A
    A -.->|odnowienie po 60 dniach| B

O co chodzi

Każda firma z własnymi wewnętrznymi usługami — od wiki przez issue-tracker po wewnętrzny monitoring-dashboard — zna tę grę: certyfikaty TLS. Są trzy klasyczne warianty i żaden z nich nie jest dobry:

1. Certyfikaty self-signed — każda przeglądarka ostrzega, użytkownicy klikają obok ostrzeżeń (kultura bezpieczeństwa zniszczona), a kiedyś klik phishingowy przestaje być rozróżnialny.
2. Certyfikaty z public CA dla wewnętrznych hostnamów — płatne (€150 – €500 per certyfikat rocznie), a wszystkie wewnętrzne hostnamy pojawiają się w publicznych logach Certificate Transparency — atakujący mogą tam wyczytać, jakie systemy wewnętrzne istnieją.
3. Let’s Encrypt — bezpłatne, ale nie działa dla czystych intranet-hostów (brak publicznej osiągalności dla walidacji HTTP), i z 50 certyfikatami na tydzień per domena twarde rate-limity.

Sovereign Certificate Authority jest odpowiedzią: ten sam komfort co Let’s Encrypt, ale wewnętrznie, bez ekspozycji w public-logach i bez limitów.

Doświadczenie Let’s Encrypt — wewnętrznie

Każdy klient kompatybilny z ACME działa bezpośrednio z wewnętrznym CA — bez zmian w kodzie, bez specjalnych narzędzi, bez proprietarnego API.

• 🤖 Auto-Enrollment — usługa musi znać tylko ACME-endpoint wewnętrznego CA, potem sama pobiera swój certyfikat.
• 🔁 Auto-Renewal — domyślny czas życia 90 dni, automatyczne odnowienie po 60 dniach. Nikt już nie musi pamiętać o datach wygaśnięcia.
• 🌐 HTTP-01 + DNS-01 Challenge — obie standardowe metody walidacji, w zależności od use-case.
• 🃏 Wildcards — certyfikaty wildcard dla całych przestrzeni subdomen możliwe (*.intern.example.com).
• 📜 Standardowi klienci — certbot, acme.sh, lego, dehydrated, Caddy, Traefik, nginx-acme — wszystkie działają bez adaptacji.

Dlaczego nie po prostu Let’s Encrypt?

Decydujący punkt: ekspozycja w CT-logach. Każdy certyfikat wystawiony przez public CA — także ten z Let’s Encrypt — trafia do publicznego, przeszukiwalnego loga. Kto odpyta crt.sh, widzi wszystkie wasze wewnętrzne hostnamy. Narzędzia rekonesansowe dla atakujących używają dokładnie tego.

Wewnętrzne CA wystawia certyfikaty, bez że pojawiają się gdziekolwiek publicznie. Wewnętrzne hostnamy pozostają wewnętrzne.

Cechy operacyjne

• 🌳 Wielopoziomowa hierarchia PKI — Root-CA offline, Intermediate-CA online dla wystawiania ACME. Standardowa praktyka PKI.
• 🔄 Automatyczna revocation — endpointy CRL i OCSP dla list odwołań, skompromitowane lub wycofane certyfikaty są czysto sperowane.
• 🔐 Opcjonalne klucze sprzętowe — Intermediate-Key może być trzymany w HSM lub TPM — nawet przy skompromitowanym serwerze brak wolnego CA-Key.
• 📊 Monitoring & Inventory — przegląd wszystkich wystawionych certyfikatów, dat wygaśnięcia, dotkniętych hostów.
• 🎯 Policy Engine — który klient może wystawić jakie certyfikaty? Account-binding, domain-allowlists, limity maximum-validity per rola.
• 🔌 Integracja usług — certyfikaty tunelowe (VPN, mTLS), service-mesh (kompatybilne z Envoy/Istio), serwery mailowe (SMTP/IMAP TLS), reverse-proxies, urządzenia IoT.
• ⏰ Konfiguracja czasu życia — krótkie cert-lifetimes (24h dla pipelines, 90 dni dla usług, 1 rok dla IoT) — finegranularnie per use-case.
• 🔍 Audit-Log — każde wystawienie, odnowienie i revocation są strukturyzowanie protokołowane.

Typowe use-cases

• 🏢 Wewnętrzne aplikacje web — wiki, tracker, CRM, dashboardy z prawdziwymi certyfikatami TLS, które każda przeglądarka akceptuje (po instalacji root na urządzeniach końcowych).
• 🤝 Service-to-Service mTLS — Microservices/service-mesh z wzajemną autoryzacją zamiast API-keys.
• 📱 Autoryzacja urządzeń — laptopy pracowników i urządzenia mobilne otrzymują certyfikaty klienckie dla dostępu WLAN, VPN i usług.
• 📧 Infrastruktura e-mail — SMTP-submission, IMAP/POP z ważnymi certyfikatami bez kosztów public-CA.
• 🛠️ Pipeline CI/CD — krótkotrwałe certyfikaty dla build-runners, automatycznie wystawiane i odrzucane po jobie.
• 🌍 Domeny internal-DNS — .internal, .lan, własne top-level-subdomeny — certyfikaty, gdzie Let’s Encrypt zasadniczo nie może wystawić.

Dlaczego to jest tematem dla CEO

• 💰 Cost-Avoidance — per 100 wewnętrznych usług z certyfikatami public-CA: typowo 30 000–50 000 € rocznie. Z wewnętrznym CA: 0 €.
• 🔍 Ochrona przed rekonesansem — wewnętrzne hostnamy są dziś największą zdradą w pre-attack-rekonesansie — wydają atakującym topologię organizacji. Wewnętrzne CA eliminuje te wycieki całkowicie.
• 🛡️ Suwerenność — pełna kontrola nad łańcuchem zaufania. Bez zależności od zewnętrznych CA, których root-program może się zmienić lub których zaufanie CA może być odwołane (Symantec, DarkMatter, …).
• 📋 Compliance — pełny custody-chain. Dla regulowanych branż (finanse, zdrowie, obronność) wewnętrzne CA są często wręcz obowiązkowe.
• ♻️ Ciągłość biznesowa — przy awarii zewnętrznego CA (np. ze względu na konserwację, sankcje, niewypłacalność) wewnętrzne certyfikaty nadal można wystawiać.
• 🔧 Skalowanie bez kosztów marginalnych — 10 czy 10 000 certyfikatów — nakład i koszty praktycznie się nie zmieniają.

Fundament technologiczny

Zrealizowany w oparciu o sprawdzone implementacje CA open source, które w pełni wspierają protokół ACME.

Sovereign Certificate Authority — wewnętrzny wariant Let’s Encrypt · ACME RFC 8555 · w pełni zautomatyzowany enrollment · bez ekspozycji w public-CT-logach · W produkcyjnym użyciu