en English

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

What is PKI?

Public Key Infrastructure (PKI) as a term describes systems and components used in securing internet communications and transactions. This article will cover a high-level breakdown of the various PKI components and how they interact in the PKI ecosystem. If you’re a company owner looking to beef up your cybersecurity or just anyone who’s interested in Public Key Infrastructure, this piece will provide you with some practical and grounded examples.  


Where is PKI used?

Discussions of PKI will quickly lead to you SSL (Secure Sockets Layer)/TLS (Transport Layer Security), which require a private key and a public key. The private key is held on the web server. The public key is embedded in the SSL certificate. When you visit a website and you see that lock to the left of the address bar, and the URL says “HTTPS,” (as opposed to HTTP), your browser will automatically download that public key along with the certificate, which confirms that the website is indeed who it presents itself to be. If there was anything that didn’t pass this exchange, the browser will give you an error warning. The browser goes through this exchange of certificates and keys in a matter of a split second. 

The private key is held on the web server. That is not to be discovered by anybody other than authorized personnel on the website. The public key is distributed to you, me, everybody else at large.

How does PKI work in a Browser?

The private key and public key are a couple. Let’s say Bob has a private key and Sally and Joe have the public key. Sally and Joe can’t communicate with each other because they both have the public key. Bob knows that whatever message he’s getting is from someone who has the public key.

How do Sally and Joe know that they’re communicating with someone who calls himself Bob? This is where certificates come in to play. For Sally and Joe to know they’re actually interacting with Bob, his certificate will confirm that. The certificate is signed by a Certificate Authority like SSL.com and it will be trusted in whatever platform they’re using, in this case a browser.

Public key and private key are computatively intensive. In order to get a comfortable level of encryption with today’s computing technology, public key sizes are a minimum of 2048 bits. You can get them up to 4096 which is much more intensive. It is more secure but there’s a point of diminishing returns. 2048 is what most people use. With secret key, on the other hand, you can put that up with 256 bits.

What is the SSL Handshake?

An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. It determines what version of SSL/TLS will be used in the session, which cipher suite will encrypt communication, verifies the server (and sometimes also the client), and establishes that a secure connection is in place before transferring data. You can read more details in our guide.

The SSL/TLS Handshake: an Overview - SSL.com



How does PKI enable secure emails?

To a certain degree, the SSL/TLS handshake also applies to Secure/Multipurpose internet Mail Extensions (S/MIME). It isn’t quite like you’re going to the website and getting the certificate. With the SSL handshake, it lasts a session, say five minutes, and then the traffic is gone. When you do it with S/MIME, it’s the same concept but your emails may last years.

To illustrate how PKI helps in making email exchanges safe, let’s use the previous characters again. Sally sends Bob her public key in an S/MIME certificate and she’ll get Bob’s email in an S/MIME certificate as well. And since they both have their private key, they can do encrypted email with each other. An S/MIME certificate does allow you to do multi-party emails so as long as you have everybody’s S/MIME certificates in a group, you can email everybody and they can do the same thing to you. Typically, if you’re using a common email client, and you’re trying to do encrypted email to a group of people, it should warn you if you don’t have S/MIME for a specific person, in which case, you won’t be able to encrypt the email. 

How does Encryption and Authentication Figure in S/MIME?

Let’s also make a distinction between encryption and authentication. If I ask for your S/MIME and you ask for my S/MIME, we can send encrypted email. However, if I sign my email using my S/MIME certificate and send it over to you, I can sign an email and it will be encrypted but you know it came from me.  

So if I get an S/MIME certificate issued by SSL.com and I sign my email and I send it to you and you don’t send me your S/MIME certificate, we won’t be able to send and decrypt encrypted email. But you’ll still be able to see that my email was signed with an S/MIME certificate issued by SSL.com and it should say the sender’s name, information that was validated.

Information that cannot be validated does not appear on the certificate. If it’s a publicly-trusted certificate, meaning it’s trusted by popular platforms, it needs to be validated according to baseline requirements which are the minimum standards put together by the CA browser form.  

What are PKI certificates?

How does a public key get distributed out there and how do you attach an identity to it? It’s through a certificate. And that’s what a Certificate Authority does, it issues certificates that you could attach to a public key and distribute it.

There are certain standards that need to be followed in order to issue a certificate. The certificate authority has to understand that you have a right to that certificate and any information that’s embedded in that certificate. And therefore, when we issue that certificate, it is trusted by the browsers. 

What is an X.509 PKI certificate?

 X.509 is like a stem cell. It’s basically a format with certain fields. Before you know what kind of certificate it is, it starts out as this zygote. Before one becomes an SSL certificate, there are certain rules on what information can be populated here. Same thing with S/MIME, Code Signing, Document Signing, Client Authentication, and other certificates that may come up in the future. Except for SAN, the following fields make up the Subject Distinguished Name.

  • Common name (CN) – typically, this is what appears as the subject of the certificate. For an SSL certificate, this refers to the domain name. It has to have globally-supported top-level domain extensions (i.e. .com; .net; .io). There’s literally hundreds, maybe thousands of them by now, and we have to be able to accommodate all of that.
  • Organization (O) – the company or website owner
  • Organizational Unit (OU) – this would be something like a department: IT, Finance, Human Resources
  • Locality (L) – basically a city
  • State (ST) – the regional location, also known as province, depending on the country
  • Country (C) – the country code
  • Subject Alternative Name (SAN) – an extension to X.509 that serves to identify those host names that have been secured by one SSL certificate.

What are the Components of the PKI Ecosystem?

  • The Certificate Authority- is a company that issues trusted certificates which are approved on a various number of platforms, most commonly browsers: Google Chrome, Safari, Firefox, Opera, 360. In the context of PKI, CA means the issuing company or mechanism that issues the certificate.
  • The Registration Authority – this will typically do the validation. It will do a bunch of the prep work and once all that has been completed, it will send the request to the CA for issuance of the certificate. The RA could also be a company, an app, or a component.
  • Vendor – this is the browser
  • Subscriber – the website owner who is buying the certificate (i.e. the company who is buying the certificate for their employees)
  • Relying Party – the person, at the end, who’s consuming the certificate 

What is a Private PKI?

Can you have a closed PKI that’s not publicly trusted? Yes, such as IoT devices in a closed environment. For instance, you can have Samsung and only Samsung products get to talk to each other: TVs, phones, stereos. In private PKIs, devices from outside third parties can be barred from communicating with the internal system. They can be small, they can be large. There are PKIs that have dozens of devices and PKIs  that have millions of devices.

What is the Future of PKI?

The technology is evolving. Instances of private PKI are no less important than the web PKI, because even if a company uses private PKI, it’s still wise to partner with a CA like SSL.com that undergoes yearly audits and has professionals that are dedicated to preserving the integrity of the private keys by locking them away and keeping them offline.

The more the PKI ecosystem has discussions about the baseline requirements, the more difficult it is to replace this technology. You can put the certificates and install them at the domain registration but the policies cannot be easily ported over.

Even with quantum computing on the horizon and future changes in the technology, the need for secure privacy and authentication will not go away. If new technology comes along, the industry will adapt. We’re in the trust business and that’s not about to go away.

Share on twitter
Share on facebook
Share on linkedin
Share on reddit
Share on email