What is X.509?
X.509 is an ITU-T standard for Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI) that defines the format of public key certificates. These certificates are used in many internet protocols, including TLS/SSL for HTTPS, which secures web browsing, email encryption (S/MIME), code signing, and various authentication mechanisms.
An X.509 certificate binds an identity (such as a domain name, organization, or individual) to a public key using a digital signature from a trusted Certificate Authority (CA). This allows parties to verify that a public key belongs to the claimed identity, forming the foundation of secure communications on the internet.
Everyday Usage: Every time you see the padlock icon in your browser's address bar indicating a secure HTTPS connection, an X.509 certificate is being used to verify the website's identity and establish encrypted communication. Your browser checks the certificate to ensure you're really connecting to the legitimate website and not an imposter.
Certificate Structure
An X.509 certificate contains several key components organized in a standardized structure:
Version
Certificate format version (v1, v2, or v3). Modern certificates use v3 which supports extensions.
Serial Number
Unique identifier assigned by the Certificate Authority for tracking and revocation.
Signature Algorithm
Cryptographic algorithm used to sign the certificate (e.g., SHA256-RSA, ECDSA).
Issuer
Distinguished Name (DN) of the Certificate Authority that issued the certificate.
Validity Period
Not Before and Not After dates defining when the certificate is valid.
Subject
Distinguished Name (DN) of the certificate holder (domain, organization, person).
Subject Public Key Info
The public key and algorithm identifier (RSA, ECDSA, etc.).
Extensions (v3)
Additional fields like Subject Alternative Names (SANs), key usage, extended key usage.
Signature
Digital signature from the CA, proving the certificate's authenticity.
Certificate Formats
X.509 certificates can be encoded in different formats:
PEM (Privacy-Enhanced Mail)
Base64-encoded certificate wrapped in BEGIN/END markers. Most common format for web servers and applications.
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0UG+mRcSdMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwODIyMDUwNTI5WhcNMTgwODIyMDUwNTI5WjBF
...
-----END CERTIFICATE-----
DER (Distinguished Encoding Rules)
Binary format. Commonly used for certificates in Java applications and some Windows environments.
PKCS#7 / P7B
Can contain multiple certificates (certificate chain). Used for certificate distribution.
PKCS#12 / PFX
Binary format that can store certificate and private key together, often password-protected.
Format Conversion: CyberChef can parse certificates in PEM or DER format. If you have a different format, you may need to convert it first using other CyberChef operations like "From Base64" for PEM or direct binary input for DER.
Using Parse X.509 Certificate in CyberChef
CyberChef's Parse X.509 Certificate operation extracts and displays all information from an X.509 certificate in a human-readable format. This is invaluable for certificate inspection, troubleshooting SSL/TLS issues, security auditing, and understanding certificate properties.
Steps to Parse a Certificate:
- Obtain the certificate (from a file, website, or elsewhere)
- Paste the certificate into CyberChef's input pane (PEM or DER format)
- Add the "Parse X.509 certificate" operation
- View the parsed output showing all certificate fields
- Examine specific fields of interest (validity dates, subject, extensions)
Common Use Cases
1. Verifying Certificate Details
Check that a certificate has the correct domain names, validity period, and issuer before deploying it to a web server.
2. Troubleshooting SSL/TLS Issues
When a website shows certificate errors, parse the certificate to identify problems like expired dates, wrong domain names, or untrusted issuers.
3. Security Auditing
Examine certificates for weak algorithms (MD5, SHA1), short key lengths (< 2048 bits RSA), or misconfigured extensions.
4. Certificate Renewal Tracking
Check expiration dates across multiple certificates to plan renewals and avoid service disruptions.
5. Understanding Certificate Chains
Parse intermediate and root CA certificates to understand the trust chain from end-entity certificate to trusted root.
6. Compliance Verification
Ensure certificates meet organizational or regulatory requirements (key size, validity period, approved CAs).
Important Certificate Fields Explained
Subject Alternative Names (SANs)
Modern certificates use SANs to list all domain names the certificate is valid for. A single certificate can secure multiple domains and subdomains.
Subject Alternative Names:
DNS: example.com
DNS: www.example.com
DNS: mail.example.com
DNS: *.api.example.com
Key Usage
Specifies what the certificate key can be used for:
- Digital Signature: For signing data
- Key Encipherment: For encrypting keys
- Certificate Signing: For signing other certificates (CA certificates)
- CRL Signing: For signing Certificate Revocation Lists
Extended Key Usage
Further restricts certificate usage:
- TLS Web Server Authentication: For HTTPS servers
- TLS Web Client Authentication: For client certificates
- Code Signing: For signing software
- Email Protection: For S/MIME email encryption
Authority Information Access (AIA)
URLs where the issuer's certificate and OCSP responder can be found for validation.
CRL Distribution Points
URLs where Certificate Revocation Lists can be downloaded to check if the certificate has been revoked.
Obtaining Certificates for Analysis
From a Website (Browser)
- Click the padlock icon in the address bar
- Click "Certificate" or "View Certificate"
- Export or copy the certificate in PEM format
- Paste into CyberChef for parsing
Using OpenSSL Command Line
# Get certificate from website
openssl s_client -connect example.com:443 -showcerts
# Extract just the certificate
openssl s_client -connect example.com:443 2>/dev/null | \
openssl x509 -outform PEM
# View certificate details (alternative to CyberChef)
openssl x509 -in certificate.pem -text -noout
From a File
If you have a certificate file (.crt, .cer, .pem), simply read its contents and paste into CyberChef.
Certificate Validation and Trust
Chain of Trust
X.509 certificates work in a hierarchy:
- Root CA: Self-signed, trusted by operating system/browser
- Intermediate CA: Signed by root, signs end-entity certificates
- End-Entity Certificate: The actual certificate for a website/service
Validation Process
When validating a certificate, systems check:
- Current date/time is within validity period
- Certificate signature is valid (signed by trusted CA)
- Certificate chain leads to a trusted root CA
- Certificate has not been revoked (via CRL or OCSP)
- Domain name matches certificate subject/SAN
- Certificate is used for its intended purpose (key usage)
Security Note: Parsing a certificate shows you its contents but doesn't validate its trustworthiness. A certificate could have valid structure but be issued by an untrusted CA, be expired, or be revoked. Always verify certificates through proper validation mechanisms.
Common Certificate Issues
| Issue |
Description |
How to Identify |
| Expired Certificate |
Certificate past its "Not After" date |
Check validity period in parsed output |
| Not Yet Valid |
Current date before "Not Before" date |
Check validity period start date |
| Wrong Domain |
Certificate issued for different domain |
Check Subject CN and SANs |
| Self-Signed |
Issuer and subject are identical |
Compare issuer and subject DNs |
| Weak Signature |
Using deprecated algorithm (MD5, SHA1) |
Check signature algorithm field |
| Short Key Length |
RSA key < 2048 bits |
Check public key size |
| Missing SANs |
No Subject Alternative Names extension |
Check extensions list |
Certificate Extensions Deep Dive
Critical vs Non-Critical
Extensions can be marked as critical or non-critical. If a system doesn't understand a critical extension, it must reject the certificate. Non-critical extensions can be safely ignored.
Common Extensions
- Subject Alternative Name (SAN): Additional identities (domains, IPs, emails)
- Basic Constraints: Identifies CA certificates and path length constraints
- Name Constraints: Restricts what names a CA can issue certificates for
- Policy Constraints: Defines certificate policies
- Subject Key Identifier: Hash of the public key for identification
- Authority Key Identifier: Identifies the CA's public key
- Certificate Policies: OIDs indicating certificate usage policies
CyberChef Recipe Ideas
Here are some useful recipe combinations involving certificate parsing:
- Website Certificate Analysis: HTTP Request (to get cert) → Parse X.509 certificate
- Certificate Extraction from Bundle: Regular Expression → Parse X.509 certificate (extract from chain)
- DER to PEM: From Base64 → To Hex → Parse X.509 (handle DER format)
- Bulk Certificate Analysis: Split → Parse X.509 certificate (parse multiple certificates)
- Certificate Field Extraction: Parse X.509 → Regular Expression (extract specific fields)
- Expiration Monitoring: Parse X.509 → Extract dates → Compare (check expiration)
Best Practices
For Certificate Deployment
- Always use certificates from trusted Certificate Authorities
- Use 2048-bit or longer RSA keys (or 256-bit ECDSA)
- Include all necessary domain names in SANs
- Set appropriate validity periods (typically 90 days to 1 year)
- Configure proper key usage and extended key usage
- Include OCSP and CRL information for revocation checking
For Certificate Analysis
- Verify certificates before deploying to production
- Check expiration dates and set up renewal reminders
- Audit signature algorithms and key sizes regularly
- Ensure certificate chain is complete
- Validate that SANs cover all required domains
- Keep records of certificate serial numbers for tracking
Automation Tip: Many organizations automate certificate parsing and monitoring to track expiration dates, identify weak certificates, and ensure compliance. CyberChef can be part of this workflow for manual verification and troubleshooting.
← Back to Operations Guide