Certyfikat TLS to jedna z tych rzeczy, o których nikt w firmie nie myśli — dopóki nie wygaśnie. Wtedy w ciągu godziny padają sklep, portal klienta, panel logowania do ERP-a przez przeglądarkę i połowa integracji, o których wszyscy zapomnieli. Warto mieć na to system, zanim system się zemści.
Widzieliśmy to z bliska u 30-osobowego producenta z branży metalowej: portal B2B, przez który klienci składali zamówienia, miał certyfikat SSL wygasający w niedzielę o 23:00. Nikt nie dostał alertu (bo alerty szły na adres byłego administratora), a w poniedziałek o 8:00 klienci zamiast formularza zobaczyli „Twoje połączenie nie jest prywatne". Cztery godziny paraliżu, kilkanaście straconych zamówień, szacunkowo ok. 60 tysięcy PLN obrotu do odzyskania. Naprawa techniczna zajęła 20 minut. Naprawa zaufania kilku dużych klientów — kilka miesięcy.
Ten tekst jest o tym, jak w firmie 10–50 osób poukładać zarządzanie certyfikatami tak, żeby ta sytuacja się nie powtórzyła. Bez rozbudowanego PKI, bez drogich narzędzi enterprise. Wystarczy kilka nawyków i jeden arkusz.
Zacznij od inwentaryzacji — nie masz tylu certyfikatów, ile Ci się wydaje
Pierwsze pytanie, na które nikt w typowej firmie nie potrafi odpowiedzieć: „ile mamy w tej chwili aktywnych certyfikatów TLS i gdzie one są?". Odpowiedź „ten na stronie głównej" wystarcza rzadko. W praktyce w MSP znajdziesz certyfikaty w co najmniej kilku miejscach:
- Strona firmowa (WWW) i jej wersje regionalne.
- Sklep internetowy, portal B2B, portal klienta.
- Panele logowania do systemów przez przeglądarkę (webmail, portal HR, portal serwisowy do ERP).
- Serwery pocztowe (SMTP/IMAPS) — nawet jeśli używacie Microsoft 365, macie własne subdomeny z certyfikatami dla autodiscover lub SPF/DMARC.
- Serwery VPN i firewall (zdalny dostęp, panel administracyjny).
- Wewnętrzne aplikacje i API dostępne przez HTTPS, także w sieci lokalnej.
- Urządzenia sieciowe z panelami HTTPS (drukarki, NAS-y, kamery przemysłowe).
- Certyfikaty do podpisywania kodu (jeśli wypuszczacie własną aplikację desktopową lub instalatory).
Zrób prosty spis w Excelu albo Google Sheets. Kolumny: nazwa (FQDN), gdzie zainstalowany (serwer/urządzenie), kto wystawił, data wygaśnięcia, kto jest właścicielem biznesowym (nie IT — właściciel, który powie „tak, ten portal jest krytyczny"), gdzie leży klucz prywatny, kiedy ostatnio odnawiany. Ten arkusz ma dwie funkcje: mówi Ci, co masz, i pokazuje, o czym zapomniałeś. Pierwsza rewizja u klienta zwykle ujawnia 2–3 certyfikaty, o których nikt nie wiedział.
Rozdziel „automatyczne" od „ręcznych"
Dla większości certyfikatów zewnętrznych (WWW, portal, sklep) najlepszym rozwiązaniem jest ACME — najczęściej Let's Encrypt — z automatycznym odnawianiem co 60–75 dni. Certyfikat trwa 90 dni, klient (certbot, acme.sh, wbudowany mechanizm serwera www) odnawia go bez udziału człowieka. Jeśli automat działa, nie wygaśnie nigdy. Jeśli automat nie działa, dowiesz się o tym z alertu, a nie z telefonu od klienta.
Są jednak sytuacje, w których zostajesz z certyfikatem odnawianym ręcznie raz w roku:
- Certyfikaty EV / OV, których wymagają np. niektóre integracje bankowe lub korporacyjni klienci.
- Certyfikaty na urządzeniach, do których ACME nie ma dostępu (firewall bez odpowiedniego API, stara drukarka, kontroler PLC z panelem HTTPS).
- Certyfikaty do podpisywania kodu (code signing) — te nie odnawiają się same z definicji.
- Certyfikaty do integracji, gdzie druga strona ma białą listę wystawców (np. sektor publiczny).
Dla tych „ręcznych" musisz mieć procedurę, bo nikt o nich sam nie przypomni.
Alerty na 60, 30, 14, 7 i 1 dzień
Nie licz na to, że sam wystawca (Let's Encrypt, DigiCert, Sectigo) Ci przypomni. Owszem, wysyłają maile — ale często na adres, który miał administrator zwolniony dwa lata temu, albo z tematem, który wygląda jak spam. Postaw własny monitoring, który regularnie sprawdza kilkanaście publicznych domen i alarmuje na wspólny kanał (email całego zespołu IT, kanał w Teams/Slack, ale nie skrzynka jednej osoby).
Praktyczny zestaw alertów, który sprawdza się w MSP:
- 60 dni przed wygaśnięciem — miękkie ostrzeżenie, informacyjne. Wpada do inboxa, można je zignorować, ale wiesz, że sprawa się zbliża.
- 30 dni — potraktuj jak zadanie: odnów albo zdiagnozuj, dlaczego automat go nie odnowił.
- 14 dni — alarm. Ktoś musi wziąć to na siebie i zamknąć w tym tygodniu.
- 7 dni — czerwone światło. Angażuj kierownictwo IT, eskaluj do właściciela biznesowego usługi.
- 1 dzień — telefon do dyżurnego. Poważnie.
Do sprawdzania publicznych certyfikatów TLS wystarczy prosty skrypt na crona, który wywołuje openssl s_client i patrzy w notAfter, albo darmowe serwisy typu Uptime Kuma z modułem TLS. Nie musisz kupować platformy za 20 tysięcy rocznie. Ważne, żeby alerty trafiały do kanału zespołowego, nie do jednej skrzynki.
Klucze prywatne — gdzie leżą i kto ma dostęp
Certyfikat to połowa historii. Druga połowa to klucz prywatny. Jeśli klucz wycieknie, certyfikat trzeba unieważnić (revoke) i wystawić od nowa — najlepiej wczoraj. W MSP klucze prywatne żyją najczęściej w trzech miejscach: bezpośrednio na serwerze produkcyjnym, w repozytorium konfiguracji (czasem, niestety, w git bez szyfrowania) i „na wszelki wypadek" w folderze o wdzięcznej nazwie certyfikaty_stare na dysku sieciowym.
Zasady, które warto trzymać:
- Klucz prywatny generowany jest na tym urządzeniu, na którym ma pracować — nie na laptopie administratora, potem kopiowany mailem.
- Kopia zapasowa klucza (bo ktoś będzie musiał odbudować serwer) leży w zaszyfrowanym menedżerze sekretów albo w archiwum offline, nie na współdzielonym udziale sieciowym.
- Kto miał dostęp do klucza, ten miał — po jego odejściu z firmy klucz jest rotowany razem z certyfikatem.
- Kluczy nie ma w gitowym repozytorium konfiguracji. Nigdy. Nawet w „prywatnym" repo.
To brzmi jak higiena oczywista. Nie jest. W praktyce widzimy .pem z kluczem prywatnym w prezentacjach PowerPoint z onboardingu i w załącznikach do maili sprzed pięciu lat.
Wildcard, SAN i wewnętrzny CA
Dwa techniczne wybory, które warto podjąć świadomie, nie z rozpędu:
- **Wildcard (
.firma.pl) vs SAN (kilka domen w jednym certyfikacie).* Wildcard jest wygodny — jeden certyfikat pokrywa wszystkie subdomeny. Ale jeśli wycieknie, ryzyko jest większe, bo pokrywa całą przestrzeń. SAN daje więcej kontroli, ale trzeba go aktualizować przy każdej nowej subdomenie. W MSP z 5–10 subdomenami zwykle wygrywa SAN. W firmie, w której subdomeny powstają jak grzyby po deszczu — wildcard z krótkim czasem życia. - Certyfikaty wewnętrzne (własny CA) dla sieci lokalnej. Jeśli macie kilkanaście wewnętrznych paneli (drukarki, NAS-y, wewnętrzne aplikacje), postawcie mały wewnętrzny CA (np.
step-ca,smallstep) i rozdystrybuujcie root CA do przeglądarek przez GPO / Intune. Alternatywa (wszędzie samopodpisane certyfikaty ignorowane w przeglądarce) uczy zespół, żeby klikać „Zaakceptuj mimo wszystko" — a to jest dokładnie ten odruch, którego nie chcecie.
Co dalej
Zacznij od czterech pytań:
- Kiedy ostatnio ktoś sprawdził listę wszystkich Waszych certyfikatów TLS — publicznych i wewnętrznych?
- Gdzie chodzą alerty o zbliżającym się wygaśnięciu? Do skrzynki jednej osoby, czy do kanału zespołu?
- Które certyfikaty odnawiane są ręcznie i kto konkretnie ma to w kalendarzu?
- Gdzie leżą klucze prywatne najbardziej krytycznych certyfikatów i kto ma do nich dostęp dziś, a nie „historycznie"?
Jeśli któraś odpowiedź brzmi „nie jestem pewien" — potraktuj to jako zaproszenie do zrobienia inwentaryzacji w tym tygodniu. Godzinne spotkanie z jedną osobą z IT wystarczy, żeby mieć pierwszy szkic. Jeśli potrzebujecie pomocy w postawieniu monitoringu i procedury odnawiania, pomagamy MSP z tym regularnie. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Certyfikat, o którym nikt nie pamięta, wygasa zawsze w piątek wieczorem. Nigdy w środę o 10:00.