Certificate Analyzer
Analyzes certificates and the cryptography around them for quantum vulnerabilities: certificate files, live TLS endpoints (including services that upgrade to TLS, such as mail, LDAP and databases), the TLS key exchange a server negotiates, and the signing keys identity providers publish for single sign-on. Results are scored using the unified Quantum Risk Engine shared across all Rivet analyzers.
Input Methods
- Hostname scan — connects to a live host on port 443 (or custom port) and retrieves the full certificate chain
- File upload — analyze
.pem, .crt, .cer, or .p7b files directly - Bulk scan — scan a list of hostnames from a CSV or newline-delimited text file
- Identity provider scan: enter an OIDC issuer or discovery URL, a JWKS URL, or a SAML / WS-Federation metadata URL. Rivet reads the signing keys your single sign-on provider publishes (the keys that sign every login token and assertion) and assesses each one, along with the provider's TLS certificate. Also available as
rivet scan-idp and through the MCP server.
Hostname scans also read certificates from mail (SMTP, POP3, IMAP), FTP, LDAP, XMPP, PostgreSQL and MySQL servers that upgrade to TLS on connection.
Result Fields Explained
Top-Level Scores
| Field | Range | What it means |
|---|
| Quantum Risk Score | 0 – 100 | Composite score from four weighted components (see Risk Score Breakdown below). Higher = more vulnerable. This is the primary number to act on. |
| Security Grade | A – F | Letter grade derived from the Quantum Risk Score: A (<15), B (15–39), C (40–59), D (60–79), F (80+). |
| Threat Level | minimal / low / medium / high / critical | The highest quantum threat level that falls within the certificate's remaining lifetime, based on the quantum computing development timeline. A certificate expiring in 36 days faces a lower threat level than one expiring in 5 years. |
| Migration | monitor / plan / prepare / urgent / immediate | Recommended migration urgency. Derived from threat level and certificate lifetime. Monitor means no action needed now; immediate means begin migration this quarter. |
| PQC Ready | Ready / Not Ready | Whether the certificate uses a NIST-approved post-quantum algorithm (ML-DSA, ML-KEM, SLH-DSA, FALCON, CRYSTALS-Dilithium/Kyber). Almost all certificates in use today show Not Ready. |
| Days to Expiry | integer | Calendar days until the certificate's notAfter date. Negative values mean the certificate is already expired. Short-lived certificates carry lower quantum risk because they will be replaced before quantum computers become a practical threat. |
Risk Score Breakdown
The Quantum Risk Score is a weighted sum of four component scores, each normalized to 0–100 before weighting.
| Component | Weight | What drives it |
|---|
| Algorithm Risk | 40% | How vulnerable the certificate's public key algorithm and key size are to Shor's algorithm. RSA-2048 scores 88; RSA-4096 scores 78; ECDSA P-256 scores 90; ECDSA P-521 scores 72. DSA/DH scores 95 — no quantum-safe interim step exists for these algorithms. A PQC-ready algorithm deducts 10 points. |
| Timeline Risk | 25% | Whether the certificate stays valid past the point at which Rivet's threat model treats its algorithm as breakable. A cert expiring in 36 days scores near 0 here; one that stays valid for many years scores higher. |
| Business Impact | 20% | Contextual factors: business criticality (standard by default), compliance requirements (FIPS-140, FedRAMP, HIPAA, etc.), certificate chain length, and whether it is a CA certificate. Without user-supplied context, this defaults to a moderate baseline score. |
| PQC Readiness | 15% | Whether the certificate already uses a NIST-approved PQC algorithm or hybrid scheme. Most certificates score 0 here today. A certificate using ML-DSA or CRYSTALS-Dilithium would score near 95. |
Shor Algorithm Threat
| Field | What it means |
|---|
| Status | VULNERABLE if the public key algorithm (RSA, ECDSA, DSA, DH) is broken by Shor's algorithm on a sufficiently large quantum computer. NOT VULNERABLE for PQC algorithms. |
| Security Level | Classical security in bits. RSA-2048 ≈ 112 bits; RSA-3072 ≈ 128 bits; RSA-4096 ≈ 152 bits; ECDSA P-256 ≈ 128 bits; ECDSA P-384 ≈ 192 bits. Shor's algorithm reduces this to near zero regardless of key size. |
| Break Timeline | The point in Rivet's threat model at which this algorithm and key size is treated as breakable, used to rank migration urgency. It is a scoring assumption, not a forecast: stronger keys are placed later than weaker ones, and the model is reviewed as the field evolves. |
| Algorithm | The detected public key algorithm (RSA, ECDSA, DSA, DH). |
Grover Algorithm Impact
Grover's algorithm affects symmetric encryption and hash functions — not public key algorithms. It halves the effective security level of symmetric keys.
| Field | What it means |
|---|
| Impact Level | LOW (AES-256 cipher suite — reduced to 128-bit effective security, still acceptable), MODERATE (AES-128 — reduced to 64-bit effective security, below recommended), CRITICAL (DES/3DES — completely broken), UNKNOWN (cipher suite not detected). |
| Security Reduction | Grover's algorithm provides a quadratic speedup, effectively halving the bit-security of any symmetric primitive. |
| Timeline | Grover's algorithm impact on symmetric cryptography grows as quantum hardware scales; 256-bit keys remain adequate. |
| Affected | Symmetric encryption (AES, DES) and hash functions (SHA-1, SHA-256) used in the TLS cipher suite. |
Migration Timeline
| Field | What it means |
|---|
| Priority | One of: Monitor, Plan, Prepare, Urgent, Immediate. Derived from the threat level during the certificate's lifetime. A certificate expiring before any quantum threat milestone shows Monitor. |
| Deadline | Recommended date to complete migration. For Monitor priority, no deadline is set. For Urgent, the deadline is approximately 1 year from scan date. For Prepare, approximately 2 years. |
| Cert Expires | The certificate's notAfter date. If this date is before the quantum break timeline for the algorithm, the certificate will naturally be replaced before it becomes a quantum risk. |
Recommendations
Recommendations are grouped into three time horizons:
- Immediate (0–6 months) — actions required now, typically for high/critical risk scores
- Short-term (6–18 months) — migration planning steps such as upgrading key sizes, enabling TLS 1.3, and testing hybrid certificates
- Long-term (1–3 years) — full migration to NIST-approved PQC algorithms and crypto-agility framework implementation
Compliance & Business Impact
| Field | What it means |
|---|
| Compliance Implications | Regulatory frameworks relevant to quantum migration: NIST SP 800-208 (PQC migration guidance), NSA CNSS Advisory 15-01 (quantum-safe requirements for national security systems), FedRAMP, FIPS-140, HIPAA, PCI-DSS, ITAR. These are shown when the certificate's risk level may affect compliance posture. |
| Business Risk Factors | Contextual risks such as long certificate lifetime (increases quantum exposure window), below-recommended key sizes, CA certificate status (affects entire PKI chain), and complex certificate chains. |
Algorithm Risk Reference
| Algorithm | Key Size | Algorithm Risk Score | Quantum Status |
|---|
| RSA | 1024 | 95 | Critical — weakest tier |
| RSA | 2048 | 88 | Critical — broken by Shor's algorithm |
| RSA | 3072 | 82 | High — broken by Shor's algorithm, needs a larger machine |
| RSA | 4096 | 78 | High — broken by Shor's algorithm, needs a larger machine |
| RSA | 8192 | 72 | Medium — still fully broken by Shor's, just needs more qubits |
| ECDSA | P-256 | 90 | Critical — broken by Shor's algorithm |
| ECDSA | P-384 | 80 | High — broken by Shor's algorithm, needs a larger machine |
| ECDSA | P-521 | 72 | Medium — broken by Shor's algorithm, needs the largest machines |
| DSA / DH | any | 95 | Critical — no quantum-safe interim step exists |
| ML-DSA (Dilithium) | — | 0 | Safe — NIST FIPS 204 |
| ML-KEM (Kyber) | — | 0 | Safe — NIST FIPS 203 |
| SLH-DSA (SPHINCS+) | — | 0 | Safe — NIST FIPS 205 |
| FALCON (FN-DSA) | — | 0 | Safe — NIST approved |
Threat Timeline Used for Scoring
These are the milestones Rivet's scoring model uses to rank certificates against each other. They are modeling assumptions for prioritization, not predictions of when quantum computers will arrive. A certificate's threat level is the highest milestone that falls within its remaining lifetime.
| Year | Threat Level | Algorithms at Risk |
|---|
| 2024–2025 | Minimal | None — current quantum computers insufficient for cryptographic attacks |
| 2026 | Low | RSA-512, ECC-160, DES, weak DH (~1,000 logical qubits) |
| 2032 | Medium | RSA-2048, ECDSA P-256, DH-2048, SHA-1 (~4,000 logical qubits) |
| 2037 | High | RSA-4096, ECDSA P-384, DH-4096, SHA-224 (~10,000 logical qubits) |
| 2040 | Critical | All classical public-key cryptography (>20,000 logical qubits) |
Certificate Technical Details
The raw certificate fields shown at the bottom of each result:
| Field | What it means |
|---|
| Subject | The entity the certificate was issued to (RFC 4514 distinguished name format, e.g. CN=cwpharmacy.com,O=...,C=US). |
| Issuer | The Certificate Authority that signed this certificate. |
| Serial Number | Unique identifier assigned by the CA. Used for revocation (CRL/OCSP). |
| Version | X.509 version. Version 3 (value = 2) is standard and required for extensions like SAN and key usage. |
| Signature Algorithm | The algorithm the CA used to sign this certificate (e.g. sha256WithRSAEncryption). Distinct from the public key algorithm — both should be assessed. |
| Public Key Algorithm | The algorithm of the certificate's own public key (RSA, ECDSA, DSA). This is what Shor's algorithm targets. |
| Key Size | Bit length of the public key. For RSA: 2048, 3072, 4096. For ECDSA: the curve's key size in bits (256, 384, 521). |
| Curve Name | For ECDSA certificates: the named elliptic curve (e.g. prime256v1 = P-256, secp384r1 = P-384). |
| Not Before / Not After | Certificate validity window. The certificate is only valid between these two dates. |
| TLS Version | The TLS protocol version negotiated during the live scan (TLSv1.2, TLSv1.3). TLS 1.3 is required for PQC cipher suite support. |
| Cipher Suite | The symmetric cipher and MAC negotiated for the TLS session (e.g. TLS_AES_256_GCM_SHA384). Determines Grover's algorithm impact on the session. |
| Key Exchange | The key exchange the server negotiated (e.g. X25519, or X25519MLKEM768 for hybrid post-quantum). A hybrid post-quantum key exchange protects recorded traffic against future decryption by a quantum computer; the certificate's own signature algorithm is a separate migration. |
