An X.509 certificate is a high-security credential used to encrypt, sign and authenticate transmissions, files and other data. X.509 certificates secure SSL/TLS channels, authenticate SSL/TLS servers (and sometimes clients), encrypt/sign SMIME, AS1, AS2, AS3 and some “secure zip” payloads, and provide non-repudiation to the AS1, AS2 and AS3 protocols.
The relative strength of various certificates is often compared through their “bit length” (e.g., 1024, 2048 or 4096 bits) and longer=stronger. Certificates are involved in asymmetric cryptography so their bit lengths are often 8-10x longer (or more) than the bit length of the symmetric keys they are used to negotiate (usually 128 or 256 bits).
Each certificate either is signed by another certificate or is “self signed”. Certificates that are signed by other certificates are said to “chain up” to an ultimate “certificate authority” (“CA”) certificate. CA certificates are self-signed and typically have a very large bit length. (If a CA certificate was ever cracked, it would put thousands if not millions of child certificates at risk.) CAs can be public commercial entities (such as Verisign or GoDaddy) or private organizations.
Most web browsers and many file transfer clients ship with a built-in collection of pre-trusted CA certificates. Any certificate signed by a certificate in these CA chains will be accepted by the clients without protest, and the official CA list may be adjusted to suit a particular installations.
In addition, many web browsers also ship with a built-in and hard-coded collection of pre-trusted “Extended Validation” CA certificates. Any web site presenting a certificate signed by am extended validation certificate will cause a green bar or other extra visual clue to appear in the browser’s URL. It is not typically possible to edit the list of extended validation certificates, but it is usually possible to remove the related CA cert from the list of trusted CAs to prevent these SSL/TLS connections from being negotiated.
X.509 certificates are stored by application software and operating systems in a variety of different places. Microsoft’s Cryptographic Providers make use of a certificate store built into the Microsoft operating systems. OpenSSL and Java Secure Sockets Extension (JSSE) often make use of certificate files.
Certificates may be stored on disk or may be burned into hardware devices. Hardware devices often tie into participating operating systems (such as hardware tokens that integrate with Microsoft’s Certificate Store) or application software.
The most widespread use of X.509 hardware tokens may be in the U.S. Department of Defence (DoD) CAC card implementation. This implementation uses X.509 certificates baked into hardware tokens to identify and authenticate individuals through a distributed Active Directory implementation. CAC card certs are signed by a U.S. government certificate and bear a special attribute (Subject Alternative Name, a.k.a. “SAN”) that is used to map individual certificates to records in the DoD’s Active Directory server via “userPrincipalName” AD elements.
See the Wikipedia entry for X.509 if you are interested in the technical mechanics behind X.509.