Internet traffic consists of traffic between two parties. When establishing an asymmetric connection between two hosts, the hosts will exchange their public key information. An SSL certificate is a digital certificate that confirms the identity of a website domain. To implement SSL on your website, you purchase an SSL certificate for your domain from an SSL Certificate provider. The trusted third party does an in-depth investigation prior to the issuance of credentials. In this article, I want to talk about Authority and PKI Trust System.
After this in-depth investigation, the third-party issues credentials (i.e. digital certificate) that are difficult to forge. From that point forward, all individuals who trust the third party simply accept the credentials that the third-party issues. When computers attempt to connect to a web site over HTTPS, the web browser checks the website’s security certificate and verifies that it is valid and originated with a reliable CA. This validates that the website identity is true. The certificate is saved locally by the web browser and is then used in subsequent transactions. The website’s public key is included in the certificate and is used to verify future communications between the website and the client.
These trusted third parties provide services similar to governmental licensing bureaus. The figure illustrates how a driver’s license is analogous to a digital certificate.
The Public Key Infrastructure (PKI) consists of specifications, systems, and tools that are used to create, manage, distribute, use, store, and revoke digital certificates. The certificate authority (CA) is an organization that creates digital certificates by tying a public key to a confirmed identity, such as a website or individual. The PKI is an intricate system that is designed to safeguard digital identities from hacking by even the most sophisticated threat actors or nation-states.
Some examples of Certificate Authorities are IdenTrust, DigiCert, Sectigo, GlobalSign, and GoDaddy. These CAs charge for their services. Let’s Encrypt is a non-profit CA that offers certificates free of charge.
The Public Key Infrastructure
PKI is needed to support the large-scale distribution and identification of public encryption keys. The PKI framework facilitates a highly scalable trust relationship.
It consists of the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates.
The figure shows the main elements of the PKI.
The figure shows a user at a pc with the words PKI certificate above it and a circled number one. There is a circled number 2 beside the computer with the words certificate store. To the right of the user is a circled three public building icon labelled PKI certificate authority and to the right of that is a circled four and a cylinder labelled certificate database.
The next figure shows how the elements of the PKI interoperate:
- In this example, Bob has received his digital certificate from the CA. This certificate is used whenever Bob communicates with other parties.
- Bob communicates with Alice.
- When Alice receives Bob’s digital certificate, she communicates with the trusted CA to validate Bob’s identity.
The figure shows a certificate database icon in the top right corner with a line connecting it to a public building icon labelled certificate authority and the circled number one beside it with the words issues PKI certificate. An arrow goes to a computer user labelled bob that has the circled number two beside it an arrow leading to the Alice computer user with the words exchanges PKI certificate. Above the Alice computer are the words verifies the PKI certificate, a circled number 3, and an arrow the points back to the certificate authority.
Note: Not all PKI certificates are directly received from a CA. A registration authority (RA) is a subordinate CA and is certified by a root CA to issue certificates for specific uses.
The PKI Authorities System
Many vendors provide CA servers as a managed service or as an end-user product. Some of these vendors include Symantec Group (VeriSign), Comodo, Go Daddy Group, GlobalSign, and DigiCert among others.
Organizations may also implement private PKIs using Microsoft Server or Open SSL.
CAs, especially those that are outsourced, issue certificates based on classes which determine how trusted a certificate is.
The table provides a description of the classes. The class number is determined by how rigorous the procedure was that verified the identity of the holder when the certificate was issued. The higher the class number, the more trusted the certificate. Therefore, a class 5 certificate is trusted much more than a lower-class certificate.
|0||Used for testing in situations in which no checks have been performed.|
|1||Used by individuals who require verification of email.|
|2||Used by organizations for which proof of identity is required.|
|3||Used for servers and software signing. Independent verification and checking of identity and authority is done by the certificate authority.|
|4||Used for online business transactions between companies.|
|5||Used for private organizations or government security.|
For example, a class 1 certificate might require an email reply from the holder to confirm that they wish to enrol. This kind of confirmation is a weak authentication of the holder. For a class 3 or 4 certificates, the future holder must prove identity and authenticate the public key by showing up in person with at least two official ID documents.
Some CA public keys are preloaded, such as those listed in web browsers. The figure displays various VeriSign certificates contained in the certificate store on the host. Any certificates signed by any of the CAs in the list will be seen by the browser as legitimate and will be trusted automatically.
Note: An enterprise can also implement PKI for internal use. PKI can be used to authenticate employees who are accessing the network. In this case, the enterprise is its own CA.
The PKI Trust System
PKIs can form different topologies of trust. The simplest is the single-root PKI topology.
As shown in the figure below, a single CA, called the root CA, issues all the certificates to the end-users, which are usually within the same organization. The benefit of this approach is its simplicity. However, it is difficult to scale to a large environment because it requires a strictly centralized administration, which creates a single point of failure.
The figure shows a server labelled root c a with a certificate next to it. There are two arrows each pointing to a computer. each computer also has a certificate next to it.
Single-Root PKI Topology
On larger networks, PKI CAs may be linked using two basic architectures:
Cross-certified CA topologies – As shown in the figure below, this is a peer-to-peer model in which individual CAs establish trust relationships with other CAs by cross-certifying CA certificates. Users in either CA domain are also assured that they can trust each other. This provides redundancy and eliminates the single point of failure.
The figure shows the same set up as the previous single-root PKI topology, but it is labelled c a 1. there is a two-way arrow between this topology and another of the same topology labelled c a 2. an arrow points from the c a 2 topology to another of the same topology labelled c a 3.
Hierarchical CA topologies – As shown in the figure below, the highest-level CA is called the root CA. It can issue certificates to end-users and to a subordinate CA. The sub-CAs could be created to support various business units, domains, or communities of trust. The root CA maintains the established “community of trust” by ensuring that each entity in the hierarchy conforms to a minimum set of practices. The benefits of this topology include increased scalability and manageability. This topology works well in most large organizations. However, it can be difficult to determine the chain of the signing process.
A hierarchical and cross-certification topology can be combined to create a hybrid infrastructure. An example would be when two hierarchical communities want to cross-certify each other in order for members of each community to trust each other.
The figure shows a server labelled root c a with a certificate next to it. There are two arrows each pointing to a subordinate with a single-root pki topology.
Interoperability of Different PKI Vendors
Interoperability between a PKI and it’s supporting services, such as Lightweight Directory Access Protocol (LDAP) and X.500 directories, is a concern because many CA vendors have proposed and implemented proprietary solutions instead of waiting for standards to develop.
Note: LDAP and X.500 are protocols that are used to query a directory service, such as Microsoft Active Directory, to verify a username and password.
To address this interoperability concern, the IETF published the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527). The X.509 version 3 (X.509 v3) standard defines the format of a digital certificate.
Certificate Enrollment, Authentication, and Revocation
The first step in the CA authentication procedure is to securely obtain a copy of the CA’s public key. All systems that leverage the PKI must have the CA’s public key, which is called the self-signed certificate. The CA public key verifies all the certificates issued by the CA and is vital for the proper operation of the PKI.
Note: Only a root CA can issue a self-signed certificate that is recognized or verified by other CAs within the PKI.
For many systems such as web browsers, the distribution of CA certificates is handled automatically. The web browser comes pre-installed with a set of public CA root certificates. Organizations and their website domains push their public certificates to website visitors. CAs and certificate domain registrars create and distribute private and public certificates to clients that purchase certificates.
The certificate enrollment process is used by a host system to enrol with a PKI. To do so, CA certificates are retrieved in-band over a network, and the authentication is done out-of-band (OOB) using the telephone. The system enrolling with the PKI contacts a CA to request and obtain a digital identity certificate for itself and to get the CA’s self-signed certificate. The final stage verifies that the CA certificate was authentic and is performed using an out-of-band method such as the Plain Old Telephone System (POTS) to obtain the fingerprint of the valid CA identity certificate.
Authentication no longer requires the presence of the CA server, and each user exchanges their certificates containing public keys.
Certificates must sometimes be revoked. For example, a digital certificate can be revoked if a key is compromised or if it is no longer needed.
Here are two of the most common methods of revocation:
- Certificate Revocation List (CRL) – A list of revoked certificate serial numbers that have been invalidated because they expired. PKI entities regularly poll the CRL repository to receive the current CRL.
- Online Certificate Status Protocol (OCSP) – An internet protocol used to query an OCSP server for the revocation status of an X.509 digital certificate. Revocation information is immediately pushed to an online database.
I know you might agree with some of the points that I have raised in this article. You might not agree with some of the issues raised. Let me know your views about the topic discussed. We will appreciate it if you can drop your comment. Thanks in anticipation.
Download Our App.
CEHNigeria On Google Playstore
Download Our Blog App On Google Playstore.
GET SEOPOZ. OUTSMART YOUR BLOG COMPETITORS
Have a deeper understanding of Google Search Console. Joint SEOPOZ for free.
Join Our Whatsapp Group Here
Join Our Whatsapp Group
Follow Us On Twitter and I will Follow Back
Follow Us On Twitter
Kindly follow me on Twitter and I promise I will follow back. Aside you will get updated when we post new articles.