TLS Certificates Explained – Java Backend Developer Guide
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
A TLS certificate is normally an X.509 document that binds a public key to a subject under an issuer's digital signature. For a public HTTPS server, the domain names are listed in the Subject Alternative Name extension. The certificate also includes the issuer, serial number, validity dates, public key, usage extensions, and signature.
The matching private key is separate and remains on the server. During the handshake, the server proves that it holds that private key. The client then validates a chain to a trust anchor, checks that the requested hostname matches a SAN, confirms the certificate is within its validity period, and applies key-usage and revocation policy.
A publicly trusted CA is normal for internet sites, but it is not the only valid model. Internal services may trust a private CA or a deliberately pinned key or certificate. A self-signed certificate works only when clients are configured to trust it directly; its self-signature does not create public trust by itself.
TLS Certificates Explained – Java Backend Developer Guide
Direct Answer
An X.509 TLS certificate binds a public key to a subject under an issuer's signature. A public-server certificate usually identifies DNS names in Subject Alternative Name and includes the public key, issuer, serial number, validity period, extensions such as key usage, and a signature. The client validates the chain against its trust store, checks the requested hostname and validity, and may check revocation according to policy. Public CAs are common on the web; private CAs and pinned trust are valid in controlled systems.
Code Example
# View the fields of a live certificate
openssl s_client -connect example.com:443 -servername example.com </dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject= CN=example.com
issuer= C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
notBefore=Jan 1 00:00:00 2026 GMT
notAfter =Apr 1 23:59:59 2026 GMT
X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com
The client checks subject/SAN against the hostname, the issuer chain to a trusted root, and the dates.
Common Mistakes & Pitfalls
- Thinking the cert holds the private key: it holds the public key; the private key stays on the server.
- Ignoring SANs: modern browsers match the hostname against SANs, not the legacy Common Name.
- Forgetting expiry: an expired certificate fails verification — automate renewal (e.g. Let's Encrypt).
- Self-signed in production: not trusted by browsers; use a CA-issued certificate.
- Missing intermediates: serve the full chain or some clients can't build the path to the root.
Check your understanding
Answer these without looking back at the article.
- What is the chain of trust from a server certificate to a root CA?
- Why does the certificate contain the public key but never the private key?
- What are Subject Alternative Names and why do they matter?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.