Post-Quanten-Zertifikatsinspektor

Füge ein oder mehrere Zertifikate oder Anforderungen als PEM ein – oder DER als Hex oder base64. Der Inspektor benennt jeden Algorithmus und wie endgültig seine Kennung ist, verifiziert jede Signatur mit ihrem Aussteller aus dem Bundle oder mit dem Objekt selbst, prüft die Regeln von RFC 9881, RFC 9909, RFC 9935 und den Composite-Entwürfen und zeigt, wie sich die Kilobytes verteilen.

100 % lokal – Zertifikate werden in deinem Browser geparst und geprüft, in einem Web Worker, der von dieser Website geladen wird; nichts wird irgendwohin gesendet

Beispiel

Zertifikate oder AnforderungenPEM (ein oder mehrere Blöcke) oder DER als Hex oder base64

Oder wähle eine Datei aus (.pem, .crt, .cer, .der, .csr)

What it reads

The inspector decodes X.509 certificates and PKCS #10 certificate requests (CSRs), pasted as one or more PEM blocks or as DER in hex or base64, or loaded from a file. For each object it names the subject key and the signature algorithm, with their object identifiers and how settled each one is. It verifies the signature, checks the rules of the documents that define these algorithms in X.509, and measures the object against the same certificate made with a classical key. Classical certificates work too: ECDSA, Ed25519, Ed448 and RSA, including RSA-PSS, so a mixed chain can be checked end to end.

Where the identifiers come from

As of 20 October 2026, the post-quantum identifiers in certificates fall into three groups, and the inspector labels each object accordingly:

Final. ML-DSA keys and signatures (RFC 9881), SLH-DSA (RFC 9909) and ML-KEM keys (RFC 9935) use OIDs that NIST assigned under 2.16.840.1.101.3.4.
Draft. Composite ML-DSA, which pairs ML-DSA with ECDSA, Ed25519, Ed448 or RSA in one key and one signature, comes from draft-ietf-lamps-pq-composite-sigs. The examples are the reference implementation's artifacts from the IETF hackathon's pqc-certificates repository. Their OIDs sit in the IANA-managed PKIX arc but can still change before the RFC.
Experimental. Falcon has no X.509 identifiers yet: FN-DSA (FIPS 206) is not final, and draft-ietf-lamps-fn-dsa-certificates leaves its OIDs to be assigned. Certificates in circulation use the Open Quantum Safe code points under 1.3.9999, which other software may not recognize.

The inspector also recognizes the "catalyst" construction of ITU-T X.509. That is a classical certificate carrying an alternative post-quantum public key and signature in extensions, readable by software that ignores them. Only the primary signature is verified, and the page says so.

What is checked

The signature is verified against the issuer's key when the issuer is in the bundle, matched by name and key identifier, or against the object's own key for a self-signed certificate and for a request's proof of possession. A composite signature is valid only if both parts verify, and the page shows each part. Beyond the signature, the inspector applies the rules of the RFCs:

AlgorithmIdentifier parameters must be absent for every post-quantum and composite algorithm;
the inner and outer signature algorithms of a certificate must match (RFC 5280);
a signature key must not carry encryption key usages;
an ML-KEM certificate's key usage is keyEncipherment and nothing else, and an ML-KEM request cannot sign itself (RFC 9935);
HashML-DSA identifiers must not appear in certificates (RFC 9881 §8.3);
a HashSLH-DSA key is bound to pre-hash signatures (RFC 9909).

A certificate whose key is classical, or whose post-quantum key is signed classically, is flagged. Its security against a future quantum computer is no better than the classical part.

Why they are so large

An ML-DSA-65 public key is 1,952 bytes and its signature 3,309 bytes, so a leaf certificate grows from about 500 bytes with ECDSA P-256 to about 5.5 KB. A chain of two such certificates adds 10 KB or more to a TLS handshake. For each object the inspector computes the exact size of the same structure with an ECDSA P-256, Ed25519 or RSA-2048 key and signature, and shows where the bytes go: key, signature, extensions and the rest. That is why browsers are not yet adding ML-DSA certificates to the Web PKI. The post-quantum migration guide explains the Merkle Tree Certificates approach instead. Private PKIs (mTLS, devices, VPNs) can pilot ML-DSA today.

To sign and verify with these algorithms directly, use the post-quantum signature lab; for the ASN.1 structure byte by byte, the ASN.1 explorer. Code for producing such certificates with OpenSSL, Go, Java and .NET is in ML-DSA for developers.