X.509 Certificates: Structure, Types, and Generation for Developers
X.509 certificates are a cornerstone of Public Key Infrastructure (PKI), holding public keys and subject details. The standard traces back to X.500 DAP, now largely replaced by LDAP. All structures are defined in ASN.1—a metalanguage for data serialization—with encoding following BER, CER, DER rules from X.690 or XER.
Basic TBSCertificate structure:
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL
}
In ASN.1, SEQUENCE is like a struct in C. For syntax details, check X.680 (2008). Certificates primarily serve as public key containers. They also verify domain ownership or identity, though reliability varies.
Certificate Hierarchy and Types
Trust chains run from root CA to end entity.
- Root: Issuer equals subject, basicConstraints.cA = TRUE.
- Intermediate: Signed by a higher CA, building the chain.
- End-Entity: Doesn't sign others; used by final systems.
By validation level:
- DV (Domain Validated): Automated domain check via email or HTTP challenge.
- OV (Organization Validated): Verifies WHOIS, registration, contacts—takes a few days.
- EV (Extended Validation): Full business audit, exclusive domain rights, authorization. Shows as a green bar with company name. Requires jurisdictionOfIncorporationCountryName, businessCategory, serialNumber in subject.
Other types:
- Multi-Domain: SAN (subjectAltName) for multiple domains.
- Wildcard: CN=*.example.com for subdomains.
- Qualified: Personal certs per RFC 3739 with givenName, dateOfBirth, countryOfCitizenship.
Generating Certificates
Self-Signed with ECC
Elliptic Curve Cryptography (ECC) beats RSA for CPU efficiency and key size, but TLS <1.2 support varies.
Generate secp521r1 private key:
openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem
CSR with SHA256:
openssl req -new -sha256 -key private-key.pem -out server.csr -days 730
Self-sign:
openssl x509 -req -sha256 -days 365 -in server.csr -signkey private-key.pem -out public.crt
Inspect:
openssl x509 -text -noout -in public.crt
Help: openssl -help, openssl x509 -help.
With Java keytool
RSA 2048:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
Convert to PKCS12:
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -deststoretype pkcs12
Output includes SubjectKeyIdentifier (OID 2.5.29.14, non-critical per RFC 5280).
Let's Encrypt (DV)
Install certbot and get certs:
sudo certbot certonly --standalone -d example.com -d www.example.com
(For Gentoo: sudo emerge certbot; Debian: sudo apt-get install certbot -t stretch-backports; Fedora: sudo dnf install certbot).
Extensions and Analysis
Certificates use OIDs for identification: subjectKeyIdentifier ::= KeyIdentifier. Full breakdown via openssl x509 -text. Chains build trust: root → intermediates → leaf.
Key Takeaways:
- X.509 uses ASN.1: SEQUENCE like structs, DER/BER encoding.
- Types: DV/OV/EV by validation, wildcard/SAN for flexibility.
- Generation: openssl for ECC/RSA, keytool for JKS/PKCS12, certbot for Let's Encrypt.
- Chain: root (cA=TRUE) → intermediates → end-entity.
Debug chains with openssl s_client -connect host:443 -showcerts. Standards like X.680/690, RFC 5280/3739 ensure PKI interoperability.
— Editorial Team
No comments yet.