Client vs. Server Certificates: Understanding Certificates, CSRs, and Private Keys

TLS certificates are commonly associated with web servers, but certificates can identify both servers and clients.

A server certificate allows a client to verify the identity of a server. A client certificate allows a server to verify the identity of a client, machine, workload, or application.

Both rely on the same fundamental PKI concepts: public/private key pairs, Certificate Signing Requests (CSRs), and Certificate Authorities (CAs).

---

Q: What Is a Server Certificate?

A server certificate identifies a server or service to clients connecting to it.

For example, when a browser connects to:

https://api.example.com

the server presents its TLS server certificate. The client validates the certificate and determines whether it trusts the CA that issued it.

A simplified flow looks like this:

Client
   │
   │ HTTPS / TLS
   ▼
Web / API Server
   │
   │ Presents Server Certificate
   ▼
Client validates:
   - Trusted CA?
   - Correct hostname?
   - Certificate valid?
   - Certificate not expired?

Server certificates are the certificates most people encounter when using HTTPS websites.

---

Q: What Is a Client Certificate?

A client certificate works in the opposite direction.

Instead of the server proving its identity to the client, the client proves its identity to the server.

For example:

AI Agent
   │
   │ Client Certificate
   ▼
API Gateway
   │
   │ Verify Client Identity
   ▼
Authorized API

The client could be a:

• Machine
• Application
• Microservice
• Container
• AI agent
• API client
• Enterprise workload

For machine-to-machine communication, client certificates can provide strong cryptographic workload identity.

---

Q: Is a Machine Certificate the Same as a Client Certificate?

Not necessarily, but a machine certificate can act as a client certificate.

The terms describe slightly different things.

Machine certificate describes the identity represented by the certificate.

Client certificate describes the certificate’s role during a TLS connection.

For example, an AI agent could have a certificate identifying it as:

AI-Agent-123

When that agent connects to an API Gateway and presents the certificate, the certificate is functioning as a client certificate.

A useful way to think about it is:

Machine certificate = identity

Client certificate = role during the connection

---

Q: What Is a Certificate Authority (CA)?

A Certificate Authority is a trusted entity that issues and cryptographically signs certificates.

For example:

Enterprise Root CA
        │
        ▼
Workload Intermediate CA
        │
        ▼
AI-Agent-123 Certificate

An API Gateway might be configured to trust the Enterprise Root CA or a particular intermediate CA.

When AI-Agent-123 connects, the gateway can verify that its certificate chains back to a trusted CA.

---

Q: Does the CA Issue Client Certificates?

Yes.

A CA can issue both server certificates and client certificates.

A client certificate will typically contain an Extended Key Usage (EKU) indicating:

Client Authentication

A server certificate typically contains:

Server Authentication

Some certificates can contain both usages, although organizations often separate them for security and policy reasons.

---

Q: Does the CA Generate the Client’s Private Key?

Normally, no.

A fundamental PKI principle is that the private key should remain under the control of the entity using it.

The client typically generates a key pair:

Client / Machine

Private Key
     │
     └────────── Stays on Client

Public Key
     │
     ▼
Certificate Signing Request (CSR)
     │
     ▼
Certificate Authority

The CSR contains the public key, along with requested identity information and other certificate-related data.

It does not contain the private key.

---

Q: What Exactly Is a CSR?

CSR stands for Certificate Signing Request.

It is a request sent to a CA asking it to issue a certificate.

Conceptually:

Generate Key Pair
      │
      ├── Private Key → Keep Secret
      │
      └── Public Key
              │
              ▼
             CSR
              │
              ▼
              CA
              │
       Validate Request
              │
       Sign Certificate
              │
              ▼
        TLS Certificate

The CSR also contains a digital signature created using the corresponding private key. This provides proof that the requester possesses the private key corresponding to the public key in the request.

---

Q: Does a Server Certificate Work the Same Way?

Yes.

Traditional server certificate enrollment follows essentially the same process.

For example:

API Server
    │
    ├── Generate Private Key
    │        │
    │        └── Remains on Server
    │
    ├── Generate Public Key
    │
    └── Generate CSR
             │
             ▼
             CA
             │
       Validate Identity
             │
       Sign Certificate
             │
             ▼
      Server Certificate

The CA needs the server’s public key, but it does not need the server’s private key.

---

Q: What Is the Difference Between Client and Server Certificates?

The cryptographic concepts are nearly identical. The primary difference is whose identity is being authenticated and how the certificate is intended to be used.

	Server Certificate	Client Certificate
Primary purpose	Authenticate a server	Authenticate a client/workload
Private key generated by	Server/workload	Client/workload
Private key sent to CA	No	No
Public key provided to CA	Yes	Yes
CSR commonly used	Yes	Yes
CA signs certificate	Yes	Yes
Certificate proves	Server identity	Client identity
Typical EKU	Server Authentication	Client Authentication
Common example	HTTPS website/API	Machine, microservice, AI agent

The fundamental PKI process is therefore largely the same.

---

Q: What Happens in Mutual TLS (mTLS)?

With ordinary HTTPS, the client authenticates the server.

With mutual TLS, both sides authenticate each other.

AI Agent                         API Gateway
    │                                │
    │ <── Server Certificate ─────── │
    │                                │
    │ Validate Server               │
    │                                │
    │ ─── Client Certificate ──────> │
    │                                │
    │                         Validate Client
    │                                │
    │ <====== Secure mTLS =========> │

The API Gateway proves its identity using a server certificate.

The AI agent proves its identity using a client certificate.

Both certificates ultimately rely on CAs trusted by the respective validating parties.

---

Q: Does Authentication Mean the Client Is Authorized?

No.

This is an important distinction.

A valid client certificate establishes an authenticated identity. It does not automatically mean that identity should have access to every API.

For example:

AI-Agent-123
      │
      │ Client Certificate
      ▼
API Gateway
      │
      ├── Authentication
      │     "Who are you?"
      │
      └── Authorization
            "What are you allowed to do?"
                  │
                  ▼
             Authorized API

Certificate validation establishes identity.

Authorization policies determine what that identity can access.

---

Q: Does the Private Key Always Stay on the Client or Server?

That is the preferred traditional model, but there are exceptions.

Cloud platforms and managed certificate services may generate and manage private keys on behalf of workloads.

The private key may therefore reside inside:

• A server
• A container or workload
• A TPM
• An HSM
• A secrets or key-management platform
• A managed cloud TLS service

The important security principle is not necessarily that the key must physically exist on the server.

It is that:

The private key must remain protected and should never be exposed simply because a CA needs to issue a certificate.

A CA only needs the public-key information necessary to create and sign the certificate.

---

Q: What Is the Simplest Way to Remember All of This?

Think of certificates as cryptographically verified identity documents.

A server certificate says:

“I am the server you intended to connect to.”

A client certificate says:

“I am an authorized machine, workload, application, or user connecting to you.”

A CSR says:

“Here is my public key and requested identity information. Please issue me a certificate.”

And the Certificate Authority says:

“I have validated this request according to my policies, and I am signing this certificate so systems that trust me can verify it.”

The private key, meanwhile, remains protected by the entity or key-management system responsible for using it.

That combination—private key + public key + CSR + CA-signed certificate + trust policy—forms the foundation of certificate-based identity for both servers and clients.