Introduction to Certificates (common)


1. Introduction

Sometimes you need to be sure about the 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 a reliable bank agent and wants to offer you deal on beneficial terms, you will not take his words on trust. You will require him 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 would you take on trust the things that someone says, with whom you communicate via network? Digital certificates are used right in order to avoid such kind of situations. They allow the identification of the 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 a message signed with a 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 cannot 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 cannot find out that the message was really written by Bob as you think his public key to be Alice's one. It is necessary to have the possibility to find out that the sender is the one he gives himself out to be. How can you do it if you cannot 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.

Certificates contain information about the 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. The private key is not a part of the certificate. Unlike certificates, the private key is not public and it is an element you must store at the most secure place.

There are several different certificate formats used. One of the most used is X.509. This type allows the use of the certificates for various purposes due to its wide distribution and numerous extensions. Such certificates 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 a 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 and 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 levels. 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 a love-letter on your behalf the main victim of this action will be you or probably the 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 the extent of the 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 cannot 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 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 cannot use external storages, you just have to export thee 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, the certificate itself, without private key has not much use. If you only lose your private key and cannot 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?


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.


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.

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now