Certificate & PKI Lab
Public Key Infrastructure: the trust and identity layer built on top of cryptography.
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
Overview
Certificate & PKI Lab's 15 tools cover the trust-and-identity layer of cryptography: decoding and inspecting X.509 certificates, generating and decoding Certificate Signing Requests, validating certificate chains, exploring TLS cipher suites, converting between key formats (PEM, JWK, SSH), and checking certificate transparency logs and expiration status.
This category is distinct from general cryptography (Security Lab's Encryption sub-discipline) in a specific, important way: PKI isn't about the cryptographic algorithms themselves (RSA, AES) — it's about the trust model layered on top of them: how a public key gets bound to a verified identity via a Certificate Authority's signature, and how a chain of such signatures lets a browser trust a server it's never directly interacted with before.
Why Certificate & PKI Lab Matters
Nearly every production HTTPS deployment, every SSH-based server access, and every signed software artifact depends on this trust layer working correctly — and PKI failures (an expired certificate, a broken chain, a misconfigured CSR) cause some of the most disruptive, all-or-nothing outages in production systems, since a browser or client typically refuses the connection entirely rather than degrading gracefully.
Common Workflows
- Decoding a PEM-formatted certificate with the PEM Certificate Decoder to check its subject, issuer, and validity dates before deploying it.
- Inspecting a certificate's X.509 v3 extensions (SAN, Basic Constraints, Key Usage) with the X.509 Certificate Inspector to diagnose a hostname-mismatch or trust issue the basic fields don't explain.
- Generating a CSR and private key with the CSR Generator before submitting a certificate request to a Certificate Authority.
- Validating a certificate chain's order and completeness with the SSL Certificate Chain Validator before it causes a 'works in some browsers, not others' deployment bug.
- Converting a key between PEM and JWK format with the JWK ↔ PEM Converter when integrating a certificate-issued key with a JWT-signing library.
- Checking a certificate's remaining validity with the SSL Expiration Checker as part of a renewal monitoring routine.
Learning Roadmap: Beginner
- Decode a real, public website's certificate to see concretely what fields (subject, issuer, validity dates, serial number) a certificate actually contains.
- Learn the difference between a CSR and a certificate — a CSR is your request, self-signed to prove key possession; a certificate is the CA's response, signed by an authority browsers already trust.
- Understand why a certificate chain needs intermediate certificates, not just the leaf certificate, to validate correctly in every client.
Learning Roadmap: Professional
- Study the X.509 Certificate Inspector's extension fields (especially SAN and Authority/Subject Key Identifier) deeply enough to diagnose a hostname-mismatch or chain-building failure without guessing.
- Set up automated certificate expiration monitoring rather than relying on manual checks — the CA/Browser Forum's reduced maximum certificate validity (398 days) makes this a recurring, not occasional, operational task.
- Understand the specific three-way topic boundary between Certificate & PKI (trust/identity), Encryption (cipher mechanics), and Hashing (key fingerprinting) before assuming a PKI concept belongs in the wrong hub.
Tool Selection Strategy
- Use the PEM Certificate Decoder for a quick read of a certificate's core fields; move to the X.509 Certificate Inspector specifically when the basic fields don't explain a hostname or trust problem you're diagnosing.
- Use the SSL Certificate Chain Validator, not just the decoder, when a certificate works in some clients but not others — that specific symptom almost always points to an incomplete chain, not a bad leaf certificate.
- Choose between PEM, JWK, and SSH key formats based on what the consuming system actually expects, using the JWK ↔ PEM Converter to bridge between the X.509/TLS world (PEM) and the JOSE/JWT world (JWK) rather than assuming one universal format.
Tools in Certificate & PKI Lab
PEM Certificate Decoder
Decode and inspect PEM-formatted certificate fields in your browser.
Open toolX509 Certificate Inspector
Inspect X.509 certificate fields, extensions, and metadata details.
Open toolCSR Generator
Generate Certificate Signing Requests (CSRs) locally with custom parameters.
Open toolCSR Decoder
Decode and verify Certificate Signing Request (CSR) fields locally.
Open toolSSL Certificate Chain Validator
Validate the order and trust chain of SSL/TLS certificates.
Open toolTLS Cipher Suite Explorer
Explore and audit TLS cipher suites, algorithms, and strength levels.
Open toolPublic Key Extractor
Extract the public key from certificates or private keys.
Open toolPrivate Key Inspector
Verify private key details, algorithm, and passphrase safety locally.
Open toolJWK Generator
Generate JSON Web Keys (JWK) for token signing and validation.
Open toolJWK ↔ PEM Converter
Convert JSON Web Keys to PEM format and vice versa.
Open toolSSH Key Generator
Generate secure SSH private and public keys client-side.
Open toolSSH Public Key Decoder
Decode SSH public key details, fingerprint, and comments.
Open toolSSH Fingerprint Generator
Compute a real SHA256 fingerprint for SSH public keys.
Open toolCertificate Transparency Lookup
Search public CT logs for certificates issued to a domain.
Open toolSSL Expiration Checker
Check SSL certificate details and expiration dates locally.
Open toolDeveloper Guide
Go deeper than the tool list — these Developer Hubs cover the concepts behind Certificate & PKI Lab's tools in full depth.
Comparative Guides
Decide between the technologies and formats Certificate & PKI Lab's tools work with:
SHA256 vs SHA512
Cryptographic hash functions are designed to ingest arbitrary binary inputs and return a fixed-size, deterministic byte sequence called a digest. These functions must be one-way (infeasible to reverse-engineer) and collision-resistant (highly unlikely that two distinct inputs produce the same hash). In modern cryptography, the SHA-2 (Secure Hash Algorithm 2) family is the default choice for data integrity, SSL/TLS certificates, and blockchain networks. Within this family, SHA-256 and SHA-512 are the two most prominent algorithms. Surprisingly, their differences extend beyond digest length to internal block sizes, math architectures, and hardware parsing performance. This guide compares SHA-256 and SHA-512 in detail.
Bcrypt vs Scrypt
Bcrypt and Scrypt both slow down password verification deliberately, but they do it in fundamentally different ways: Bcrypt spends CPU cycles alone, while Scrypt deliberately consumes large amounts of memory alongside CPU time. That single architectural difference — memory-hardness — is the whole reason Scrypt exists, and it's the lens this comparison uses throughout.
MD5 vs SHA1 vs SHA256
MD5 and SHA-1 are both cryptographically broken — not theoretically weak, but practically broken, with real, demonstrated attacks — while SHA-256 remains secure with no known practical attack. This comparison is less about a tradeoff between three roughly-equivalent options and more about understanding exactly why two of them were retired and what, if anything, they're still safe to use for.
HMAC vs Digital Signatures
Both HMAC and digital signatures let a recipient verify a message wasn't tampered with, but they answer a different second question: HMAC only proves the message came from someone who holds a shared secret, while a digital signature proves it came from the one specific party holding a private key — and only the second property, non-repudiation, actually holds up if the sender later denies sending it.
Argon2 vs Scrypt
Argon2 and Scrypt are both memory-hard — the defining property that separates them from Bcrypt (see Bcrypt vs Scrypt) — but Argon2 refines the idea with a hybrid access pattern specifically designed to resist both GPU cracking and side-channel timing attacks simultaneously, something plain Scrypt's single access pattern can't do at once.
Common Mistakes
- Deploying a leaf certificate without its required intermediate certificates, assuming browsers will trust it because the root CA is well-known.
- Checking only a certificate's Subject Common Name for hostname matching, when modern clients check the Subject Alternative Name extension and ignore the CN when a SAN is present.
- Losing track of a private key generated alongside a CSR — without it, a certificate the CA later issues is unusable.
- Assuming Extended Validation certificates provide stronger encryption than Domain Validation ones — the cryptographic strength is identical; only the identity-verification process differs.
Standards Landscape
- RFC 5280 defines the X.509 certificate and extension structure this category's decoders and inspectors parse.
- RFC 2986 (PKCS#10) defines the CSR format; RFC 7517 defines JWK, the JSON key format this category's converters bridge to PEM.
- RFC 9162 defines Certificate Transparency v2, the public log system this category's transparency-lookup tool queries.
Glossary
- Certificate chain
- The sequence of certificates from a leaf (end-entity) certificate up through one or more intermediates to a trusted root, each signing the one below it.
- SAN (Subject Alternative Name)
- An X.509 extension listing every hostname a certificate is actually valid for — what modern clients check for hostname matching, not the Subject Common Name.
- CSR (Certificate Signing Request)
- A self-signed request containing your public key and desired identity, submitted to a Certificate Authority to obtain a signed certificate.
- Certificate Transparency
- A public, append-only log system requiring CAs to publish every certificate they issue, so mis-issuance becomes independently detectable.
- PKCS#8
- The modern, algorithm-agnostic private key wrapper format, distinct from the older, RSA-specific PKCS#1 format.
Troubleshooting
- If a certificate works in some browsers but fails in others, check the chain for a missing intermediate certificate first — some clients cache intermediates from other sites, masking an incomplete server-side chain.
- If a hostname mismatch error appears despite the Subject looking correct, check the SAN extension specifically — that's what modern clients actually validate against.
- If a certificate renewal fails silently, confirm your monitoring checks expiration directly rather than assuming an automated renewal process succeeded without verification.
References
Frequently Asked Questions
- What is the difference between a CSR and a certificate?
- A CSR is your request — self-signed to prove you hold the matching private key. A certificate is the CA's response: the same identity information, now signed by the CA, making it trusted by anyone who trusts that CA.
- Why does my certificate work in some browsers but not others?
- Almost always a missing intermediate certificate. Some browsers cache intermediates from other sites and can complete the chain anyway; a fresh client with none cached will fail unless the server sends the complete chain itself.
- Which hub should I read to go deeper on this category?
- The Certificate & PKI hub covers the trust/identity layer in depth. Note that SSH key fingerprinting specifically is owned by the Hashing & Integrity hub, and the underlying cipher mechanics (RSA, ECC) are owned by the Encryption Studio hub.
- Do I need Extended Validation certificates for better security?
- No — the cryptographic strength is identical across Domain, Organization, and Extended Validation certificates. The difference is in how much identity verification the CA performs, which matters for organizational trust, not encryption strength.
- What is Certificate Transparency and why does it matter?
- It requires publicly-trusted CAs to publish every certificate they issue to public logs, making it possible to detect a certificate mis-issued for your domain that you never requested.
- How far in advance should I renew a certificate?
- Many teams automate renewal at roughly a third of the certificate's remaining validity, and separately monitor expiration directly as a backstop in case automated renewal silently fails.
- Are SSH keys and TLS certificates the same trust system?
- No — SSH uses trust-on-first-connection, verified by comparing key fingerprints, with no certificate authority involved by default. TLS uses a hierarchical chain of trust rooted in a small set of pre-trusted CAs.
- What is the difference between PEM and JWK key formats?
- PEM is a base64-encoded text wrapper around binary key data, the standard for TLS. JWK represents the same key data as a JSON object, the format most JOSE/JWT tooling expects. The same underlying key can be converted between the two.
Related Categories
Other categories whose tools share a Developer Hub with Certificate & PKI Lab: