x509 - dwilson2547/wiki_demo GitHub Wiki

X.509 is a standard format for public key certificates, which are used to securely associate a public key with an identity (such as a person, organization, or device). It is a cornerstone of Public Key Infrastructure (PKI) and is widely used in secure communications, including TLS/SSL, S/MIME, and code signing.

Let’s break down X.509 in detail:

• 1. What is X.509?
• 2. Structure of an X.509 Certificate
• 3. Key Components Explained
  • A. Version
  • B. Serial Number
  • C. Signature Algorithm
  • D. Issuer
  • E. Validity Period
  • F. Subject
  • G. Subject Public Key
  • H. Extensions (v3)
  • I. Signature
• 4. How X.509 Certificates Work
  • A. Certificate Issuance
  • B. Certificate Usage
• 5. Certificate Chain and Trust
• 6. Common Use Cases
• 7. Example: X.509 Certificate in PEM Format
• 8. Security Considerations
• 9. Standards and RFCs
• 10. Summary Table: X.509 Certificate Fields
  • Why is X.509 Important?

• X.509 is a standard defined by the International Telecommunication Union (ITU) that specifies the format and semantics of public key certificates.
• It is part of the X.500 series of standards, which define directory services for computer networks.
• X.509 certificates are used to bind a public key to an identity, enabling secure communication and authentication.

An X.509 certificate contains the following key fields, encoded in ASN.1 (Abstract Syntax Notation One) and typically serialized using DER (Distinguished Encoding Rules) or PEM (Base64-encoded DER):

• v1: Basic fields (subject, issuer, public key, validity).
• v2: Adds issuer unique identifier and subject unique identifier (rarely used).
• v3: Adds extensions for additional functionality (e.g., key usage, certificate policies).

• A unique number assigned by the issuer to distinguish the certificate from others.

• Specifies the algorithm used to sign the certificate (e.g., sha256WithRSAEncryption or ecdsa-with-SHA256).

• The Certificate Authority (CA) that issued the certificate.
• Example: CN=Example CA, O=Example Org, C=US.

• Defines the time window (Not Before and Not After) during which the certificate is valid.

• The identity the certificate is issued to.
• Example: CN=example.com, O=Example Org, C=US.

• The public key (e.g., RSA or ECDSA) associated with the subject.
• Includes the algorithm and the key itself.

• Key Usage: Specifies how the key can be used (e.g., digital signature, key encipherment).
• Subject Alternative Name (SAN): Additional identities (e.g., DNS names, IP addresses).
• Basic Constraints: Indicates if the certificate is a CA certificate.
• Certificate Policies: Defines the policies under which the certificate was issued.

• The issuer signs the certificate using its private key.
• The signature ensures the certificate’s integrity and authenticity.

1. A Certificate Signing Request (CSR) is generated by the subject, containing the subject’s public key and identity.
2. The CA validates the subject’s identity and issues a certificate by signing the CSR with its private key.
3. The certificate is distributed to the subject.

• When a user (e.g., a web browser) receives a certificate, it:
  1. Verifies the signature using the CA’s public key.
  2. Checks the validity period.
  3. Validates the certificate chain (if applicable).
  4. Uses the subject’s public key for secure communication (e.g., TLS).

• Root CA: A self-signed certificate at the top of the trust hierarchy.

• Intermediate CAs: Certificates issued by the root CA to delegate trust.

• End-Entity Certificates: Certificates issued to users, servers, or devices.

• Trust Model: Users trust certificates issued by CAs whose root certificates are pre-installed in their systems (e.g., browsers, operating systems).

• TLS/SSL: Secures web traffic (HTTPS).
• S/MIME: Encrypts and signs emails.
• Code Signing: Verifies the authenticity of software.
• VPNs: Authenticates users and devices.

-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgISA... (Base64-encoded DER)
-----END CERTIFICATE-----

• Certificate Revocation: Certificates can be revoked if compromised (e.g., using CRLs or OCSP).
• Weak Algorithms: Older certificates may use weak algorithms (e.g., SHA-1, 1024-bit RSA).
• Phishing and Spoofing: Attackers may create fake certificates to impersonate legitimate entities.

• RFC 5280: The primary standard for X.509 certificates.
• PKCS #10: Defines the format for Certificate Signing Requests (CSRs).
• PKCS #12: Defines the format for storing certificates and private keys (e.g., .p12 or .pfx files).

X.509 certificates enable secure authentication and encryption in modern systems. They are the backbone of PKI, ensuring that public keys can be trusted and securely associated with identities.

Would you like to dive deeper into Certificate Authorities (CAs), certificate revocation, or how X.509 is used in TLS?