[toc]
## Basic Concepts ##
The central authority is usually a single entity that vouches the correctness of some data or information for its users.
We are surrounded by many such central authorities in our surroundings. Most of them are formed by the state, such as agencies or public offices in charge of issuing all kinds of documents. We place our trust in such central authorities that they will produce correct and valid data at any time we request the documents from it.
There are also various kinds of private entities that provide us with the same type of services.
In all of these cases the central authority has various means of guaranteeing that the document it issues is valid and that it can be trusted. For example, the national banks in charge of issuing the paper we call *money* use special paper, colours, holograms and a plethora of other similar protections in order to guarantee that the money issued is real and that it can be distinguished from the forged documents.
Ministries and government offices in charge of issuing personal ID cards or passports employ similar techniques which guarantee the same guarantee for those documents.
## X.509 ##
X.509 builds on similar concepts as examples presented above. It is a huge standard described by many different documents. X.509 builds around on top of the PKI, introducing *certificates* which serve the purpose of making guarantees of validity of some public key (the identity of the entity presenting such certificate, as well as the actual authenticity of the entity through the signing process).
In addition to issuing certificates for identification purposes, X.509 also introduces various additions like specifying the allowed usages for a certificate, hierarchies amongst the certification authorities, ability to invalidate certificates by revoking them, as well as means of verifying the certificates.
### X.509 Certification Authority ###
The X.509 certification authority forms the base of each X.509 environment. It is the focal point of trust in such an environment. Compromises associated with certification authority usually lead to complete and utter destruction of the trust it had provided.
Each certification authority has a single private/public key pair. This pair is used for *issuing* certificates (more on certificate structure down on this page). Issuing of certificate involves combining a public key of some entity with additional information and making a signature of such a bundle. The signing operation is performed using the certification authority private key.
In other words, the certification authority primarily serves the purpose of signing data.
Such signatures can be verified by the client provided the the client has the certificate of the certification authority itself. This certificate can be either *self-signed* (meaning that the information and public key contained within it are signed by the very same certification authority) or signed by some *other* certification authority.
In the latter case the certification authority is referred to as *root* certification authority. In former case the certification authority is usually referred to as *intermediate* certification authority. Most often the root certification authority is not involved in issuing certificates to end entities, leaving that task to the intermediate certification authority.
### X.509 Chain of Trust ###
The root certification authority most often represents a central point in trust. It is therefore often referred to as *trust anchor*. Together with intermediate certification authorities it presents a chain of trust the entities can verify.
The chain of trust is comprised out of the trust anchor certificate, end entity certificate, and any number of intermediate certificates necessary for *linking* the end entity certificate to the trust anchor.
For example, let's say we have a *Root CA*, a *Server CA*, and an end entity certificate for a mail server. The end user accessing the mail server has the *Root CA* and *Server CA* locally stored on his/her computer. Upon reading the mail server's certificate the user finds out that it has been signed by the *Server CA*. The user then verifies this by using the public key from the *Server CA* certificate stored locally on his/her computer. After that the user also makes additional check by making sure that this *Sever CA* is indeed signed and issued by the *Root CA*. Upon establishing this the user has effectively managed to reconstruct the chain of trust which was involved during the issuing of the end entity certificate (in this case, the mail server). Therefore the user can trust the mail server to be genuine provided that he/she trusts the *Root CA* as well.
### X.509 Certificate ###
### X.509 Infrastructure ###