Frequently Asked Questions

While the industry legacy term "SSL Certificate" is still tossed around by sales teams and out-of-date docs, SSL (Secure Sockets Layer) has been deprecated for years due to protocol vulnerabilities. Certificates rely strictly on TLS (Transport Layer Security) protocols using X.509 v3 structure standards.

At its core, a Digital Certificate (specifically an X.509 certificate) is a cryptographically bound electronic credential that proves identity across a network. I was once taught to think of it as a digital passport for machines, servers, and software services. Instead of a government issuing physical paper to a person, a trusted Certificate Authority (CA) signs a public key file to guarantee that a specific server, domain, or device actually owns the identity it claims to hold.

Without digital certificates, encrypted communications across the internet and enterprise networks—whether HTTPS, TLS-encrypted backend APIs, or automated machine authentication—would be wide open to man-in-the-middle attacks and unauthenticated eavesdropping.

When a system requests or installs an X.509 certificate, it relies on asymmetric cryptography (a public and private key pair):

1. The Key Pair:
   • Private Key: Generated locally on the host, stored with strict access controls, and never shared over the wire. It signs data and proves ownership.
   • Public Key: Encapsulated inside the certificate itself and distributed freely to clients or connecting peers.
2. The Certificate Signing Request (CSR):
   To get a trusted certificate, an administrator or automated agent generates a CSR containing the public key and identity attributes (Subject Distinguished Name, SANs). This request is submitted to a CA.
3. CA Signature & Verification:
   The CA validates ownership of the domain or host, appends its digital signature using its own private key, and issues the complete certificate. Connecting clients verify this payload against a trusted Root CA store to establish an encrypted TLS tunnel.

An X.509 certificate is structured using ASN.1 syntax and contains non-negotiable metadata fields that drive platform validation rules:

• Subject Alternative Name (SAN): The primary extension defining the valid fully qualified domain names (FQDNs), IP addresses, or Uniform Resource Identifiers (URIs) the certificate protects.
• Period (NotBefore / NotAfter): The explicit start and expiration timestamps. Browsers and CLM engines strictly enforce these boundaries—once past the NotAfter date, TLS handshakes fail immediately.
• Issuer: The identity and signature of the issuing CA (Root or Intermediate).
• Key Usage & Extended Key Usage (EKU): Defines the operational scope of the key pair (e.g., Server Authentication, Client Authentication, or Code Signing).
• Serial Number: A unique alphanumeric identifier assigned by the CA for revocation tracking via Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP).