Generated by DeepSeek V3.2| X.509 | |
|---|---|
| Name | X.509 |
| Extension | .cer, .crt, .der, .pem |
| Mime | application/pkix-cert, application/x-x509-ca-cert |
| Owner | International Telecommunication Union, Internet Engineering Task Force |
| Released | 0 1988 |
| Latest release version | Version 3 |
| Genre | Public key certificate |
| Container for | Public key, Digital signature |
| Standard | ITU-T X.509, RFC 5280 |
X.509. It is a standard format for public key certificates, crucial for establishing trust in digital communications. Defined jointly by the International Telecommunication Union and the Internet Engineering Task Force, it forms the backbone of the public key infrastructure used across the Internet. These certificates bind a public key to an identity, such as a person or a web server, and are digitally signed by a trusted certificate authority.
The X.509 standard was first published in 1988 as part of the ITU-T X.500 series of directory service standards. Its development was heavily influenced by the work of early cryptography pioneers and the need for a scalable system of trust. The format was later adapted for the Internet by the Internet Engineering Task Force, most notably in RFC 5280, which defines the profile for Internet X.509 Public Key Infrastructure. This standard is fundamental to protocols like Transport Layer Security, which secures connections to websites and services. Major technology companies, including Microsoft, Apple Inc., and Google, rely on X.509 certificates within their operating systems and browsers.
An X.509 certificate contains several mandatory and optional fields defined by Abstract Syntax Notation One encoding rules. The core data includes the version number, a unique serial number, and information about the signature algorithm used, such as SHA-256 with RSA. It holds the distinguished name of the issuing certificate authority and the subject entity, along with the subject's public key information. Validity periods are defined by "not before" and "not after" timestamps, and the certificate is secured by the digital signature of the issuer. Version 3 certificates introduced critical extensions, governed by RFC 5280, such as Subject Alternative Name for specifying additional identities like DNS names.
The lifecycle begins with a certificate signing request generated by an entity's software, such as OpenSSL. This request is submitted to a certificate authority like DigiCert or Let's Encrypt for validation and signing. Once issued, the certificate is distributed and installed on systems like Apache HTTP Server or Microsoft IIS. Certificates must be renewed before their expiration to avoid service disruption, a process often automated by tools like Certbot. Revocation, handled via Certificate Revocation List or the Online Certificate Status Protocol, is critical if a private key is compromised, with status checked by clients like Mozilla Firefox and Google Chrome.
The most visible application is securing HTTP traffic via HTTPS, where Transport Layer Security uses X.509 certificates to authenticate web servers for browsers like Safari (web browser). They are equally vital for securing email through S/MIME and code signing for software distributed by entities like Adobe Inc. or Microsoft. Within enterprises, certificates authenticate users and devices for Wi-Fi access via IEEE 802.1X and secure Virtual Private Network connections from vendors like Cisco Systems. They also underpin document signing for European Union eIDAS compliance and client authentication for online banking platforms.
Security heavily depends on the trustworthiness of the issuing certificate authority, with incidents like the breach of DigiNotar demonstrating systemic risk. Weak cryptography, such as the deprecated MD5 or SHA-1 algorithms, has led to practical attacks documented by researchers at the Katholieke Universiteit Leuven. Compromised private keys necessitate immediate revocation, though failures in Certificate Revocation List distribution can leave systems vulnerable. The complexity of the public key infrastructure and errors in validation libraries, such as those in OpenSSL leading to the Heartbleed bug, present ongoing challenges. Emerging technologies like Certificate Transparency, pioneered by Google, aim to detect misissued certificates by creating public, auditable logs.
Category:Cryptography standards Category:Internet standards Category:Public-key infrastructure