Menu
Menu
The Certificate Authorities CA is a critical element of the PKI Public Key Infrastructure. They are a trusted entity that issues digital certificates. Today, Certificate Authorities are used everywhere: from issuing TLS certificates for websites to issuing digital certificates to secure IoT Internet of things devices.
A certification authority or CA is a trusted party whose integrity is undeniable and whose public key is widely known. The task of the certification authority is to authenticate asymmetric encryption keys using electronic signature certificates.
Technically, the CA is implemented as a component of the global directory service and is responsible for managing users’ cryptographic keys. Public keys and other information about users are stored by certification authorities in the form of digital certificates.
CAs are built into a multi-level hierarchy where at each level a CA can perform both the role of an issuing CA and additional functions. In the simplest case, one CA can combine all roles. This means that it will act as the root CA, provide security issuance policies and issue certificates to end users.
Larger companies with more complicated IT processes are using CA divisions based on their roles. For example, at the head office they keep a root CA that issues certificates only to other intermediary CAs that already impose issuance policies on themselves. They may not directly serve end users, but issue certificates to other subordinate CAs, which will serve the end users.
Private components of electronic certificates can be disclosed from time to time by mistakes or malicious actions. Therefore, CA should be able to revoke the certificates of its “subordinates”.
First version of TLS was based on the Secure Sockets Layer SSL protocol and the functions of these protocols were similar, ssl certificates were often called TLS certificates. Current versions of the protocol support compatibility with the legacy SSL protocol. Therefore, today the term SSL is used together with TLS – SSL/TLS – to describe the TLS protocol.
The current protocol version at the time of publication is TLS 1.3. This version was released in 2018 by the Internet Engineering Task Force (IETF). Today, this standardization organization manages the development of a new protocol. The previous version of TLS 1.2 is still in use and has not yet been deprecated, the full transition to TLS 1.3 is still not complete.
Despite the recognition of the SSL protocol as insecure, it continues to be used on older hardware and software. The same thing happens with legacy versions of the TLS protocol: TLS 1.0 and TLS 1.1. These versions of the protocol are considered insecure because they use the SHA-1 and MD5 hashing algorithms. Most modern web browsers by default do not open pages of sites that use outdated versions of the TLS protocol. However, nowadays the number of such sites is less than one percent of the total.
The CA acts as a guarantor that the owner of the certificate is who he claims to be. For example, SSL certificates contain and display your domain name, your organization name, your address, expiration date, and information about the certificate authority responsible for issuing the certificate.
When a browser connects to such a site, it receives a Secure Socket Layer SSL certificate from it and makes a series of checks using the public key of the CA that issued the certificate: is the certificate expired, is the certificate issued by a CA certificate authority known to it, and is the certificate used on the site for which it was issued.
If one of these parameters fails the browser notifies the visitor that this site is not secure.
Digital certificates are a form of identification. Other common types of credentials include your driver’s license, state passport, birth certificate, etc. Each of these carries some information that identifies you and some unforgeable record that someone else has identified you.
A digital certificate is similar in purpose to a physical one. A digital key certificate is information attached to a user’s public key that helps others determine whether the key is genuine and correct. Assurance digital certificates are needed in order to make it impossible to try to give the key of one person for the key of another.
A digital certificate consists of three components: the public key to which it is attached, data about the user’s identity and rights, and one or more digital signatures that “bind” the key to the certificate.
Microsoft Root Certificate view example and its contents
Certification Authorities are required to ensure the security of information transmission over public and private networks. They act as guarantors that to whom the certificate is issued to those for whom he claims to be.
Most certification authorities issue certificates for websites. This is necessary to establish a secure connection between the user’s browser and this site and prevent different attacks of hackers. Browsers have certificates with which they can verify site certificates.
Without digital certificates, no online banking, online shopping or telecommuting would be possible without the risk that critical data could be stolen.
There are several types of trust hierarchy between CAs. The simplest of them is when there is only one CA that performs all the functions on its own.
In turn, the hierarchical structure, at the head of the entire structure is one Head CA which is trusted by everyone and subordinate CAs are subordinate to it. In addition to this head CA there is more than one CA in the structure, which is subordinate to a higher CA to which any users or subordinate CAs are assigned.
The PKI network architecture is built as a network of trust with numerous certification authorities providing PKI services and connected by equal relations. There is no one main CA that everyone trusts. In this architecture all CAs trust adjacent CAs and each user trusts only the CA from which he issued the certificate. CAs issue certificates for each other: a certificate pair describes a two-way trust relationship.
In a cross-certified architecture there are several parts each of which has its own PKI, but they want to communicate with each other resulting in their common inter-company PKI. The cross-certified enterprise PKI architecture has the most complex certification chain system.
The bridge CA architecture was designed to address the disadvantages of the complex certification process in a cross-certified enterprise PKI. In this case all companies trust not just one or two firms but one specific bridge CA which is not the main point of trust, but serves as an intermediary between other CAs.
A public CA issues certificates for users outside the organization, the work of CA requires an impeccable reputation and compliance with the requirements of both industry regulators and developers of ubiquitous browsers. It is necessary to regularly pass compliance audits, use special software and hardware, and also comply with the requirements for the physical security of the premises where the root certificates are located. All this requires huge investments, so there are not so many universally recognized certification centers around the world.
However, it can be much easier to set up a CA within a company, although it may require certain costs to ensure the secure operation of the CA and the certificate lifecycles.
There are two types of certification authorities: root and intermediate. Often certificates are issued by intermediate CAs.
For example, before establishing a connection to the server, the client browser checks the server’s certificate. To establish a dependency between the server certificate and root certificates known to the browser the Intermediate certificate is needed. Having found that the server is backed by an intermediate certificate which in turn is tied to the root the browser can establish a secure https connection.
In some cases, a chain of trust may contain two or three intermediate certificates. This is done to provide a stronger level of protection.
The chain of right holders can be determined from the digital signatures of the certificate. This procedure may take a long time or even be impossible in the absence of Internet access. Using the installed intermediate certificate allows the browser to immediately associate the certificate used for security with the root certificate and avoid further checks. Thus, the intermediate certificate serves to verify and facilitate secure connection establishment.
Although most of the certificates issued are used to establish and protect secure communications on the Internet, you can receive other certificates that can be divided into several installation groups:
The first thing to start with is to decide on the type of certificate. The price and data provided by CA differ depending on the type of certificate. Next, you will need to place an order and generate a CSR request to obtain a certificate. A CSR request is a special request containing detailed information about the domain and company and the public key.
When generating a CSR request you also create a special private key. You must store it in a safe place, because without it your certificate will not work and if the key pair falls into the wrong hands, it will be impossible to guarantee security. Once the CSR has been generated you will need to attach a copy of the CSR to CA.
First of all, it is necessary to consider the purpose for which the certificate is obtained. Depending on what your organization is doing, you may need not only the type of certificate, but also compliance with industry requirements for electronic certificates and certificate authorities that issue them.
In addition, it is worth taking into account the reputation of the certification authority. It will not be superfluous to study what will be required to obtain a certificate, how long it will take and how much it will cost. Think about what additional CA services you might find useful. Some CAs do not provide prompt support and feedback. This can be critical for an online business when a site security breach can be very costly for the company.
There are two main types of CAs, private and public. Their working process is similar but they are used for different purposes.
Public certificate authority issues digital certificates to various organizations. They are most widely used for issuing certificates used on the Internet. Such certificates are issued to organizations for the secure operation of websites and applications.
World leaders in the digital industry, together with industry regulators, are developing standards and requirements for such certificate centers. Public certificate authorities must comply with them in order for their certificates to be accepted as trusted and accepted as such by browsers on the Internet.
The requirements include responsibility for validating the details of the organization that requests the certificates. The requirements also include the use of software and hardware solutions that meet industry standards. In addition, strict adherence to security policies is required. Including physical devices involved in the process of issuing and storing certificates.
Nowadays, there are not so many international certification centers due to the fact that earning trust and maintaining a reputation is sometimes extremely costly.
Even if you manage to create your own publicly trusted CA, you’d then still have the issue of figuring out how to gain market share in an established marketplace. Out of the hundreds of certificate authorities that exist globally, only a handful of commercial CAs are responsible for issuing the overwhelming majority of publicly trusted certificates in use globally. DigiCert, Sectigo, and IdenTrust (Let’s Encrypt) are the top-3 among the world’s largest public CAs.
Your public CA root and/or intermediate certificates must be included in the trust stores on multiple platforms to be publicly trusted, they are also called root stores. To be included in these stores your CA must meet a series of initial requirements as well as ongoing program requirements. For example, Microsoft’s Root Certificate Program must be used to distribute your trusted root certificates across various Windows running systems so applications can use them for reference. Windows uses certificate trust lists (CTLs) to store trusted and untrusted root certificates.
For security within the organization, private certificate authorities are used. There are many reasons, including greater control and flexibility for securing your internal networks and services as well as simplifying authentication for your employees.
The main difference from public certificate authorities is that only devices or employees within the organization can trust such certificates. Outside of it, such certificates will not have any weight. Private CA certificates aren’t publicly trusted, so they won’t be used by external users, clients, operating systems or services. Therefore, you don’t have to go through all the difficulties that public CAs do in terms of root ubiquity.
The main scenarios for using these are also strikingly different. Since certificates are not trusted outside of the company, they are not used on websites on the Internet or in public applications. Such certificates are used for secure communication within the company network between servers and devices of employees or the Internet of things. In addition, private CA digital certificates can be used to sign code or sign documents. Digital certificates within a company can be used to control file sharing in the same way employees use a card key to physically access an office.
Generally speaking, digital certificates within a company are part of authentication. Digital security built on digital certificates is much more reliable than login and password authentication. In addition, this authentication system provides more granular access management and helps ensure security when working remotely or when working with cloud services that the company uses.
Companies can create certificate authorities themselves, come up with policies and ensure their correct operation. Today, however, it is becoming more and more common for companies to deploy CAs that provide turnkey security services.
Summarizing the above you get the following advantages with your own private CA in case you really need them:
Certificate Authorities play a critical role in today’s digital world. Both on the Internet and within the networks of private organizations, the need for reliable and trusted certificate authorities is growing every day. Helenix works with the most qualified partners in the development and deployment of certificate authorities. We develop solutions for a variety of needs of our clients using the most advanced and proven cybersecurity practices. You can learn more about our competencies in the About Us section.
A certificate authority is an authority that issues digital certificates that are considered trusted by users or other certificate authorities. CAs can be public or private depending on the purpose of their use.
Certification authorities ensure the issuance of digital certificates. Depending on the hierarchy of trust, certificates can be intended for both end users and other certification authorities.
An example of a certificate authority is an organization that issues TLS/SSL digital certificates to protect companies’ websites. Such an organization will be a public certification authority. For example, our partner company Entrust.
In order to find the certification authority that issued the digital certificate, you need to open the information about the digital certificate. The corresponding section will provide information about the certification authority.