Bridge SSL
What is a digital certificate? Kinds, purpose and trust
A digital certificate is a certificate in the form of digital data with a digital signature appended, computed over that data [1]. The kind behind SSL and TLS is the public-key certificate: it binds an identifier, such as a domain name or an email address, to a public key, and the issuer's signature attests that the key belongs to that identifier [1]. A website's SSL certificate, an email certificate and a code-signing certificate are all digital certificates; the purpose written into each one decides where it is accepted. It is part of the SSL and TLS glossary.
- Also called
- public-key certificate, when it binds a name to a public key [1]
- Binds
- an identifier, such as a domain name or an email address, to a public key [1]
- Signed by
- its issuer, a certificate authority, or the subject itself in a self-signed certificate [1]
- Purpose set by
- the Extended Key Usage extension: when present, the certificate may be used only for a purpose it lists [2]
Digital certificate, public-key certificate, X.509: which name means what
Digital certificate is the widest of these names. RFC 4949, the internet security glossary, files two kinds under it: public-key certificates and attribute certificates [1].
| Name | What it names | Covered on this site |
|---|---|---|
| Digital certificate | any certificate kept as digital data with an appended signature [1] | here |
| Public-key certificate | a digital certificate that binds an identifier to a public key [1] | here |
| Attribute certificate | a digital certificate that binds descriptive data other than a public key to a subject name or to another certificate [1] | outside the scope of this site |
| X.509 certificate | the format of public-key certificates that RFC 5280 profiles for the internet [2] | the X.509 entry in this glossary |
| SSL/TLS certificate | a public-key certificate for authenticating a server; a publicly trusted one must carry the server authentication purpose [3] | the SSL certificate section |
Every SSL certificate is a digital certificate. The reverse does not hold: an email or code-signing certificate is a digital certificate that fails a check for a TLS server, as the test further down shows.
Validation levels, DV, OV and EV, are a different axis: they describe what the authority checked, not what the certificate is for. For website certificates they are compared under types of SSL certificate.
How a digital certificate works
A digital certificate lets anyone check that a public key belongs to a name without asking the key's owner.
The subject generates a key pair and keeps the private key.
It sends the public key and the identifier to an issuer, such as a certificate authority, which checks the identifier.
The issuer signs the data with its own private key. Because that digital signature cannot be forged, the certificate can be published anywhere without protecting its integrity [1].
A program that relies on the certificate checks the issuer's signature, then the issuer's own certificate, and so on up to an issuer it already trusts. RFC 5280 calls that starting point the trust anchor: path validation verifies the binding between the name and the public key based on the trust anchor's public key [2].
Two mechanisms narrow or watch that trust. An app can accept only a known certificate or public key for its server, which is pinning a certificate. And transparency logs for issued certificates record TLS certificates as they are issued or observed, so anyone can audit what certificate authorities issue and notice suspect certificates [6].
Who signs a digital certificate
The signer decides who will trust the certificate.
| Signer | Who trusts it | Fits |
|---|---|---|
| Public certificate authority | browsers and operating systems out of the box | public websites |
| Private certificate authority | only devices where its root was installed | internal services, devices, client certificates |
| The subject itself (self-signed) | no browser | development and internal use |
A self-signed certificate is one where the public key it binds and the private key that signed it belong to the same pair [1]. Public and private authorities are compared under certificate authority, and self-signed certificates have their own page in the certificates section.
Kinds of digital certificate by purpose
What a digital certificate may be used for is written in its Extended Key Usage extension. When that extension is present, the certificate must be used only for one of the purposes it lists, and an application may require a particular purpose before it accepts the certificate [2]. Any organization with a need may define a purpose of its own [2]. The CA/Browser Forum's Baseline Requirements include these six for website certificates [3]:
| Purpose, as OpenSSL prints it | OID | In a publicly trusted TLS certificate [3] |
|---|---|---|
| TLS Web Server Authentication | 1.3.6.1.5.5.7.3.1 | must be present |
| TLS Web Client Authentication | 1.3.6.1.5.5.7.3.2 | may be present |
| Code Signing | 1.3.6.1.5.5.7.3.3 | must not be present |
| E-mail Protection | 1.3.6.1.5.5.7.3.4 | must not be present |
| Time Stamping | 1.3.6.1.5.5.7.3.8 | must not be present |
| OCSP Signing | 1.3.6.1.5.5.7.3.9 | must not be present |
So a publicly trusted website certificate cannot double as an email or code-signing certificate. The Baseline Requirements address only certificates for authenticating servers reachable through the internet [3]; email and code-signing certificates are not covered by them.
One authority, three certificates: a test
A test certificate authority made with OpenSSL 3.0.13 signed three certificates, each with its own P-256 key. They differ in name and in purpose: www.example.com with TLS Web Server Authentication, Example Test Code Signer with Code Signing, alice@example.com with E-mail Protection. Each was then verified against the same authority for two uses. The -purpose option names the intended use of the certificate being checked, such as sslserver for TLS servers [7].
| Certificate | -purpose sslserver | -purpose smimesign |
|---|---|---|
www.example.com, TLS Web Server Authentication | OK | error 26: unsuitable certificate purpose |
Example Test Code Signer, Code Signing | error 26 | error 26 |
alice@example.com, E-mail Protection | error 26 | OK |
$ openssl verify -CAfile ca.pem -purpose sslserver email.pem
CN = alice@example.com
error 26 at 0 depth lookup: unsuitable certificate purpose
error email.pem: verification failedAll three chain to the same authority, and every refusal names the purpose, not the signature or the name. The code-signing certificate failed both checks because neither use is in it; the predefined purposes of OpenSSL 3.0 do not include code signing [7].
Digital certificate vs digital signature
A digital signature is computed over a document with the signer's private key. A digital certificate tells whoever checks the signature which public key verifies it and whose key that is. The certificate carries a signature of its own, made by its issuer [1], which is why the two terms get mixed up.
In signed email the two travel together. S/MIME builds its messages on the Cryptographic Message Syntax, CMS [5], and CMS signed data has a field for certificates, intended to be enough to build a path from a root to every signer [4]. In the test, the email certificate signed a one-line file, and the signature file carried the certificate:
$ openssl cms -sign -in doc.txt -signer email.pem -inkey email.key -binary -outform DER -out doc.p7s
$ openssl pkcs7 -inform DER -in doc.p7s -print_certs -noout
subject=CN = alice@example.com
issuer=CN = Example Test CA
$ openssl cms -verify -inform DER -in doc.p7s -content doc.txt -binary -CAfile ca.pem -out /dev/null
CMS Verification successfulTwo changes to the signed file
Each change breaks verification for its own reason.
| Change | Result | What it shows |
|---|---|---|
| file edited from "Pay 100" to "Pay 900", signature kept | CMS Verification failure, content verify error | the signature covers the document |
| same file signed with the website certificate | CMS Verification failure, unsuitable certificate purpose | the certificate decides whether its key may sign email; cms -verify checks the S/MIME signing purpose by default [7] |
Digital certificates on Bridge CDN
Bridge SSL is the certificate layer of Bridge CDN: TLS certificates are issued and renewed automatically where your site is served. It works only for hostnames Bridge CDN serves. TLS is terminated at the edge, so there is no certificate file on your machine, and Bridge SSL has no certificate upload.
FAQ
Is a digital certificate the same as an SSL certificate?
An SSL certificate is one kind of digital certificate: a public-key certificate whose purpose is authenticating a server. Email, code-signing and client certificates are digital certificates too, and a publicly trusted SSL certificate must not carry the email or code-signing purpose. [3]
What is the difference between a digital certificate and a digital signature?
A signature is computed over data with the signer's private key. A certificate binds the signer's public key to a name, so anyone can tell whose signature it is; the certificate itself is signed by its issuer. [1]
Who issues digital certificates?
A certificate authority, public or private. A self-signed certificate is issued by its own subject, with the same key pair on both sides. [1]
Can a website certificate sign email?
Not a publicly trusted one: it must not carry the email protection purpose. In the test above, a signature made with the website certificate failed verification with "unsuitable certificate purpose". [3]
Sources
RFC 4949, Internet Security Glossary, Version 2: "digital certificate", "public-key certificate", "attribute certificate", "self-signed certificate".
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile: §4.2.1.12, §6.1.
CA/Browser Forum Baseline Requirements for TLS server certificates, version 2.3.1: §1.1, §7.1.2.7.10.
RFC 5652, Cryptographic Message Syntax (CMS): §5.1.
RFC 8551, S/MIME Version 4.0 Message Specification: §1.
RFC 6962, Certificate Transparency: Abstract.
OpenSSL 3.0 manual: openssl-verification-options, option
-purpose; openssl-cms, option-verify.