PKI and Certificate Authorities: Who Actually Issues a Certificate?

It is common to hear that “PKI issues certificates.” Strictly speaking, that is not precise.

The Certificate Authority (CA) is the entity that issues a certificate. Public Key Infrastructure (PKI) is the larger system of policies, roles, software, procedures, certificates, key pairs, trust stores, and status services that makes certificate-based trust work.

In short:

PKI is the certificate trust system; a CA is the organization or service that signs and issues certificates within that system.

PKI Is the System Around Certificates

NIST defines PKI as a framework for issuing, maintaining, and revoking public-key certificates. That framework includes more than a signing service. It also covers how identities are checked, how keys are protected, how certificates are distributed, how clients decide what to trust, and how revoked certificates are reported.

The main concepts are related but not interchangeable:

RFC 5280 uses similar PKI roles: end entity, CA, optional RA, CRL issuer, and repository. A repository stores certificates and revocation information for distribution; it does not become the CA merely because it hosts the files.

What a CA Actually Does

Suppose a fictional service operates at www.example.com. It generates a key pair:

Private key: kept by the service
Public key:  shared in the certificate request

The service then sends a Certificate Signing Request (CSR) to a CA, either directly or through an RA. The request commonly contains the public key and the names for which the certificate is requested.

After the request is approved, the CA creates a certificate containing information such as:

Subject:               CN=www.example.com, O=Example Services
Subject Alternative Name: DNS:www.example.com
Issuer:                CN=Example Intermediate CA
Validity:              notBefore ... notAfter
Subject public key:    the public key generated by the service
CA signature:          a signature made with the CA private key

The CA’s signature binds the subject information and public key together. Anyone who has the CA’s trusted public key can verify that the certificate was signed by that CA and that the signed contents have not been modified.

The CA does not need the service’s private key. The service keeps that key and uses it to prove possession of the key pair during TLS or another protocol. If the private key is exposed, an attacker may be able to impersonate the service even when the certificate itself is genuine.

A Certificate Chain

A public certificate is often issued by an intermediate CA rather than directly by a root CA. The result is a certification path:

Root CA certificate       trusted by the client
	|
	+-- signs the intermediate CA certificate
			|
			+-- Example Intermediate CA signs the certificate for www.example.com
					|
					+-- www.example.com uses the certificate and its private key

The root CA is a trust anchor: the client already has trusted information about it, usually through a trust store. The intermediate CA extends that trust to the leaf or end-entity certificate. The leaf certificate identifies the service and carries the service’s public key, but it is not normally allowed to issue other certificates.

During validation, a client checks the chain of signatures, certificate validity periods, constraints, key usage, revocation status when applicable, and the identity of the service it intended to contact. A certificate is not trusted simply because it contains a familiar-looking name.

Common Name Is a Field, Not the Issuer

Common Name (CN) is an attribute that may appear in a certificate’s subject distinguished name. For example:

Subject: CN=www.example.com, O=Example Services

In this example, www.example.com is the value of the Common Name. It is part of the subject information; it is not a CA, and it does not mean that the subject issued the certificate.

The Common Name should also not be confused with the modern TLS identity check. RFC 9525 says that a service identity is represented in subjectAltName, such as:

Subject Alternative Name:
	DNS:www.example.com

For a TLS connection to www.example.com, the client compares the expected hostname with the appropriate DNS name in subjectAltName. The current specification does not permit the Common Name RDN to identify a service. Older certificates and older clients may still contain or inspect a CN value, which is why it remains visible in certificate tools, but it is a legacy field for hostname identity.

This gives the example a useful division of responsibility:

CN=www.example.com
	descriptive subject attribute in a certificate

DNS:www.example.com in subjectAltName
	typed service identity used for current TLS matching

Example Intermediate CA
	CA that signs the certificate

PKI
	the complete trust, issuance, distribution, validation, and revocation system

The Precise Vocabulary

These sentences are accurate:

• “The CA issued the certificate for www.example.com.”
• “The CA signed the certificate with its private key.”
• “The certificate contains a Common Name of www.example.com.”
• “The client validated the certificate chain to a trusted root CA.”
• “The PKI provides the policies and services for issuance, trust, distribution, and revocation.”

This sentence is too vague:

• “PKI issued the certificate.”

It is understandable as shorthand, but it hides the important distinction between the infrastructure and the authority that performs the signing operation.

References

• NIST CSRC Glossary: Public Key Infrastructure - Defines PKI as a framework for issuing, maintaining, and revoking public-key certificates.
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - Defines PKI entities, certificate fields, certification paths, trust anchors, subject alternative names, and revocation mechanisms.
• RFC 9525: Service Identity in TLS - Defines current TLS service-identity rules and explains why DNS names belong in subjectAltName rather than the Common Name.