Certyfikaty TLS i automatyczne odnawianie

Dlaczego go potrzebujesz?

TLS szyfruje ruch „kliyent”, potwierdza autentyczność serwera (i z mTLS - klient), a także chroni przed spoofing. Główne zagrożenia: opóźnienia certyfikatów, słabe klucze, nieprawidłowy łańcuch zaufania, procedury ręczne. Celem artykułu jest opisanie architektury, w której certyfikaty są zawsze istotne, a obroty są niezauważone przez użytkowników.

Podstawowe koncepcje

AC/sygnatariusz: organ certyfikujący (publiczny lub wewnętrzny).
Łańcuch (fullchain): certyfikat liścia + pośredni + korzeń (zwykle korzeń w repozytoriach klienta).
SAN (nazwa alternatywna tematu): lista domen/IP dla jednego certyfikatu (multi-SAN).
Dzika karta: ".example. com '- wygodne dla wielu subdomen, wymaga walidacji DNS.
zszywanie OCSP: serwer stosuje najnowszy status cofnięcia; zmniejsza opóźnienie i zależność od zewnętrznych OCSP.
HPKP: przestarzały/nieużywany; zamiast tego, dzienniki tomografii komputerowej i higiena klucza.
CT (Certyfikat Przejrzystości): publiczne dzienniki wydawania - ważne dla kontroli fałszywych wydań.

Profil krypto i klucze

• ECDSA (P-256) - szybki i zwarty; preferowane dla nowoczesnych klientów.
• RSA-2048/3072 - nadal kompatybilny; mogą być prowadzone podwójnie cert (RSA + ECDSA).
• Generowanie kluczy: tylko po stronie docelowej (nie przenosić prywatników przez sieć), chronić prawa dostępu („0600”).
• HSM/KMS: dla obszarów krytycznych (płatności/PII) przechowywać klucze w HSM/KMS, włączyć operacje audytu.
• Długość życia: Krótkie certyfikaty (90 dni/30 dni dla wewnętrznych) zachęcają do częstej rotacji i zmniejszają ryzyko kompromisu.

Modele architektoniczne zarządzania TLS

1. Publiczne CA za pośrednictwem ACME (Zaszyfrujmy/Buypass/itp.)

Walidacja: HTTP-01 (za pośrednictwem serwera WWW/Ingress) lub DNS-01 (dla domen wildcard/out-of-stream).
Plusy: darmowe/zautomatyzowane, szerokie zaufanie. Minusy: zależności zewnętrzne.

2. Wewnętrzne CA korporacyjne

Narzędzia: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Plusy: niestandardowe zasady, mTLS, krótki TTL, zwolnienie dla domen wewnętrznych. Minusy: dystrybucja korzeni, zarządzanie zaufaniem.

3. Hybryda

Publiczne CA dla użytkowników zewnętrznych; wewnętrzne CA - dla usług (mTLS), kanałów międzyklasterowych i administratorów.

Automatyczne wzory odnowienia (odnowienie)

Zasady ogólne

Próg odnowienia: początek od „≤ 30” dni przed wygaśnięciem; dla usług krytycznych - „≤ 45” dni.
Zero-przestoje: wydanie nowego certyfikatu, wymiana atomowa, gładkie przeładowanie bez łamania połączeń.
Podwójne uchwyt (niebieski/zielony): przechowywać prąd i następny cert; przełączanie - poprzez symlink lub wersjonowany sekret.
Uwaga: 45/30/14/7/3/1 dzień ostrzeżenia; osobny wpis podczas awarii wyzwania ACME.

Klienci ACME i ich aplikacja

certbot/acme. sh/lego: środki świetlne na VM/gołym metalu.
cert-manager (Kubernetes): operator współpracujący z emitentem/emitentem klastrów; automatyzuje zwolnienie/odnawianie i pisze do Secret.
krok-ca/Vault Agent: automatyczne zwolnienie/obrót z krótkimi TTL, wzory sidecar do aktualizacji kluczy i łańcuchów.

Procesy dla kubernetów

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

Wymiana na gorąco w NGINX-Ingress następuje automatycznie, gdy 'Secret' jest aktualizowany. Dodaj 'ssl-ecdh-curve: secp256r1' i włącz zszywanie OCSP poprzez/ConfigMap adnotacje.

Procesy dla VM/Gołych metali

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

Okresowe odnawianie certyfikatów przez timer systemd.
W przypadku dzikiej karty należy użyć DNS-01 (dostawcy wtyczek) i podobnych '--deploy-hook'.

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

Wymiana atomowa NGINX

Zatrzymaj pełny łańcuch. pem 'ма' privkey. pem 'pod stabilnymi ścieżkami (symlink to versioned files), a następnie' nginx -s reload '.

Wewnętrzny PKI i mTLS

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

Automatyczne uwalnianie: za pośrednictwem wstrzykiwacza Vault Agent (K8s) lub bocznego; aplikacja ponownie odczytuje cert z pliku/FS-watcher.
Krótki TTL: 24-720 godzin, co zachęca do częstej rotacji i zmniejsza wartość skradzionego klucza.
mTLS: wydawanie certyfikatów klienta dla określonych usług/ról; na wejściu - wzajemne TLS w ingress/sidecar-proxy.

Bezpieczne działanie

Udostępnianie tajemnic: klucze prywatne - tylko na hosta/kapsuła, dostęp zgodnie z zasadą najmniejszych przywilejów.
Prawa do plików: „600” dla klucza; właściciel - użytkownik procesu.
Okres karencji: Ustaw 'renewBefore', aby był wystarczający do uwzględnienia awarii DNS/ACME/dostawcy.
OCSP Stapling: włącz na frontach; monitorować świeżość odpowiedzi (zwykle 12-72 godziny).
HSTS: włączyć stopniowo (bez 'preload' na początku), upewniając się, że prawidłowa dostawa HTTPS wszystkich treści.
Double-cert (RSA + ECDSA): poprawia kompatybilność i wydajność; Daj ECDSA nowoczesnym klientom.

Monitorowanie i SLO

• Dni przed wygaśnięciem (skrajnia) dla każdej domeny/tajemnicy; SLO: „nie cert od <7 dni do wygaśnięcia”.
• Ważność łańcucha (linking), zgodność SAN z wymaganymi domenami/IP.
• Stan zszywania OCSP (świeżość odpowiedzi).
• Odsetek udanych/nieudanych wyzwań ACME.
• Uściski ręczne Leitency TLS, wersje protokołu/szyfry (audyt).

• Ostrzeżenie: 30 dni do wygaśnięcia.
• Crit: 7 dni/niepowodzenie „odnowić”.
• Strona: 72 godziny/nieprawidłowy łańcuch w prod/bez zszywania OCSP.

Incydenty i zwroty

Opóźnienie certyfikatu: tymczasowo ponownie uruchomić i wdrożyć ręcznie, naprawić RCA (dlaczego odnowienie nie działa, ograniczenia blokowania DNS/API).
Kluczowy kompromis: natychmiastowa reissue/cofnięcie, rotacja tajemnic, kontrola dostępu, rotacja tokenów konta DNS/ACME.
Nieprawidłowy łańcuch: pilne złożenie prawidłowego „fullchain”, przymusowe przeładowanie frontów.
Blokada dostawcy DNS: zachowaj ścieżkę weryfikacji kopii zapasowej (HTTP-01) lub wtórny system DNS.

Lista kontrolna implementacji automatycznej

1. Wybierz model (publiczny urząd certyfikacji poprzez ACME/wewnętrzny PKI/hybrydowy).
2. Zdefiniuj profil krypto: ECDSA-P256, w razie potrzeby podwójny cert z RSA-2048.
3. Skonfiguruj agenta automatycznego (cert-manager, certbot, acme. sh, Vault Agent).
4. Zorganizuj wymianę zero-przestojów (wzór symlink, wnikanie na gorąco/NGINX/Envoy).
5. Włącz zszywanie OCSP i HSTS (etapami).
6. Dodaj daty powiadomień i wyzwanie statusów; przepisać SLO.
7. Dokumentuj procesy rozbijania szkła i ręcznego uwalniania.
8. Prowadzenie ćwiczeń „fałszywych”: złamane DNS-01, ACME upadek, wygasły korzeń/pośredni.
9. Sprawdź dostęp do kluczy prywatnych, obróć tokeny dostawcy DNS i konta ACME.

Funkcje dla iGaming/fintech

PCI DSS/PII: Strict Cipher Suites, forced TLS 1. 2+/1. 3, wyłączyć słabe szyfry/kompresję, wznowienie sesji bez kompromisów bezpieczeństwa.
Segmentacja domeny: oddzielne certyfikaty dla subdomen płatniczych i administratorów; dla dostawców treści - izolowane łańcuchy.
Audyt i rejestrowanie: wydanie/wycofanie/rotacja; podpisz artefakty CI/CD.
Wieloregionalność: Lokalni emitenci dla regionów, aby nie zależeć od niedoskonałości międzyregionalnych.

Konfiguracje próbki

NGINX (RSA + ECDSA, zszywanie OCSP)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: profil i emisja

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

NAJCZĘŚCIEJ ZADAWANE PYTANIA

Czy potrzebuję dzikiej kartki?
Jeśli często pojawiają się nowe subdomeny, tak (poprzez DNS-01). W przeciwnym razie użyj multi-SAN dla domen jednoznacznych.

Co wybrać: cert-manager lub certbot?
Kubernetes → cert-manager. VM/microservices out of K8s → certbot/lego/acme. sh. Wewnętrzny PKI → Skarbiec/krok-ca.

Czy TTL można zmniejszyć do dnia?
W przypadku wewnętrznego mTLS, tak, jeśli automatyka/boczny ekr gwarantuje rotację i aplikacje mogą przeładowywać na gorąco.

Jak zabezpieczyć DNS-01?
Oddzielny token/minimalny dostęp do strefy, rotacja klucza, ograniczenie dostępu IP API, audyt.

Razem

Niezawodne zarządzanie TLS to połączenie właściwego profilu kryptograficznego, zautomatyzowanego uwalniania i odnawiania, zerowych rotacji przestojów, obserwowalności i przejrzystych procedur reagowania na incydenty. Zbuduj rurociąg ACME/PXI, dodaj ścisły alarm i regularnie trenuj „awaryjne” scenariusze - a wygasłe certyfikaty nie będą już źródłem nocnych pagerów.