Wikipedia defines public key infrastructure as “a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.” In other words, PKI is the system with which we establish trust between digital entities through the issuing and revocation of digital certificates. This blog entry attempts to cover PKI from a broad and generalized perspective and serves as a beginner’s guide to the topic.

In order to understand Public Key Infrastructure one must understand the fundamentals of asymmetric encryption and the role that certificates play in the encryption process. Rather than reinventing the wheel here I have provided a YouTube video below that briefly cover these topics.

Now that you have a basic understanding of how Asymmetric encryption works we can take a look at how it applies to certificates and certificate authorities (CAs). The most common use of certificates is in website encryption. The certificate provided by a webserver contains the public key that visitors can use to encrypt communications and the server uses its private key to decrypt the traffic.

By pressing F12 in chrome we can go to the security tab to view the website’s certificate.

On first inspection we see the certificate’s period of validation, who issued the certificate, and the associated common name it was issued to. In this case of google.com’s certificate we see the certificate was issued to *.google.com from their own CA Google Internet Authority G2 CA.

The asterisk means the certificate is a wildcard certificate and signifies that this certificate can be installed on any site ending with google.com. In this case, https://www.google.com is secured, but the same certificate is also present on https://news.google.com.

Further investigation of the certificate can be carried out by going to the details tab. Here, you’ll find fields such as the public key, subject (common name), subject alternative names (all of the DNS names this certificate can secure), certificate revocation list URL (to check if the certificate is still valid), authority information access, and many other details.

At their most basic definition, CAs are entities that sign certificate requests. Certificate requests are typically generated from the server requesting a certificate, but can be generated elsewhere and installed later on the server in question. Public certificate authorities are considered trusted and anything signed by these CAs are automatically trusted on endpoints. This is the case because operating systems have a pre-built list of CAs that are considered trusted root certificate authorities. Here is the lists that Windows comes with.

If you think about it, it’s a pretty short list, and for good reason. Public CAs are considered trusted entities whose root certificates are automatically installed and trusted on most devices. Subsequently, any certificates signed by this certificate will show as trusted in a browser. However, the Root CA does not sign certificates, but instead signs the certificate of subordinate CAs which issues certificates to servers. In this way, PKI trust is established through a hierarchical system of Root and Subordinate CAs. This can be viewed in Windows by going to the Certification Path tab while viewing a certificate.

From the above image we can see what the PKI hierarchy is for this certificate. Because our computer trusts the GeoTrust Global CA, we automatically trust anything it trusts. Thus, CA trust is transitive in nature. On this tab, you can also view the certificates of any other CAs in the certificate chain up to the root.

Due to the nature of this hierarchical trust, any Public Root CAs who do not uphold PKI standards are subject to blacklisting by operating systems and browsers. In recent memory, Symantec was caught issuing tens-of-thousands of extended validation (EV) certificates without going through the proper checks. EV certificates gather more information from the organization requesting the certificate and in exchange issue a certificate that browsers indicate is more trusted. In Chrome, EV certificates are easily differentiated from standard certificates because the organization’s name is in the address bar instead of simply stating “secure”.

                                  

In any case, EV certificates do not function any different than their standard counterparts (domain validation and organization validation types) and still follow the tenets of asymmetric encryption.

In addition to signing certificates, certificate authorities also provide mechanisms to revoke certificates should they be signed in error, need renewal, or have had their private keys exposed. The two mechanisms for this are certificate revocation lists and Online Certificate Status Protocol (OCSP). CRLs typically take longer to update so a day could go by before a CRL reflects an invalidated certificate. They’re also quite large as time goes on as they list every certificate that has been revoked. OCSP, on the other hand, is much faster and allows the client to send an OCSP request to the CA’s OCSP responder, which replies with a good, revoked, or unknown status. This works well for the most part but can be subject to volumetric attacks on the OSCP responder. If it’s too busy to respond to clients, the sites they’re trying to visit are practically down.

Internal PKI

So far, I’ve only talked about public certificate authorities. Internal PKI essentially works the same way, only the root CA’s certificate is not automatically trusted on computers by default. However, if you use a directory service such as Active Directory, or have a MDM platform which configures your endpoints, you can have one of those platforms automatically have each computer in the organization trust the internal root CA. This allows administrators to issue certificates that do not cost anything, besides server licensing, and allows for locking down far more than websites internally. Certificates can be issued internally to secure wireless and wired 802.1x connections, provide certificates for encrypting individual files, secure workstation access with smart cards, sign code, secure email by verifying the sender, and encrypt network traffic between two endpoints. Having a PKI opens up a number of use case.


Conclusion

PKI is responsible for all client to server encryption on the web. At first, the topic can be overwhelming, and creating your own PKI can be a daunting task that requires plenty of forethought and planning. However, the basics of hierarchical trust and asymmetric encryption remain a rather straight forward process. I recommend anyone who is involved in technology to become acquainted with these concepts. Whether you’re a web developer, desktop technician, or a seasoned systems administrator, knowing these basic concepts will only help you be better at your job. I have provided a few follow up resources below for those who wish to learn more.

Additional Resources

Symantec CA Controversy
https://www.infoworld.com/article/3184482/security/google-to-symantec-we-dont-trust-you-anymore.html
https://arstechnica.com/information-technology/2017/03/google-takes-symantec-to-the-woodshed-for-mis-issuing-30000-https-certs/

Extended Validation Certificates
https://www.globalsign.com/en/ssl-information-center/what-is-an-extended-validation-certificate/

I highly recommend these Security+ videos from Professor Messer for more detailed coverage on these topics.


0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *