Introduction to Certificates (common)

1. Introduction
Sometimes you need to be sure in identity of the person you communicate with. This proposition holds
for individual meetings as well as for data exchange. If someone you don't know comes to you and says
that he is reliable bank agent and wants to offer you deal on beneficial terms, you will not take his
words on trust. You will require to show his credentials, furthermore you will try to ascertain as much
about this bank as possible and you will use your own trustworthy sources of information.

So why must you take on trust the things that somebody with whom you communicate via network
says? Digital certificates are used right in order to avoid such kind of situations. They allow to identify
persons or firms. Moreover, digital certificates permit transmitting encrypted data with certainty that it
can be read only by person to whom it is addressed.

Two encryption methods are used today: symmetric cryptography and public-key cryptography.
Symmetric cryptography means that one secret key is used for data encryption and then the same key is
used for decryption. Some problems arise in this case, such as secure key transfer, a lot of keys must be
stored at the safe place and to be easily accessible at any time for owner. Public-key cryptography
means that key pair is used: private key and public key. These two keys are related with mathematical
expression so that data encrypted with one key from the pair can be decrypted only with the second
one. There is no need for key transferring in this case. Moreover you will need to care about only one
key security.

But then the next problem appears. Suppose you get message signed with sender's private key. Can you
really trust this information? As it turns out, not entirely. Only one thing can be guaranteed in this
situation. You can only be sure that message and public key came from one place but you can not know
what this place is exactly. Let us assume that your friend Alice sent you her public key but Bob
substituted it with his one. Then Bob sends you message as if he were Alice. In that case you can not
find out that message was really written by Bob as you think his public key to be Alice's one. It is
necessary to have possibility to find out that sender is the one he gives himself out to be. How can you
do it if you can not get public key from its owner directly? Right in this case certificates relieve, as
their main purpose is to confirm public key belonging to its owner.

Certificate contains information about person or organization to which it belongs, public key,
information about certificate issuer, time limits when this certificate can be used and operations for
which it can be used. Private key is not a part of the certificate. Unlike certificate private key is not
public and it is an element you must store at the most secure place. Remember that one without other is
of no use.

There are several different certificate formats used. One of the most used is X.509. This type allows
using certificates for various purposes due to wide distribution and numerous extensions. Such
certificate can be used for encrypting, signing messages, signature verification, as addition or
replacement password system of authentication while resources access, furthermore such certificates
are used in the SSL protocol.

Each certificate contains some mandatory and some optional fields. To understand functions of some of
these fields you need to acquaint yourself with Certificate Authority concept and certificate issuing
technology.

2. Types of certificates and Certificate Authority functions

Certificates are made in two types in general: self-signed and issued by certificate authority. If we
compare digital certificate with usual identity card, then in case of self-signed you made identity card
yourself and in case with certificate authority you got it from competent authority. Most of systems
with rare exception distrust self-signed certificates. At the same time self-signed certificate can be
useful for creating internal certificate structure in some company. But it is special topic beyond the
limits of this article.

So what is certificate authority (CA) and what is it for? CA is organization which functions include
certificates issuing, accessibility providing, revocation in case of need. If you request a certificate CA
will require confirming your identity with some appropriate method. This method can depend on
required security level. For example, if you need certificate only for personal using it can be enough to
indicate your passport or another document number. But if purposes are more serious then stronger
measures will be taken. Sometimes you can be required to bring notarized paper document and to do it
yourself. These differences are quite explainable. If someone writes love-letter on your behalf the main
victim of this action will be you or probably person to whom such letter was addressed. But what will
happen if malefactor affixes your signature to the transfer of an immense sum of money? In this case
extent of damage can be sizeable not only for you but for you company as well.

After certificate issuing CA must provide easy access to them and at the same time it must guarantee
that certificates can not be changed or revoked by unauthorized person. Individual certificate
authorities get beyond managing the whole information flow as certificates gain more popularity and
widespread. So they delegate authority to lower levels CAs. That is when you get certificate it is signed
by a CA of the lowest level, it in turn has its own certificate issued by CA of higher level and
confirming its right to issue certificates. And so on up to the root CA. But who identifies this root CA
then? Right in that case self-singed certificates are used. It means that root CA issues certificate for
itself. If you use popular browser or mail client most likely it will contain list of some checked and
trustworthy certificates including ones for root CAs.

Next important function of CA is revocation capability in case of need. Certificate revocation necessity
can appear in case of suspicious that someone else has got access to the private key or it has been lost.
Moreover sometimes it can be useful to lock certificate for determined time interval, for example, if
certificate owner is in hospital or went on leave.

3. Certificate fields
Each certificate consists of certificate body, signature algorithm and CA signature itself. Certificate
body includes several obligatory fields and moreover there can be one or more additional fields
depending on certificate version.

Brief description of standard fields follows:

• Version (1, 2 or 3). Certificate of the first version can contain only obligatory fields without any
 extensions or additional information. Unique subject and object identifiers were added at the
second version. These fields enable reusing of the same names several times. But it is not
recommended to use these fields. Extensions were added at the third version. They allow to
concretize certificate area of application and some other parameters related to certificate owner,
or digital signature which the certificate must confirm. The number in this field is one less than
real certificate version as numeration begins from zero.
• Serial number - uniquely defines certificate issued by the certificate authority.
• Signature - the algorithm identifier for the algorithm used by the CA to sign the certificate.
• Issuer - identifies CA that issued certificate.
• Subject - information about certificate owner. If one subject needs several different certificates
signed by one CA, such certificate can have the same value of this field. Sometimes this field
can be empty (i.e. when key associated only with e-mail address). In that case subjectAltName
extension must be used.
• Validity - beginning and ending dates of certificate period of validity.
• Subject Public Key Info - - subject public key for the sake of if which the certificate was
created. Besides key itself this field contains algorithm identifier and parameters with which this
key must be used.
• Issuer Unique ID and Subject Unique ID. These fields uniquely identify the issuer and subject.
They are used when Issuer and Subject fields contain the same values, however the certificate is
not self-signed.
• Extensions - a sequence of one or more certificate extensions. Each extension can be critical or
not, standard or custom.
• Signature Algorithm - contains the identifier for the cryptographic algorithm used by the CA to
sign this certificate.
• Signature Value - CA signature to confirm certificate validity and authenticity.

4. Certificate Revocation List (CRL)

CRL is usually used for revoked certificates indication. This list contains certificates that are not valid
anymore by some reason however certificate period of validity has not finished yet. On this period
ending certificate is deleted from the CRL. CRL using is non-obligatory in general, if CA can process
revoked certificates in a different way. But as this way is used more often let's dwell on it.

Besides revoked certificates containing as stated above, each CRL must include next updating date.
CRLs are usually updated with some frequency, i.e. once a day, once an hour or once a week. Updating
rate depends on certificate authority but if updates are too rare then it will raise a possibility of
accepting the certificate that was revoked but has not been added to the CRL yet. And of course it
decreases security level.

When CRL is used the organization that issued and signed this list must be indicated, besides
certificates. So each CRL must contain issuer's signature and signature algorithm and moreover dates of
the current and next updates. These dates are necessary for users to find out actuality of the CRL they
are using. As well as certificates CRLs can have different extensions that allow flexible adapting of the
control system.

5. How do I get a certificate?

Before you can use a certificate for any purposes you need to get it. You can do it in one of several
ways: you can issue self-signed certificate yourself, you can get it in your company if it issues
certificates for its workers, or you can request it at the certificate authority. The choice of method
depends on your needs and purposes. If you are planning to use certificate only for personal needs it
can be quite enough to use self-signed certificate, especially if you have possibility to hand it over to
your friends and partners. But in this case you will need some knowledge of certificates issuing and
understanding of all certificate fields and extensions means. Otherwise you risk getting certificate that
can't be used for your purposes. Furthermore serious systems can deny authentication when self-signed
certificate is used.

Utilization of certificate issued by your company has number of advantages and disadvantages. As such
certificate will be most likely used for internal company needs, for example for resources access
limitation, it can have some non-standard extensions unsupported by other systems. Or its range of
application can be limited.

It should be mentioned the case when some companies require certificate issued by themselves for user
authentication. Banks or software developers can prefer such practice.

If you decide to use universally recognized certificate authority, actions you will have to do will depend
on authority rules and security level you need. At the most simple case (i.e. at www.thawte.com)
certificate confirming your e-mail address can be got absolutely free. You just have to pass simple
registration procedure during which you will need to enter name, country and depending on it some
identification code (passport or driving license number etc.) and of course e-mail address and
password. That's all. The only thing you will have to do over this is to get your certificate from the
same computer and with help of the same browser which you used for request sending. If you have a
desire you can set extensions yourself but it's strongly recommended to do it only if you know what
you are doing very well. On other systems using, for example Verisign, registration procedure can be
stricter and it takes more time. You can be required to bring notarized document for example.
Obviously such kind of service will not be free.

6. Certificate Storages
The most easy and common place for certificates storing is System Windows Storage. But it can occur
that this storage does not provide you with the necessary security level. Even when you set the highest
possible security level for you private key such protection can be broken if someone who really needs it
has access to your computer. Even if such person will do nothing with your own certificates he can
change other people's ones that can also cause inconvenience.

So the better decision is to store your certificates and private keys outside of your computer. You can
use Smart Card or USB Dongle for these purposes. This way has some advantages:

• All your certificates are stored at one place. You don't need to find necessary one over different
storages. Note that some program applications can use their own storages and when you put a
certificate to its storage it is still unavailable for other applications and system. When you use
USB Dongle or Smart Card you can access certificates at any time. If some application can not
use external storages you just have to export certificate from one storage and then import it to
another one.
• You are the only person who has access to certificates. You carry your Smart Card or USB
 Dongle with you like keys from home or car. You give it to no one. It is always protected by
password. Even if your Smart Card or USB Dongle is stolen the criminal will have to find out
the password before they can use it. It is good idea to use long and unusual passwords for such
devices.
• You need only one copy of each certificate. You do not need to install it on your home
computer, computer in the office, notebook or any other place. At the same time you have
access to it from any computer. It means that even if a criminal get access to your computer and
find out your private key password it will be of no use for him as there is no installed certificate.
But when you come to friend and have to sign some data you can do it easily without certificate
installation.

But there is nothing ideal in the world. So some features can be advantages in one situation and become
disadvantages in other:

• If you use Smart Card you won't be able to read information from it at any computer. You can
do it only if there is a Smart Card reader. So you can have some problems if you need to use
your certificate at the computer without such device. USB Dongle in this respect is better as it
could be used at any computer with USB port. But on the other hand if you keep in external
storage only certificates you use in the office it can be more secure to use Smart Card.
• If you used to store all kinds of data at the one place you can be confused as external storages
allow to store only digital certificates. Of course it is nice that you will keep only certificates
there and will not access this device for other information. But it could be good idea to store
your password manager at the same secure place as certificates.
• There is no possibility to export your private key from Smart Card. So if you by some reason
need to install certificate with private key to another storage you will need to copy it in a
different way.

7. Storing private keys

As stated above certificate itself without private key has not much use. If you only lose your private
key and can not access some secret information it will be only half of the trouble. But if your private
key will be known by some unauthorized person it can cause you a lot of trouble. So your private key
must be really private and secret. No one but you must have access to it. But at the same time you need
to have access to it at any moment.

There are several ways for private key restoring in case of its loss. You can entrust its storing to
authorized delegate. But this method can be called ideal in no way, as it's undesirable to give access to
your private key to anyone even to trusted person. You can divide key into several parts and allot these
parts to several trusted people so that it is possible to restore information only by bringing all parts
together and no one from them can restore your key himself. In this case all involved people must be
approachable at any moment. Or you will have to do number crunching to decrease number of people
needed for restoring. Another way is to put your private key into digital envelope and sign it with
trusted person's public key. In case of losing you can just ask this person to open the envelope with his
private key. It's easy to see that in all these methods trusted people must remain trusted and accessible.

The easiest and most comfortable way is to save your private key into the file, save this file on floppy
disk and to store this floppy disk at the secure place for example in bank safe. On private key loss you
will only need to use this floppy disk and import your key from it.

So you should care about private key reserve copy beforehand to have possibility to restore it in case of
loss. However all these actions will be absolutely useless if you did not just lose access to your private
key but someone unauthorized got such access. The only thing you can do in that case is to revoke your
certificate as soon as you got any suspicion that someone else can use it. After that you will have to
create new certificate and provide top-level security of the corresponding to it private key.

8. Uses of Certificates
Now let's see what profit you can get from certificates usage. When it is useful to sign or encrypt data.
What problems can you avoid using certificates?

Signature
Digital signature means that message is encrypted with sender's private key and then two variants of
the message (encrypted and non-encrypted) are sent to the recipient. Recipient decrypts encrypted
message with sender public key. If result is equal to the original message everything is all right and
sender is the one he personates. Furthermore digital signature allows avoiding desertion and confirming
message authorship.

It should be mentioned that when the whole message is used as digital signature transinformation
content redoubles that can be unwanted. Moreover public key cryptography takes much time. Therefore
usually not the whole message is encrypted but only its digest. Digest can be created from the initial
message and has small fixed length. Digest creation algorithm must meet several requirements. If one
symbol changes in initial message digest must vary considerably. It is practically impossible to find
message with predetermined digest. These demands are necessary to make touching up of signed
message impossible. When digest is used recipient has to take next steps: apply to the initial message
the same algorithm as sender did. Decrypt digest received with the message with sender public key.
Compare this two digests which must be equal. Obviously you will not do it manually, program which
you use to work with certificates will do it for you.

Upon supposition that Alice asks Bob to do her a service, for example to find some information she
needs, and promises some fee for it. Alice formulates her demands and sends them to Bob as e-mail
letter. Bob finds necessary information, sends it to Alice and waits for the promised fee: But Alice has
changed her mind in this time and she is not going to pay anything. She says that she does not know
what the matter is about, she did not write anything like this and Bob fabricated everything. In this case
there is no way for Bob to get his owing and maximum he can do is to prove that letter was sent from
Alice's mail address. But it is not known who really sent it.

After a time Alice needs some new information and she turns to Bob again. Bob knows to his own cost
that he should not trust Alice. So he requires Alice to sign her letter with digital signature. Alice needs
this information very much and she agrees to his demands. She promised Bob $1000 signed this
message and sent it to Bob. This price absolutely suited Bob and he did everything Alice asked him.
However guileful Alice tried to palter and erased one zero as though she promised only $100.
Dissatisfied Bob requires all his money and demonstrates signed letter he received. Alice asserts that
she has original and Bob changed her message. In this case it's enough for Bob to generate digests of
both messages (as we know they will be quite different) then there was nothing else to do for Alice but
to sign both digest with her private key. As signature will be the same as at the signature at the message
variant shown by Bob it's obvious who tells the truth.

Encryption
In case when it is more important to guarantee that transferred information will be accessible only for
recipient message encryption is used.

Asymmetric algorithms are much slower than symmetric ones. In order to speed up messages
encrypting and decrypting next method is used. Message is encrypted with symmetric algorithm using
some secret key. Then this secret key is encrypted with recipient's public key and attached to the
message. Recipient has to decrypt secret key first. There is no problem as he has according private key.
Then using secret key he decrypts the initial message.

Alice decided to use Bob's service again but she does not want someone else to find out what exactly
she needs. In this case Alice has to encrypt her message using Bob's public key which she can get from
Bob's certificate. After it she sends only encrypted variant. Bob receives message and decrypt it with
help of his private key. Thus only Bob can read the message as no one else must access his private key.

Sign and Encrypt

What can be done if we need to guarantee both: message privacy and its sender personality? Signing
and encrypting operations can be combined perfectly. Operations order can vary dependent on specific
situation. It means that you can sign message and then encrypt it together with signature. Or vice-versa
you can encrypt message first and then sign encrypted data. The second variant can be more preferably
when large amount of information comes in the form of encrypted messages as signature verification
does not require the whole message decoding and can be automated to a certain extent.

Secure File Storing

We reviewed certificates usage only for data transmission. Let's now have a look how certificates can
help in secure files storing. Imagine you have several files and you do not want anyone else to have
access to them. You can protect them with password. I hope you will still remember it if do not use this
files for a long time. Or you can encrypt them using your public key. Probably you will use certificate
for other needs as well so even if system requires password each time private key is used you won't
forget it.

Certificate basics (technical)

1. Definition
Two types of encryption algorithms are used - symmetric and asymmetric. Symmetric encryption
algorithms deal with one secret key, which is used to both encrypt and decrypt information.
Asymmetric algorithms usually deal with a pair of keys, one of which is private (secret) and another
one is public (known to everybody). Certificate is a block of information in standard format that
contains a public key and supplementary information about this key. In broader meaning certificate can
also include an associated private key. The private key is not the part of certificate binary data, but
logically they create one entity.

There exist different certificate formats, designed for different applications. Most known formats are
PGP and X.509. X.509 certificates are used in SSL/TLS protocol, which is the base for secure Internet
communications. Format of X.509 certificates is defined in RFC 2459.

X.509 certificate structure is defined using Abstract Syntax Notation 1 (ASN.1). This notation allows
uniform identification of binary data structures on any system, not dependent from byte size and byte
order. The details of the structure can be found below.

2. Features and possible uses

The certificate contains the following information:

• Information about the person or organization, to which it was issued,

• Information about the organization that issued the certificate
• Date range when the certificate is valid.
• (Optional) information, which lets the application automatically verify validity of the certificate
and find out whether the certificate was revoked.

Also certificate can contain predefined or user-defined information about intended use of the
certificate. This means that the application can find out user's credentials and scope of operations that
the user is permitted to do. Each application can define it's own flags for the certificates it uses or
manages.

Due to its nature, certificate is currently the best choice for authenticating the person and information
that is distributed by this person, and also for defining the scope of operations allowed to the person.

Certificates are indispensable for providing easy-to-manage access control system for client-server and
n-tier applications. In this scenario the server issues certificates, in which it places information about
allowed uses of the certificate. Certificates together with their private keys are a good alternative to
regular username/password pairs. When the user connects to the server, it uses the certificate in the
process of establishing connection with the server. The server is able not only to validate the user's
authenticity, but also determine, what actions this user is allowed to take, or to which user group it
belongs.

Utilizing SSL/TLS protocol is the best way to involve the certificates into the "conversation", but if
your middleware doesn't provide an easy way to add SSL to data exchange, you will need to manage
certificates by hand. In both cases SecureBlackbox package will assist you in certificate management.
And if you need SSL, SecureBlackbox is a complete SSL/TLS solution.

3. Certificate management
Creation of the certificate is called issuing. The organizations that issue certificates are called
Certificate Authorities (CA). The person or organization to which the certificate is given (for which it is
issued) is called Subject.
The certificate is valid during some time period. If the certificate is used out of this time period, it is
either "not yet valid" or "expired".

When the certificate is issued, the certificate authority signs it and the signature of this certificate
authority is put to the certificate.

Certificate authority can claim the certificate to be not valid anymore in some cases. For example,
when Subject claims that the certificate's private key was stolen. Another case is when Certificate
Authority's private key has become known to third parties and the signature doesn't identify
authenticity anymore. Such certificate is called revoked. Certificate authority keeps the list of revoked
certificates and each certificate can contain the address (URI) of certificate revocation list.

There can be several type of CAs. If you utilize certificates for some n-tier software solution (for
authentication/security purposes), the certificates will most likely be generated by the server part of the
software solution. In this case the user of the server part will act as a CA. If the certificate is issued by
some organization to itself (i.e. the CA is the Subject), the certificate is called self-signed.

If the data exchange, in which the certificates are involved, is public (i.e. more than one organization
participates in the process), self-signed certificates are a security compromise. The side, which receives
the certificate during data exchange session, can't reliably verify the identity of the other side unless
there is some repository, which can confirm the identity of that other side. Certificate Authority itself is
a good repository. There are several commercial organizations that issue and manage certificates (most
of them are affiliates of VeriSign company). They act as certificate repositories and their authenticity is
well known to public.

Certificate authorities, that publicly issue certificates, usually require that the person, who requests the
certificate, prove his identity by passing regular (paper) documents (passport, driver's license etc).

Another type of public activity that involves certificates is electronic document signature or encryption.
In this case there is one party that signs/encrypts the data, and any number of parties that get the
information and must check it for validity.

When one side of data exchange session receives the certificate from other side, it is supposed to
validate the certificate, i.e. check the following:

• Certificate integrity must not be corrupted. Each certificate contains the data that can be used to
check certificate integrity. Information in corrupted certificate can't be used at all;
• If the certificate is not self-signed, CA's authenticity should be verified either. This is done by
looking for this CA's certificate in the repository. Repository can be local to the application that
validates the certificate (for example Windows 32 API provides API for accessing built-in
Windows certificate storage). Custom storage can be used (it can be located on other system
including public certificate repositories. If the certificate is found, we use CA certificate to
validate the certificate in question. If the certificate is not found, we can't confirm authenticity
of the certificate in question;
• Certificate validity time period must correspond to the data signing/encryption time. One should
not use expired or not yet valid certificates to sign/encrypt the data;
• Certificate should not be present in certificate revocation list. As mentioned, each certificate can
contain the reference to the certificate revocation list. The validating side should check the list if
 the reference is present. If the certificate is not self-signed, and there is no reference to
certificate revocation list inside, it is possible to check the CA's certificate for such a reference
and use it instead.
• (optional). Certificate purpose must correspond to the action being certified. Each certificate can
have a list of purposes, for which it is applicable.

Usually, certificate is only valid if all of the above conditions are true. If any of conditions is false, the
data source can't be fully trusted. SecureBlackbox offers methods to validate the certificate (except
revocation list lookup).

4. Supplementary services
One of the most important actions in certificate management is key recovery.

When the key is lost (because of data storage corruption or some accident or just erased by mistake),
it's probably lost forever. This means that if the key pair was used to encrypt the data, the data is also
unrecoverable. One of the ways to prevent this is to put the key (or key pair) to the digital envelope and
store this envelope somewhere. The envelope, however, must be secure too. This is achieved by
involving a third party (trusted person) to the process. Trusted person gives it's public key for envelope
creation. Trusted person itself doesn't necessarily have access to the envelope. If the original key is lost,
the owner of the envelope can contact the trusted person, who will apply it's secret key to the envelope
and open the envelope.

The disadvantage is that the trusted person must remain trusted and it must remain available. If its
security is compromised or the person becomes unavailable, all users of trusted person's services must
recreate their envelopes. To overcome the security risk of involving a trusted person it is possible to
involve several trusted persons. Each person's public key is used to encrypt only a part of the
information being secured (it's either secret key or symmetric key). Then a single person can't discover
the secret information as s/he doesn't have a ccess to the secured data (secret key or symmetric key).

When it is necessary to recover the key, each of those persons should be contacted to decrypt part of the
envelope. Unfortunately in this case if any of those persons becomes unavailable, the whole envelope is
useless.

In business it makes sense to use key recovery services, which are provided by public companies.
These companies can be related to certificate authorities somehow or can be independent organizations.
As with the trusted person mentioned above, the recovery service can have access to the keys used for
signing documents or to decrypt data. The benefit of the recovery service is that it usually has secure
infrastructure for key keeping and transfer.

If the certificate authority (CA) issues or plans to issue lots of certificates, it makes sense to delegate
some of its functions to registration authorities. Those authorities receive certificate requests from the
organizations or individuals, check their identity and issue certificates. They also manage certificate
revocation lists and re-issue expired certificates.

Certificate management is quite a complicated thing, which can involve other types of services and
actions. We don't review them here because the topic is enough for a book, not just an article.
5. Certificate structure
X.509 defines the following blocks of data in the certificate:

• Version. This is the version of the certificate format. Currently can be 1, 2, and 3.
• Certificate serial number.
• Signature algorithm identifier, which identifies the algorithm used to sign the certificate and
parameters for the algorithm.
• Issuer name. This is the name of the company that has issued (generated and signed) the
certificate.
• Validity period. This field defines lifetime of the certificate.
• Subject name. This field contains the name of the person/company, to which the certificate is
issued.
• Public key information. Contains the body of the public key, information about its algorithm
and parameters.
• Extensions (see below)
• Signature algorithm identifier (the same as described above).
• Signature value (body of the signature).

There were several revisions of certificate standard. The latest is X.509.3. Revisions 2 and 3 define
extensions to the original format.

Extensions can be critical or non-critical. If they are critical, the application, which doesn't handle such
extension, should not process such certificate further. Non-critical extensions can be ignored.

The certificate itself contains a flag, which defines whether certificate extension is critical or non-
critical.

X.509.2 defines the following extensions:

• Issuer Unique Identifier

• Subject Unique Identifier

X.509.2 extensions are not currently recommended for use by RFC 2459.

X.509.3 defines the following extensions:

• Authority Key Identifier. Critical for not self-signed certificates.

• Subject Key Identifier. Critical for not self-signed certificates and recommended for self-signed
certificates.
• Key Usage. This field is used to restrict the set of operations, for which the certificate is
eligible. The standard recommends flagging this extension as critical.
• Extended Key usage. This field is similar to Key Usage field, but RFC 2459 doesn't constrain
possible values of this field and any application can define it's own flags.
• CRL Distribution Points. This is the URL of the certificate revocation list, which can be used to
check validity of the certificate. This extension is non-critical, but it is recommended that the
applications support it.
 • Private Key usage period. This field defines the lifetime of the private key, associated with the
certificate. If the field is not present, the lifetime is the same as the lifetime of the certificate
itself. RFC 2459 doesn't recommend using this field.
• Other, more specific extensions. Full list can be found in RFC 2459

Conclusions
Certificates are very powerful and advanced technology, which, when used properly, can provide the
highest level of security in many areas of electronic activity. Basic certificate management, though, is
not too complicated thing and can be done by any application, especially with the help of
SecureBlackbox package.