CERT Lookup
Certificate (CERT) records stored in DNS.
Enter a value above to run CERT Lookup
e.g. example.com
Quick answer
CERT Lookup shows certificates published directly in DNS, such as X.509 or PGP certificates tied to a domain. Each record lists the certificate type, a key tag, the algorithm, and the certificate data itself, letting applications fetch a domain's public certificate straight from DNS.
CERT Lookup queries the CERT resource record, defined in RFC 4398, which lets you publish certificates and certificate revocation lists directly in DNS. A CERT record ties a certificate to a domain name, so applications can retrieve a public key or CRL by asking DNS instead of contacting a separate directory or key server. It is most often used for storing PGP/OpenPGP keys, X.509 (PKIX) certificates, and SPKI or IPKIX data. This tool fetches the raw CERT records at the name you enter and shows the certificate type, key tag, algorithm, and encoded payload.
How it works
The tool sends a DNS query of type CERT for the exact name you provide. Each returned record has four fields: a certificate type (for example 1=PKIX for X.509, 3=PGP for OpenPGP, 4=IPKIX, 6=IPGP), a 16-bit key tag, an algorithm number matching the DNSKEY/SIG algorithm registry, and the certificate or CRL itself carried as Base64 in the wire format. Because certificates are large, CERT answers are often big and may arrive over TCP rather than UDP.
How to read the results
Start with the type field: it tells you whether the payload is an X.509 certificate, a PGP key, an SPKI structure, or a URL pointing to the real object (the ..PKIX/..PGP variants). The key tag helps you match a certificate to a matching signature or key without decoding the whole blob; a value of 0 means the tag is unused. The algorithm field mirrors DNSSEC algorithm numbers. Decode the Base64 payload to inspect the actual certificate, subject, and validity dates.
Why it matters
CERT records let you distribute keys and certificates using infrastructure you already run, which is handy for automated PGP key discovery, S/MIME setups, and some IPsec deployments. In practice adoption is low, and most email and TLS ecosystems have moved to alternatives such as DANE (TLSA), SMIMEA, and OPENPGPKEY records. A lookup confirms whether a domain still publishes CERT data and whether the payload is current, which matters when auditing legacy configurations.
Frequently asked questions
- What certificate types can a CERT record hold?
- RFC 4398 defines PKIX (1) for X.509 certificates, SPKI (2), PGP (3) for OpenPGP keys, and the URL-based variants IPKIX (4), ISPKI (5), IPGP (6), ACPKIX (7), and IACPKIX (8). The URL variants store a pointer to the certificate rather than the certificate itself, keeping the DNS response small when the object is very large.
- Should I use CERT records or DANE/SMIMEA instead?
- For most modern needs, DANE (TLSA), SMIMEA, and OPENPGPKEY records are the better choice because they are more widely supported and integrate with DNSSEC-based validation. CERT is still valid and useful for legacy PGP key discovery or specific SPKI deployments, but you should not expect broad client support for it today.
- Why is my CERT lookup returning nothing?
- An empty result usually means no CERT record exists at that exact name, which is common because few domains publish them. Confirm the label is correct, since PGP key names may be derived from a hashed local-part. Also check that resolvers along the path are not stripping the large record; retrying over TCP or querying an authoritative server directly can help.