TLS certificates help an HTTPS client check that it has reached the service named in its URL. Encryption protects the conversation; certificate validation helps establish who is on the other end.
A Linux server can answer on port 443 and still fail that identity check. To understand the warning, separate the certificate’s name, its chain of signatures and the client’s trust settings. This lesson explains those parts before you inspect a disposable certificate locally.
A TLS certificate is a signed public document that associates a public key with an identity, such as a website hostname. The client checks the requested name, the certificate’s permitted use and validity, and a certification path to an authority it accepts.
The server must also demonstrate possession of the corresponding private key during the TLS handshake. Copying a public certificate alone does not provide that proof.
Separate certificates from private keys, follow a chain of trust, distinguish hostname checks from issuer checks, and observe how explicitly trusting a certificate changes one local verification command.
- Where the certificate fits in an HTTPS connection
- TLS certificates, private keys and session keys have different jobs
- How a chain of trust connects the server to the client
- A trusted issuer does not make every hostname valid
- Mini lab: see how a trust decision changes verification
- Create a private temporary workspace
- Describe the certificate and generate its key
- Inspect the public document
- Compare two verification decisions
- Remove only the exercise files
- When TLS certificates fail validation
- Knowledge check
- Servers Academy — Key Takeaway
- Official references
Where the certificate fits in an HTTPS connection
Suppose you open https://app.example.test/.
This is a hypothetical service used throughout the lesson.
Its hostname tells the client which service identity to expect.
Name resolution finds an address. A transport connection carries the exchange. TLS then establishes a protected channel with the server, and HTTP carries the website request inside it. HTTP/1.1 and HTTP/2 commonly use TCP; HTTP/3 uses QUIC. The certificate’s identity role remains relevant in both cases.
If those layers are unfamiliar, start with Linux hostname resolution and how TCP connections work . DNS finding an address and TCP reaching it do not themselves authenticate the website.
A reverse proxy or CDN may terminate the browser’s TLS connection before traffic reaches your application. In that setup, the browser validates the certificate presented by that edge service. The edge-to-origin connection is a separate connection with its own configuration.
TLS certificates, private keys and session keys have different jobs
The certificate contains a public key and information signed by its issuer. An issuer is the entity that signs the certificate. A certificate authority, or CA, issues certificates under defined validation and policy rules.
| Item | What it does | Who may receive it? |
|---|---|---|
| Certificate | Associates a public key with names and other signed information. | Clients can receive it; it is public. |
| Private key | Creates cryptographic proof for the corresponding public key. | Only the authorized signing component should access it. |
| Session traffic keys | Protect the data exchanged over a particular connection. | The connection’s participants derive and use them. |
In a normal certificate-authenticated TLS 1.3 handshake, the server signs handshake information, and the client checks the signature using the certificate’s public key. The peers derive traffic keys through the handshake; those keys are not copied from the certificate. See RFC 8446’s CertificateVerify description .
The certificate also carries fields such as an issuer, validity dates,
allowed uses and extensions. For HTTPS names, the Subject Alternative
Name extension—usually abbreviated SAN—is the field to inspect.
A filename such as website.pem says nothing about
which hostname is covered.
How a chain of trust connects the server to the client
Public TLS certificates are commonly issued through an intermediate CA. The client verifies a sequence of signatures and certificate constraints until it reaches an accepted trust anchor. A trust anchor is a starting point the client already accepts through its trust configuration.
The server normally supplies its leaf and the intermediate certificates needed to build a usable path. Sending a root alongside them does not make that root trusted. The client must already accept a suitable anchor. Let’s Encrypt’s chain documentation shows a real issuer hierarchy; cross-signing can give clients more than one possible path.
A root certificate is often self-signed. Its self-signature does not create trust: the client’s decision to accept that root does. Otherwise, anyone could create a root and claim authority over every website.
Path validation includes more than checking that one signature matches. Certificate constraints and intended use matter too. RFC 5280 specifies the public-key certificate path validation framework.
A trusted issuer does not make every hostname valid
The client compares the identity it requested with the identity presented by the service. For an HTTPS DNS hostname, that means matching against appropriate DNS entries in SAN. Modern service-identity guidance does not use the legacy Common Name field as a substitute.
In our hypothetical example, a valid certificate for
app.example.test does not automatically cover
admin.example.test.
A wildcard such as *.example.test can match one label
such as app.example.test; it does not cover
example.test or one.app.example.test.
These matching rules are described in
RFC 9525
.
Server Name Indication, or SNI, is a TLS extension that lets the client indicate a hostname so a shared server can choose a certificate. Selecting a certificate and verifying its name are separate operations. Sending the right SNI value does not itself prove a hostname match.
What a valid certificate does not promise: a trusted HTTPS connection does not certify that a website is honest, that its application has no vulnerabilities or that a purchase is safe. Domain-validation issuance checks control of a domain, not the quality of its content. Let’s Encrypt explains that validation process .
Mini lab: see how a trust decision changes verification
This offline exercise creates a one-day, self-signed certificate
for lesson.test. It starts no server and changes
no system trust store. You need a shell and the OpenSSL
command-line tools. Inspect the implementation first:
openssl versionThe commands below use widely available options documented for OpenSSL 3.x. Other implementations can differ. Stop if a command reports an unsupported option.
Create a private temporary workspace
sa_tls_dir="$(mktemp -d)"
printf '%s\n' "$sa_tls_dir"
Keep using this shell so sa_tls_dir retains the path.
The directory contains only files for this exercise.
Describe the certificate and generate its key
cat > "$sa_tls_dir/lesson.cnf" <<'EOF'
[req]
prompt = no
distinguished_name = subject
x509_extensions = extensions
[subject]
CN = lesson.test
[extensions]
subjectAltName = DNS:lesson.test
basicConstraints = critical,CA:FALSE
EOF
openssl genpkey -algorithm RSA \
-pkeyopt rsa_keygen_bits:2048 \
-out "$sa_tls_dir/lesson.key"
openssl req -new -x509 -sha256 -days 1 \
-key "$sa_tls_dir/lesson.key" \
-config "$sa_tls_dir/lesson.cnf" \
-out "$sa_tls_dir/lesson.crt"
The configuration supplies a DNS identity and marks this as a
non-CA certificate. genpkey creates a new RSA private
key; req -x509 creates the self-signed certificate.
The temporary private key is unencrypted: use it only for this
disposable exercise.
Inspect the public document
openssl x509 -in "$sa_tls_dir/lesson.crt" \
-noout -subject -issuer -dates
openssl x509 -in "$sa_tls_dir/lesson.crt" \
-noout -text
The subject and issuer identify the same self-signing entity.
Locate DNS:lesson.test under Subject Alternative Name.
Inspecting a certificate prints its contents; it does not establish trust.
Compare two verification decisions
openssl verify "$sa_tls_dir/lesson.crt"
openssl verify \
-CAfile "$sa_tls_dir/lesson.crt" \
"$sa_tls_dir/lesson.crt"
The first command should reject the newly created self-signed
certificate under the normal trust configuration. The second
should report OK: you explicitly supplied that
certificate as trusted input for this invocation.
The certificate did not become publicly trusted. You changed the verifier’s input. No browser trust was installed, no hostname check was requested and no running server proved possession of the key. This exercise isolates certificate trust rather than testing a complete HTTPS connection.
Remove only the exercise files
rm "$sa_tls_dir/lesson.key" \
"$sa_tls_dir/lesson.crt" \
"$sa_tls_dir/lesson.cnf"
rmdir "$sa_tls_dir"
unset sa_tls_dirThe generation, inspection and two verification outcomes were exercised locally with LibreSSL 3.3.6. OpenSSL 3.x options were checked against upstream documentation; execution on a Linux OpenSSL 3.x installation was not performed.
When TLS certificates fail validation
Different clients can use different trust sources and policies. A browser accepting a site does not guarantee that a minimal Linux container will accept it. curl’s certificate verification guide explains its CA-store choices and default checks.
| Problem reported | Question to investigate |
|---|---|
| Hostname mismatch | Does SAN cover the exact name in the requested URL? |
| Expired or not yet valid | Are the relevant certificate dates and the client’s clock correct? |
| Issuer cannot be found | Did the server provide needed intermediates, and does this client have an appropriate trust anchor? |
| Works in one client only | Do the clients use different CA stores, cached intermediates or validation policies? |
Disabling verification with curl --insecure removes
the identity checks you are trying to investigate. For a deliberate
private CA, configure the intended trust source instead of
accepting every peer.
For the broader application path, continue with how a website works on a VPS . Before launch, use the server pre-production checklist to test the real hostname, service and recovery plan.
Knowledge check
Someone copies a site’s public certificate. Can they impersonate its TLS server with that file alone?
No. A certificate-authenticated handshake also requires proof involving the corresponding private key. The certificate is intended to be public.
A trusted CA issued a certificate for app.example.test. Does it cover admin.example.test?
Only if the certificate contains an identity that matches admin.example.test under the applicable rules. A trusted signature and the requested name are separate checks.
Why does sending a root certificate from the server not make it trusted?
Trust comes from the client’s accepted configuration. Letting a peer create its own trust anchor would defeat the identity check.
Why did the second lab verification succeed?
The command explicitly supplied the lab certificate as trusted input. The result applies to that verification, not to browser trust or a real network service.
A connection reaches port 443 but certificate validation fails. What has already worked?
The client has reached a listening service on that transport path. That does not establish a valid certificate name, a trusted certification path or a healthy application.
Servers Academy — Key Takeaway
Think of HTTPS identity as a relationship between the requested name, the server’s certificate and private-key proof, and the client’s accepted trust anchors. No single certificate file establishes that whole relationship by itself.
When verification fails, identify which check failed before changing configuration. That habit helps preserve both service availability and the reason HTTPS is useful.
