What is a CA-signed certificate? How the signature works and how to check yours

8 min readUpdated Oct 2026

A CA-signed certificate is a certificate that carries the signature of a certificate authority. The CA stands behind the binding of a name to a public key, and a client that trusts that CA can accept the binding. The SSL certificate guide covers certificates in general. Whether a given client accepts it depends on the roots that client trusts, so a certificate signed by a CA you run yourself is CA-signed too, and a client accepts it only where path validation ends at a trust anchor that client holds. Who runs the CA and whose trust stores carry its root is the difference between a public and a private one, and what a certificate authority does covers it.

This page shows what the signature consists of, how a certificate comes to carry one, how to test your own certificate with OpenSSL, and when a CA-signed certificate is the right choice.

Signature: The signatureValue field holds a digital signature computed over the DER-encoded tbsCertificate ^[1]
Algorithm: The signatureAlgorithm field names the algorithm the CA used to sign the certificate ^[1]
Signer: The issuer field identifies the entity that has signed and issued the certificate ^[1]
Signer's key: The authority key identifier extension identifies the public key that matches the private key used to sign ^[1]
Verdict: Path validation tests the name-to-key binding against the public key of a trust anchor ^[1]

What the CA's signature covers

The signed part is the tbsCertificate. It holds the names of the subject and the issuer, the public key of the subject, the validity period and other information ^[1]. The signatureAlgorithm field records how the CA signed it, and signatureValue holds the result.

Two fields point a verifier to the signer. The issuer field names the signer. The authority key identifier identifies the signer's public key, and the subject key identifier in the signer's own certificate identifies certificates that contain that key ^[1].

A signature alone does not make a certificate trusted. The verifier runs path validation, which tests the binding of name to key against the public key of a trust anchor ^[1]. A client with a different set of trust anchors can therefore reach a different verdict on the same certificate.

How a certificate becomes CA-signed

Request. You generate a key pair and send a certificate signing request. The request holds a distinguished name and a public key, collectively signed by the requester ^[2]. How to generate a CSR safely covers the mechanics.
Validation. For a publicly trusted certificate, the CA validates the applicant's ownership or control of the domain, using one of the processes the Baseline Requirements permit ^[3]. The validation level decides what else is checked; DV, OV and EV certificates compares them.
Issuance. The CA authenticates the requester and verifies the request's signature. It then builds an X.509 certificate from your name and public key, its own issuer name, and its choice of serial number, validity period and signature algorithm ^[2].
Installation. In TLS 1.3 the sender's certificate comes first in the list, and each following certificate should directly certify the one before it ^[7]. Certificate chain: intermediate certificates and the chain of trust explains the order.

How to tell whether your certificate is CA-signed

A name in the issuer field is only a claim. The test is whether a chain of signatures leads from your certificate to a root you trust. Four OpenSSL 3.0 commands do it, with server.pem as your certificate:

openssl x509 -in server.pem -noout -issuer -subject
openssl x509 -in server.pem -noout -ext authorityKeyIdentifier
openssl x509 -in issuer.pem -noout -ext subjectKeyIdentifier
openssl verify -CAfile roots.pem -untrusted intermediates.pem server.pem

The first command prints the issuer and the subject ^[5]. The issuer line says who claims to have signed it.
The second and third print the authority key identifier of your certificate and the subject key identifier of the candidate issuer certificate ^[5]. Matching values tell you which certificate to test in the next step. They are a pointer, not proof.
The fourth builds the chain. openssl verify verifies certificate chains; -CAfile loads the trusted certificates from a file, and -untrusted supplies intermediates for chain building ^[4]. Put the roots you want to trust in roots.pem.

Reading the result

How to tell whether your certificate is CA-signed
What you see	What it means	What to do
`openssl verify` accepts `server.pem`	A chain of signatures leads from your certificate to a root in `roots.pem`. Other clients, with other roots, can decide differently ^[1]	Check which roots are in the file; root certificates and trust stores explains them
`unable to get local issuer certificate`	The issuer certificate could not be found, which happens when the issuer of an untrusted certificate is missing ^[6]	Add the intermediate with `-untrusted`, or the right root to `-CAfile`; see intermediate certificate authority

More commands for inspecting a certificate are on the OpenSSL commands page.

When you need a CA-signed certificate

When you need a CA-signed certificate
Who has to trust it	What fits	Why
Visitors' browsers you do not control	A certificate signed by a CA whose root those clients trust	Each client validates against its own trust anchors ^[1]
Devices and services you manage	A CA-signed certificate from a CA you run, with its root installed on those devices	The trust comes from the anchor you supply ^[1]
A throwaway local test	A self-signed certificate	Nobody outside your machine has to trust it

If you want a publicly trusted certificate without paying, see free public certificate authorities.

FAQ

What is a CA-signed certificate?

A CA-signed certificate is one whose signature was made by a certificate authority. The signature fields and the issuer field record who signed it. Whether a client trusts it depends on the trust anchor it holds.

How does a certificate authority sign a certificate?

The certificate authority authenticates the requester, verifies the signature on the certificate signing request, and builds an X.509 certificate from the name, public key, its own issuer name, and its choice of serial number, validity period and signature algorithm. The signature on the certificate comes from the CA, and the issuer field names it.

How do I get a certificate signed by a CA?

To get a CA-signed certificate, send a certificate signing request to the certificate authority, pass its domain validation, and install the issued certificate with its intermediate certificate. The four steps above give the order.

Is every CA-signed certificate trusted by browsers?

No. Path validation ends at a trust anchor the client holds, and a client without that root certificate cannot validate the certificate against it. A certificate from a certificate authority you run yourself is CA-signed all the same, with that CA as the issuer.

Sources

RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: sections 4.1.1.1 to 4.1.1.3, 4.1.2.4, 4.2.1.1, 4.2.1.2 and 6.
RFC 2986, PKCS #10: Certification Request Syntax Specification: abstract and section 1.
CA/Browser Forum, Baseline Requirements, section 3.2.2.4.
OpenSSL 3.0 manual, openssl-verify and openssl-verification-options: the -CAfile and -untrusted options.
OpenSSL 3.0 manual, openssl-x509: the -issuer, -subject, -noout and -ext options.
OpenSSL 3.0 manual, X509_STORE_CTX_get_error, docs.openssl.org/3.0/man3/X509_STORE_CTX_get_error/.
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: section 4.4.2.