What is a Certificate?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I understand public key encryption, but I do not understand the
terminology surrounding security certificates.

For starters, what exactly is a certificate? On the Microsoft website,
I've read that it is a private key / public key pair. Verisign has told
me, however, that a certificate is a public key signed with a
certification authority's private key. Which is it?


Re: What is a Certificate?

it is basically both...
a certificate contains:

1. a public key is a very large number that people encript the messages
   that they send to you with it, and you with your public, which is given to
   are the only person who can encript those messages.
   (it is what private key/public pair is)

2. and some other stuff...
   for example some like SSL contain digital signature

it is created by certificate authority (CA), all nodes are pre-configured
by the public key of CA so other people can check to see if it is a real
certificate (it goes back to your second deffinition).

Hope it helps,


Quoted text here. Click to load it

            -Mina Doroudi (dormina@cc.gatech.edu)

Re: What is a Certificate?

Quoted text here. Click to load it

basically there is technology with asymmetric encryption (one key
encrypts, another key decrypt ... they form a key pair).

public key encryption involves a business process for doing things
like digital signature authentication. the businees process designates
one of the keys from the key pair to be a private key which will be
kept confidential and never divulged or exposed. The business process
designates the other key as public and allows it to be made widely

for authentication purposes, public keys can be registered
in place for pin/passwords &/or other shared-secrets

a person then can use the private key to encode a hash of some data
.... creating a digital signature. the digital signature can be
transmitted and verified using the registered public key. From
3-factor authentication paradigm

* something you have
* something you know
* something you are

.... the verification of a digital signature with a public key implies
"something you have" authentication ... i.e. the originator has
exclusive access to the private key producing the digital qsignature.
The advantage of public key vis-a-vis a shared-secret ... is the
public key can be used for verifying a digital signature ... but can't
be used for impersonation by creating a digital signature (while
anybody with access to a registerd shared-secret can not only used the
shared-secret for verification but also for impersonation).

digital certificates were originally targeted at the offline email
paradigm from the early 80s ... where somebody called the local
(electronic) postoffice, exchanged email and hung up. The scenario was
if email was received from somebody with no prior contact ... how was
the receiver going to authentication a complete stranger ... never
having contact with the person before.

In the PGP secure email model ... you register the public keys of the
parties that you are acquanted with. In the offline stranger scenario
.... you have no method of validating whether any specific public key
belongs to a specific person. So the idea was that in your trusted
public key repository ... in addition to directly registering public
keys of entities you directly communicated with ... you would also
register public keys of something called "certification authorities"
(or CAs). CAs would create things called digital certificates where
they bind some information about an entity to their public key ...
and the digital certificates are digitally signed by the certification

This is basically the "letters of credit" model from the sailing ship
days. The recipient gets a communication that is digitally signed and
has an appended digital certificate. The recipient verifies the CA's
digital signature (on the digital certificate) using the CA's public
key stored in the recipient's trusted public key repository. Having
validated the CA's digital signature, they can now trust the contents
of the digital certificate ... from which they pull the originator's
public key ... to validate the digital signature on the actual
message. This provides for indirect authentication when a total
stranger is involved and the recipient has no recourse to online,
electronic, and/or other forms of timely communication to validate
communication from an unknown stranger. This is compared to the PGP
trust model ... where individuals load their trusted public key
repository with the actual public keys of individuals they communicate
with ... as opposed to having it loaded with public keys of
certification authorities (since the actual public keys are directly
available ... there is no need for certification authorities and/or
digital certificates, certified by certification authorities).

An example is the SSL domain name digital certificate scenario. The
issue were various perceived integrity issues with the domain name
infrastructure and whether a browser client could actually trust that
the URL they had typed into the browser ... corresponded to the
webserver they were talking to.

The browsers have a preloaded trusted public key store.of numerous
recognized certification authorities. Servers contact one of these
certification authorites to get a SSL domain name digital certificate
containing their domain name and their public key (digitally signed by
the certification authority). The browser contacts the server in a SSL
session. The server returns a digitally signed message and their SSL
domain name certificate. The browser validates the CA's digital
signature on the returned digital certificate (using the CA's public
key that has been preloaded into their browser) ... and then uses the
public key from the digital certificate to validate the digitally
signed message. If that works ... they then can check whether the
domain name (in the supplied digital certificate) matches the domain
name that they typed in as part of the URL (aka prooves that the
server you think you are talking to is actually the server you are
talking to)..

So an issue for the SSL domain name certification authorities is that
an applicant supplies some amount of identification information.  The
certification authority then must cross-check that identification
information on file with the authoritative agency responsible for
domain name ownership. This identification matching process is an
error prone, time-consuming, and expensive activity. It also turns out
that the authoritative agency responsible for domain name ownership is
the domain name infrastructure ... which has the integrity concerns
giving rise to the need for SSL domain name certificates.

So somewhat a proposal backed by the SSL domain name certification
authority industry ... is that applicants for domain names should also
provide a public key as part of domain name registration. Use of this
"on-file" public key could help with a number of the existing domain
name infrastructure integrity issues. Also the certificaton authority
industry could require that SSL domain name certificate applications
be digitally signed. Then the certification authority can replace an
error-prone, expensive and time-consuming identification matching
process with a much simpler and more reliable authenticaton process
(they simply retrieve the on-file public key for that domain from the
domain name infrastructure and validate the digital signature on the
SSL domain name certificate application ... note that this is a
certificateless operation being able to do real-time online retrieval
of public keys instead of getting them from a stale, static digital

All well and good ... however it represents soemthing of a catch-22
for the certificaton authority industry. By improving the integrity of
the domain name infrastructure ... they improve the integrity of their
certifying that the entity requesting the domain name certificate is
the actual owner of the domain name. However, the questions about the
integrity of the domain name infrastructure is a major factor for
needing SSL domain name digital certificates.  Improving the integrity
of the domain name infrastructure reduces the requirement for SSL
domain name digital certificates.

The other issue is if there are now public keys on-file for real-time,
online retrieval ... for access by the certification authorities in
certificateless digital signature authentication ... then it would
also be possible for other entities to also do real-time online
retrieval of such public keys. One scenario would be to modify the the
SSL protocol for certificateless operation by retrieving the
appropriate public key directly from the domain name infrastructure.

misc. past postings about SSL domain name certificates

misc. past postings about certificateless public key authentication

recent posting on other aspects of certificaton authorities and
digital certificate business model
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates

Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: What is a Certificate?

Quoted text here. Click to load it

I've never understood why they chose this term: pulic
*key* encryption. It't the wrong term. The proper
terms for a "pair" should be:

public lock
private key

Doesn't that work better?

Why is the public part, that's used to lock up
the data from prying eyes -- why is that called
the pulic *key* when it *locks* the data. Didn't
they know that the key is for unlocking of the

Enquiring minds wnat to know!!!

Re: What is a Certificate?

Quoted text here. Click to load it
You can encrypt data with either your public or private key.
You can decrypt data encrypted with your public key with your private key.
You can decrypt data encrypted with your private key with your public key.

The public/private distinction is just that to use the system effectively you
need to keep one of the keys private whereas you want to give away (make
public) the other key.

If you encrypt data with your private key then someone who decrypts it with your
public key can be certain that it was encrypted using your private key. Thus
providing a level of authentication as to who the message came from.

If you encrypt data with someone else's public key then the only person who
can decrypt it must have the corresponding private key.

David Webb
Security team leader
Middlesex University

Quoted text here. Click to load it

Re: What is a Certificate?

Thank you for the generous replies. If I understand the responses
correctly, a certificate is a public key which may or may not be signed
by a certification authority's private key. Is that correct?


Re: What is a Certificate?

TC napisał(a):
Quoted text here. Click to load it

To be a _certificate_ it must be signed. X.509 certificate contains of
three parts:

TBSCertificate (TBS = To Be Signed)
Specification of signature algorithm
Signature of TBSCertificate

TBSCertificate contains a public key, distinguished names of subject and
issuer, timeframe of validity, serial number and extensions, which may
specify allowed uses of this certyficate, whether it is a CA, how long
certification chain may be, identifiers of certification policies,
additional names (e-mail, domain name etc.) and many other things.


Re: What is a Certificate?


Microsoft has a program called selfsign.exe. When I run it, it creates
a certificate. Is it creating two key pairs and signing the public key
of one with the private key of the other? Or is it lying (i.e. claiming
to create a certificate, but really just creating an unsigned public


Re: What is a Certificate?

Quoted text here. Click to load it

It creates a self-signed certificate - a certificate that will work
just like any other, but cannot be used to proof anything. The
signature on the certificate was generated by its own key, that's like
saying "I'm me because I say I'm me".

The important part about real certificates is that they are signed by a
Certificate Authority - somebody who is known to check the authencity
of keys before signing them. Obviously, this cannot work with
self-signatures :-)

Juergen Nieveler
"Keep good relations with the Grecians."
George W. Bush --Quoted in the Economist, June 12, 1999

Re: What is a Certificate?

Quoted text here. Click to load it

note however, to get the CA's public key for validating a signature on
a CA-issued digital certificate ... you get that out of a CA
self-signed digital certificate ... which says I'm the CA because I
say I'm the CA.

so who checks the authenticity of the CA's keys?

basically there you have a trusted repository of public keys. In the
case of PGP ... you validated the public keys that you are
communicating with before classifying them as trusted.

CA public keys are also typically in a trusted repository of public
keys (frequently built inside an application like a browser) ... and
somebody hopefully has validated the authenticity of the CA public
keys before (pre)loading them into the client's trusted repository of
public keys>.

At some point all operations have to resort to some repository of
trusted public keys ... whether it is a certificateless environment
(where you typically are doing the validation of the authenticity of
the public keys and related information ... like PGP operation)
..... or a certificate-based environment ...  where there is one or
more level of indirection between the validation of the digital
signature on the original communication and the final validation of a
CA's digital signature on a communication (in the format of a digital
certificate) ... using a CA's public key that has been (pre)loaded in
an application trusted public key repository.

misc certificateless

Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: What is a Certificate?


Are you implying there are two classes of certificates, "real" and
"self-signed"? Real certificates must be signed by a certification
authority, but self-signed certificates need not?


Re: What is a Certificate?

TC wrote:
Quoted text here. Click to load it

Re: What is a Certificate?

Quoted text here. Click to load it

Self-signed certificates are, as the name says, signed by yourself.
Therefore they don't have any implicit trust assigned to them, whereas
a signature by a CA signifies that the CA trusts the certificate to be
authentic. CA root certificates usually are self-signed, of course
(Chicken-Egg...), in some cases they are however signed by other CAs

The main difference here is that the Root Certificates are usually
included in the web browser/mail client/OS, so that any new certificate
can immediately be checked, whereas a self-signed certificate will
always cause the machine to ask the user wether to trust this

Juergen Nieveler
Ever get the feeling your guardian angel is laughing?

Re: What is a Certificate?

TC napisał(a):
Quoted text here. Click to load it

Self-signed certificates are also signed by CA, but the difference is
that this is the same CA which issued them (this is what "self-signed"
means). Certificates form a trust chain, and a self-signed certificate
is at the end of this chain. You trust it because it is well known (and
because Microsoft has built this certificate into Internet Explorer).
Possibly trust chains of millions of certificates finish at this one
certificate. You can trust names and attributes written in that
certificates because you trust this one certificate.


Re: What is a Certificate?


Thank you. I believe I understand. Please tell me if I've got this
right: All certificates are signed by a certification authority. If a
certificate is signed by a certification authority which does not
itself have a certificate, then it is a self-signed certificate.

When I use Microsoft's "selfsign.exe", I am using a certification
authority which does not have a certificate. I am using the CA's
private key to sign a newly generated public key, and therefore
creating a new self-signed certificate.

This makes sense to me.

I am confused about one part of your explanation, however: You suggest
that self-signed certificates are signed by the certification authority
which issued them. Aren't all certificates signed by the CA which
issued them, and only by the CA which issued them?


Re: What is a Certificate?

Quoted text here. Click to load it

the format of certificate is a technical standard/specification that
includes things like public keys and a digital signature.

who signs the certificate is a business specification.

the business specification of the verification of digital signatures
typically involves the relying party (entity relying on the digital
signature verification) having some form of trusted repository of
public keys. These trusted repositories of public keys may be used to
implement direct verification ... like in PGP signed email. Other
public keys in the relying party's trusted public keys may belong to
parties that issue digitally signed digital certificates ...  that
attest to the trust involving other entities.

In general, all "root" CA digital certificates are self-signed. In
this situation it is up to the relying party (or somebody that the
relying party trusts) to load the public keys for "root" certification
authorities into some trusted public key repository.

selfsign needs to have a pair of asymmetric cryptography keys.  The
key of the pair that is designated "public" is placed in the
certificate and the key (of the pair) that is designated "private" is
used to digitally sign the certificate. This can be used to become a
new "root" certification authority.

To the extent that such a new "root" certification authority has any
business accpetance ... is the extent that the associated public key
can be loaded into relying parties trusted public key repositories.

In general, all the common PKI infrastructures ... have at their root
.... one (or more) self-signed digital certificate.

The PKI business issue is if all the digital certificates are
self-signed and require somebody to make a specific decision about
each associated public key for loading into a trusted public key
repository ... then you can do away with the certificates all together
and just go about directly loading the trusted public keys into the

The whole point about PKIs and digital certificates ... is that for
some entity that you trust (have thier public key loading into your
trusted public key repository) ... will you "trust" their judgement as
to other public keys ... aka CAs have made trust judgements (and/or
certified other public keys) and placed that trust judgement in
something called a digital certificate and have digitally signed that
digital certificate.

The business purpose of the stale, static digital certificates are a
substitute for

1) the relying party having their own trusted judgment about the
associated public key (aka having the specific public key already
loaded into their own trusted public key repository)(

2) the relying party not being able to contact the certification
authority in a timely manner to directly verify information

there was the scenario in the mid-90s about x.509 identity
certificates overloaded with privacy information and found
institutions retrenching to relying-party-only certificates
(i.e. where the relying party registered the public key and also
issued a certificate).  The relying-party-only certificates usually
only contained some identifier (like an account number) which referred
to all the information that the relying-party knew about the
key-owner. Rather than having the information in a digital certificate
where it might be transmitted all over the world and unnecessarily
exposted the information to all sorts of prying eyes ... the
information was kept securely at the relying party. However, it was
trivial to show that such stale, static digital certificates were
redundant and superfluous ... since the relying-party already had all
the information on record (including the registered public key) and
therefor there existed no information in the stale, static digital
certificates that the relying party didn't already have. It was futhre
aggrevated in the case of payment transactions for financial relying
parties. Not only were the stale, static digital certificates
redundant and superfluous, but they were tended to also be one hundred
times larger than the typical payment transaction size (resulting in
enormous payload bloat).

there is the scenario involving SSL server domain name certificates,
which were motivated in large part by integrity concerns involving the
domain name infrastrucutre. somebody would apply for a SSL server
domain name certificate and supply a lot of identification
information. The certification authority would then contact the
authoritative agency for domain name ownership to validate whether the
applicant for the digital certificate was the actual owner of the
domain name. This raised two issues:

1) the authoritative agency for domain name ownership is the domain
name infrastructure ... which has integrity concerns ... which give
rise to the requirement for SSL domain name certificates

2) trying to match an applicants identification information with the
domain name identification information on file with the domain name
infrastructure was a time-consuming, costly, and error prone process.

Somewhat to address both these issues (domain name infrastructure
integrity and vaguries of identity matching) a proposal (somewhat from
the CA industry) is that a domain name owner register a public key
when they obtain a domain name. Future interaction between the domain
name owner and the domain name infrastructure then are digitally
signed and the domain name infrastructure can verify the digital
signature with the on-file public key ... note: no certificate.
Also, CAs can require that SSL domain name certificates applications
be digitally signed. The CAs then can do a real-time retrieval of the
on-file public key and verify the digital signature on the application
(turning a time-consuming, costly, and error prone identification
process into a simple and reliable authentication process). note:
no certificate

The catch22 for the CA industry is

1) improving the integrity of the domain name infrastructure then
lessens some of the original justification for SSL domain name

2) if the CA industry can use certificateless public keys on file from
the domain name infrastructure (for validating digital signatures from
domain name owners) ... then it is also possible that others could
also do real-time retrieval of certificatelss on-file public keys (aka
do a modified version of TLS/SSL that uses certificateless public keys
retrieved directly from the domain name infrastructure).

Part of the issue is that the whole CA trust chain/hierarchy is a
business definition. As a business definition ... it can't be limited
to just those business processes that involve digital certificates and
public keys ... but has to extend all the way thru the business
processes that CAs use for certification as well as the authoritative
agencies that they rely on for the original information.

A frequent comment is no (trust) chain is stronger than its weakest
link. If the CA industry is looking at improving their trust
hierarch/chain by using certificateless, on-file public keys kept by
the domain name infrastructure ... then why can't others directly also
use such certificateless, on-file public keys (and eliminate all the
extraneous business processes).

Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: What is a Certificate?

Anne & Lynn,

Thanks. It seems to me that you are describing a system different from
the one described by Jacost. In the system you describe, a self-signed
certificate is a public key signed with its own private key. In the
system described by Jacost, a self-signed certificate is a public key
signed with the private key of a certification authority which has no


Re: What is a Certificate?

Quoted text here. Click to load it

the definition of a self-signed certificate is a certificate signed by
the private key that corresponds to the public key contained in the
certificate. an indication of a self-signed certificate ... is that
the public key contained in the certificate itself is used for
validating the certificate's digital signature ... as opposed to
continue searching the trust hierarchy looking for a "higher"
certificate with a public key for validating the current digital
certificate's digital signature.

a CA can have a self-signed "root" certificate ... and that CA can use
the corresponding ("root") private key to sign other certificates
where the same business organization is in possession of the
corresponding private keys. this would be a more general business
reference to a CA signing certificates for itself. In such a business
sense ... such CA certificates are self-signed, in the sense that they
are signed by the same business operation. However, this isn't the
common definition of a "self-signed certificate".

note in my RFC index

clicking on the ".txt=nnn" field in each RFC summary will retrieve
the actual rfc.

from rfc3280
http://www.garlic.com/~lynn/rfcidx10.htm#3280  Authority Key Identifier

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate.  This extension is used where an issuer has
   multiple signing keys (either due to multiple concurrent key pairs or
   due to changeover).  The identification MAY be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

   The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate certification path construction.  There is one exception;
   where a CA distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier MAY be omitted.  The
   signature on a *self-signed certificate is generated with the private
   key associated with the certificate's subject public key*.  (This
   proves that the issuer possesses both the public and private keys.)
   In this case, the subject and authority key identifiers would be
   identical, but only the subject key identifier is needed for
   certification path building.

from rfc3125

3.6.1  Certificate Requirements

   The certificateTrustTrees identifies a set of self signed
   certificates for the trust points used to start (or end) certificate
   path processing and the initial conditions for certificate path
   validation as defined RFC 2459 [7] section 4.  This ASN1 structure is
   used to define policy for validating the signing certificate, the
   TSA's certificate and attribute certificates.

from rfc3261:

26.4.2 S/MIME

   The largest outstanding defect with the S/MIME mechanism is the lack
   of a prevalent public key infrastructure for end users.  If self-
   signed certificates (or certificates that cannot be verified by one
   of the participants in a dialog) are used, the SIP-based key exchange
   mechanism described in Section 23.2 is susceptible to a man-in-the-
   middle attack with which an attacker can potentially inspect and
   modify S/MIME bodies.  The attacker needs to intercept the first
   exchange of keys between the two parties in a dialog, remove the
   existing CMS-detached signatures from the request and response, and
   insert a different CMS-detached signature containing a certificate
   supplied by the attacker (but which seems to be a certificate for the
   proper address-of-record).  Each party will think they have exchanged
   keys with the other, when in fact each has the public key of the

from rfc3379, section 5.

   The DPD server response includes zero, one, or several certification
   paths.  Each path consists of a sequence of certificates, starting
   with the certificate to be validated and ending with a trust anchor.
   If the trust anchor is a self-signed certificate, that self-signed
   certificate MUST NOT be included.  In addition, if requested, the
   revocation information associated with each certificate in the path
   MUST also be returned.

from rfc3820, section 2.5

   In order for a party to have rights of it's own it requires a unique
   identity.  Possible options for obtaining an unique identity are:

   1) Obtain an identity from a traditional Certification Authority

   2) Obtain a new identity independently - for example by using the
      generated public key and a self-signed certificate.

   3) Derive the new identity from an existing identity.

from rfc3830, section 3.

   Public-key cryptography can be used to create a scalable system.  A
   disadvantage with this approach is that it is more resource consuming
   than the pre-shared key approach.  Another disadvantage is that in
   most cases, a PKI (Public Key Infrastructure) is needed to handle the
   distribution of public keys.  Of course, it is possible to use public
   keys as pre-shared keys (e.g., by using self-signed certificates).
   It should also be noted that, as mentioned above, this method may be
   used to establish a "cached" symmetric key that later can be used to
   establish subsequent TGKs by using the pre-shared key method (hence,
   the subsequent request can be executed more efficiently).

Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: What is a Certificate?

http://www.garlic.com/~lynn/2005g.html#10 What is a Certificate?

Quoted text here. Click to load it

note that the man-in-the-middle (MITM) attack applies to effectively
keys that have to be loaded in the relying party's trusted public key
repository ...  including those keys belonging to certification

in effect, some additional &/or out-of-band method is required for
further validating the association between some public key and some
other characteristic (nominally represented by information contained
in a signed digital certificate).

one method used in the PGP case is to have a key-id (basically a short
encoded representation of the full public key) and the key-id is
verbally confirmed in telephone, face-to-face and/or other independent
(trusted) communication.

frequently in many of the PKI/CA related deployments ... the
application vendor prebuilds a trusted public key repository into the
application itself ... and the relying party then places some level of
trust in the application vendor.

one of the issues that has been raised in the case of various vendor
provided trusted public key repositories ... is some of them involve
CA keys that have become quite stale and/or the CA companies have even
gone out of business. In these situations there may be no apparent
trusted constodian of the corresponding private key. Furthermore, the
PKI/CA deployments that have been made ... make no differentiation
between the trust levels of the CA public keys that have been
preloaded into a vendor provided trusted public key repository ... aka
all certificates are accepted equally regardless of which CA public
key (from the relying party's trusted public key repository) has been
used to validate a digital certificate's digital signature
(i.e. regardless of which CA issued the certificate).

the original design point for PKI, certificates, ca etc ... was the
offline email scenario from the early 80s ... where a relying party
dialed up their local (electronic) post office, exchanged email, and
then hungup. The issue was for received email from senders that the
relying party had never before interacted with (and/or never before
communicated with) ... how were they to authenticated the email
origin. Since there never before had been any communication ... the
relying/receiving party likely wasn't to have any information on hand
about the send. Also, since the relying/receiving party had hungup
(and was now offline), they had no timely, online recourse to
information from any authoritative agency. Digital certificates filled
the gap as a substitute for the real information.

However, in an online world, it is frequently trivially possible to
show that stale, static digital certificates are redundant and

Anne & Lynn Wheeler | http://www.garlic.com/~lynn /

Re: What is a Certificate?

TC napisał(a):
Quoted text here. Click to load it

Ann & Lynn explained in more detail all that my limited fluency in
english language and PKI knowledge made impossible for me to do. But
this is what I tried to say -- that self-signed certificate is signed by
its own private key. Typically self-signed certificate is the last (or,
according to RFC 3280, the first) CA certificate in a trust chain -- a
"root CA" certificate. So to keep it short:

Self-signed certificate is:
1. a certificate signed by its own private key;
2. (typically) a CA certificate originating the trust chain;
3. a certificate which you trust because you know it -- technically
because it is loaded (or built) in trusted certificate store.


Site Timeline