Kategoria
Certyfikaty i PKI
Wszystkie narzędzia i artykuły z tej kategorii, zebrane w jednym miejscu.
Narzędzia
ACME dns-01 TXT computer
Compute the TXT record for an ACME dns-01 challenge, from the token and account key.
Certificate chain builder
Paste a leaf and its intermediates in any order and get the chain a server should send: the end entity first, each issuer after the certificate it signed, the root optional. Links are made by key identifier or by name, RFC 5280's rules are checked along the way (cA, keyCertSign, pathLenConstraint, validity, windows), missing and extra certificates are named, and each signature is verified in your browser. Nothing is fetched.
Dekoder certyfikatów X.509
Wklej certyfikat w formacie PEM, base64 lub hex, aby odczytać jego podmiot, wystawcę, okno ważności, klucz publiczny i rozszerzenia v3, z odciskami SHA-256 i SHA-1. Działa w całości w twojej przeglądarce.
Dekoder CSR
Zdekoduj żądanie podpisania certyfikatu PKCS#10, aby odczytać jego podmiot, klucz publiczny, żądane nazwy SAN i rozszerzenia oraz atrybuty; wszystko w przeglądarce.
Let's Encrypt rate-limit planner
Plan certificate issuance for a set of hostnames: group them by registered domain and see how they map onto Let's Encrypt's rate limits.
Planer odnawiania certyfikatów
Oblicz ważność certyfikatu TLS, czy mieści się w 47-dniowym harmonogramie CA/Browser Forum, oraz wynikającą z tego częstotliwość odnawiania; wszystko offline.
Artykuły
Anatomia certyfikatu X.509
Co żyje wewnątrz certyfikatu TLS, jak ustrukturyzowane są bajty ASN.1/DER, co właściwie kontrolują rozszerzenia v3 i dlaczego dekodowanie certyfikatu nie jest tym samym co zaufanie mu.
CzytajPEM, DER i formaty plików certyfikatów
Dlaczego ten sam certyfikat przychodzi w tylu formach plików, czym właściwie są PEM i DER oraz co naprawdę zawierają .crt, .pem, .pfx i .p12.
CzytajŻądania podpisania certyfikatu i jak certyfikaty są wystawiane
Co zawiera CSR, dlaczego twój klucz prywatny nigdy nie opuszcza twojej maszyny, jak CA waliduje i wystawia, oraz jak ACME automatyzuje całą wymianę.
CzytajCertificate chains: the order, the anchor, and what breaks them
A server certificate is only the last link. How a client builds the path from the leaf to a root it trusts, why the order of the Certificate message matters and what TLS 1.3 relaxed, why the root is normally left out, how key identifiers and names link one certificate to the next, what pathLenConstraint, cA and keyCertSign forbid, why a cross-signed root appears in a chain as if it were an intermediate, and why the same chain works in one browser and fails in another. With RFC 5280, RFC 8446, the Baseline Requirements and a live Let's Encrypt chain.
CzytajJak naprawdę działa walidacja certyfikatu
Kroki, które klient wykonuje, by zdecydować, że certyfikat jest godny zaufania: budowanie łańcucha, sprawdzanie podpisów i dat, dopasowanie nazwy oraz egzekwowanie ograniczeń.
CzytajUnieważnianie certyfikatów: CRL, OCSP i certyfikaty krótkożyciowe
Dlaczego certyfikat czasem trzeba anulować zanim wygaśnie, dlaczego klasyczne systemy unieważniania działają słabo, i dlaczego branża zamiast tego skraca czasy życia certyfikatów.
CzytajAuthority Information Access: The OCSP and CA Issuers URLs
The AIA extension carries two kinds of pointer: where to ask whether a certificate is revoked (OCSP) and where to fetch the issuer's own certificate (CA Issuers). What each is for, why they are easy to confuse, and what the inspector shows.
CzytajOCSP Must-Staple: Closing the Soft-Fail Gap
Real-time OCSP checking has a fatal weakness: when the responder is unreachable, clients usually proceed anyway. OCSP stapling and the Must-Staple flag are the fix. What the TLS Feature extension declares, and the operational risk it carries.
CzytajACME: how certificates issue and renew themselves
How the ACME protocol automates certificate issuance end to end: the account, the order, the three challenge types, the dns-01 record you publish, and the finalize-and-download step that produces the certificate.
CzytajThe 47-day era: how TLS certificate lifetimes are shrinking
The CA/Browser Forum's SC-081v3 schedule takes maximum public TLS validity from 398 days down to 47 by 2029, in three steps. What the phases are, why 47, and what it does to renewal volume.
CzytajCertificate validity windows: notBefore, notAfter, and renewal lead time
How a certificate's lifetime is defined by two timestamps, how that length is measured against the cap, why validity is not the same as time remaining, and how to choose a renewal lead time.
CzytajLet's Encrypt: the free CA and its rate limits
What Let's Encrypt is, why its certificates are short-lived, and how its rate limits actually work: the per-registered-domain and per-account limits, the exact-set and authorization-failure limits, and why ARI renewals are exempt from all of them.
CzytajDCV and SII reuse: the validation cadence behind the renewal cadence
Issuing a certificate means proving domain control and, for OV/EV, organization identity. SC-081v3 shrinks how long those proofs can be reused, DCV to 10 days by 2029, which reshapes renewal as much as validity does.
CzytajRenewing before expiry: lead time, ACME, and ARI
Why late renewal causes outages, how ACME automates issuance and renewal, how the ARI extension lets a CA steer the renewal window, and how to pick a lead time that leaves room to retry.
CzytajPublic vs private PKI: which certificates SC-081v3 governs
The 47-day schedule binds publicly trusted TLS certificates only. What separates public from private PKI, why internal CAs are exempt, and how to read the planner's compliance verdict for an internal certificate.
Czytaj