- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Certificates and the technologies surrounding them can be a difficult topic to understand. In this series, we’re going to break down the underlying concepts around these technologies in a straightforward, easy-to-understand way. In our first part we will cover the basics of certificates and how they work, and in the future we’ll talk about SCEP, AD CS, 802.1x, and more.
What is a certificate?
- A certificate is a unique, digitally signed document which authoritatively identifies the identity of an individual or organization.
What makes up a certificate?
- A signed digital certificate contains the owner’s distinguished name, the owner’s public key, the certificate authority’s (issuer’s) distinguished name, and the signature of the certificate authority over these fields.
- There are often other fields, such as Country, State/Province, City, Organization, Department, and more which can more accurately identify the certificate or the object which the certificate identifies. These fields aren’t always there, but don’t be surprised to see them occasionally.
- Here is an example of the jamf.com web certificate:
https://jamf.com
Common Name: *.jamf.com
Subject Alternative Names: *.jamf.com, jamf.com
Valid From: March 31, 2022
Valid To: April 29, 2023
Issuer: Amazon, Amazon
Serial Number: 033beb304fddd18ab9bedf25861df734
What do certificates do?
- A digital certificate provides:
- Authentication, by serving as a credential to validate the identity of the entity that it is issued to.
- Encryption, for secure communication over insecure networks such as the Internet.
- Integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.
- In other words:
- Certificates can be used to authenticate users and devices for access to a network (VPN or 802.1x network), access to network resources (such as a network drive), and other sensitive resources (internal websites, databases, and applications).
- Certificates can encrypt communication via TLS (previously known as SSL) encryption and can be used to secure access to websites on the internet or other networks.
- Certificates can identify computers and other devices to other computers similarly to serial numbers or unique names given to resources by humans.
- Certificates can sign a file, which prevents modification or allows the detection of modification, to ensure that a file is not altered in transit (file uploads/downloads, emails, etc.).
How do certificates work?
- Certificates are a part of Public Key Infrastructure (PKI), which is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
- Public Key Infrastructure uses a combination of public and private keys to encrypt messages while verifying the ownership of the certificate and key-pair through Certification Authorities.
- Alongside this, Public Key Infrastructure uses a concept known as a Certificate Chain of Trust to provide security and trust with certificates.
- Client certificates contain a Public Key, which anyone or anything with the certificate can use to encrypt a message (data). This is analogous to a password that is given to users or computers to encrypt messages.
- Server certificates contain a Private Key, which only the server should be able to use to decrypt the messages sent with the public key encryption. This is analogous to a password which is used by a server or service to decrypt the messages which were encrypted with the public password.
How are certificates used?
- A common example of public and private keys uses three individuals, Alice, Bob, and Charlie:
Alice wants to send a message to Bob without letting Charlie read it; she encrypts the message with her private key and then encrypts it again with Bob’s public key. Because she used Bob’s public key, the only person who can read the message is the person with Bob’s private key, presumably Bob.
When Bob receives the message and decrypts it with his private key, he then sees something encrypted with Alice’s private key. He can use her public key, which he has, to read the message. And, because only Alice knows her private key, Bob knows that Alice sent the message.
- In that example, how does Bob know that the encrypted message he received came from Alice? It claims that it came from Alice, but how can he trust it? How can Alice trust that a response to her message comes from Bob?
- A somewhat more convoluted example can help illustrate how this works, Alice, Bob, Charlie, and the CA:
Someone presents a certificate to Alice claiming that they are Bob and offers the certificate as proof.
The certificate contains the public key corresponding to what is claimed to be Bob’s private key.
The certificate also identifies a CA known to the Alice that had signed the certificate.
Alice checks the signature in the certificate with the CA using the public key of the CA. The CA confirms that this is Bob’s certificate.
Alice now presents a software challenge to whomever presented the certificate to verify that he or she has access to the private key that was originally generated when the certificate was obtained and hence, he is in fact Bob.
The challenge answered successfully; communication begins with Charlie left out of the loop!
What is a Certification Authority?
- A certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates.
What does a Certification Authority do?
- Certification Authorities are often a service provider or server software which creates, signs, and authenticates certificates. There are several functions and definitions of certification authorities depending on context.
- In terms of the actual certificates themselves: certificate authorities are servers which create and sign certificates. There is more than one kind of certification authority: root, intermediate, issuing. Each plays a role in establishing the chain of trust with certificates.
- In terms of the software creating and signing the certificates: Active Directory Certificate Services, and other similar services or software like Aruba ClearPass, are a collection of software which creates, signs, and authenticates certificates.
- These services are often run with on-premises servers and are connected to a directory service.
- These services contain the root, intermediate, and issuing certificate authorities.
- In terms of who provides the certificates: Certificate Authorities are publicly trusted or internally trusted entities which issue certificates used in applications such as websites or web apps on the internet.
- Certificate Authorities can be an internal department of a company utilizing on-premises software, like Active Directory or Aruba ClearPass, or public companies or organizations such as GoDaddy or Let’s Encrypt.
- These providers can provide multiple kinds of certification services:
- SCEP services or their own API to distribute and sign certificates
- RADIUS services or their own authentication mechanism to authenticate users or computers with certificates
- Certificate signing services which provide TLS/SSL certificates used by websites and applications to encrypt and secure network connections
What is the certificate chain of trust?
- The chain of trust of a certificate chain is an ordered list of certificates containing the client certificate, issuing CA certificate, intermediate CA certificate(s), and the root CA certificate. This certificate chain enables the receiver to verify that the sender and all intermediate certificates are trustworthy.
- Each link of the chain of trust is a well-known and trusted CA. The certificate chain is used to establish trust. A certificate signed by a CA that includes its full chain of trust is trusted more than a certificate signed by itself or missing links in the chain of trust.
- Well-known here means that you can identify who owns it. This can mean an internal CA which you know is maintained by your organization or a publicly trusted CA like GoDaddy.
- Here’s an example showing the concept of the certificate chain of trust:
- A client certificate is issued to a computer. This certificate is provided and signed by the Issuing CA and can be cross-signed by a Cross-Signing CA.
- Both CAs have their own certificate which identifies them as a Certificate Authority.
- The Issuing CA is a certificate authority which provides certificates to clients or other servers for authentication. This CA has a certificate which is signed by an Intermediate CA.
- The Intermediate CA is a certificate authority which provides certificates to Issuing CAs. This CA has a certificate which is signed by a Root CA.
- Sometimes organizations do not distinguish between an Intermediate CA and an Issuing CA, meaning there is one CA which provides both roles rather than two individual CAs.
- The Root CA is a certificate authority which provides certificates to Intermediate CAs. This CA has a self-signed certificate, an aptly named certificate which is signed by itself.
- Root CAs are often used to sign an Intermediate CA certificate, then turned off and not used again until a new Intermediate CA certificate is needed.
- A root CA is the end of the Certificate Chain of Trust.
- A Cross-Signing CA is a 2nd Issuing CA which has a certificate signed by a different Intermediate CA, which in turn was signed by a different root CA. This is used to establish multiple or alternate trust paths.
- Not every certificate is cross signed, however some security frameworks suggest or require cross-signed certificates in specific environments.
- Click below for an example showing the certificate chain of trust for the web certificate used at https://jamf.com:
First, the certificate presented by https://jamf.com once again:
Common Name: *.jamf.com
Subject Alternative Names: *.jamf.com, jamf.com
Valid From: March 31, 2022
Valid To: April 29, 2023
Issuer: Amazon, Amazon
Serial Number: 033beb304fddd18ab9bedf25861df734
Next, the intermediate certificate from Amazon:
Common Name: Amazon
Organization: Amazon
Organization Unit: Server CA 1B
Country: US
Valid From: October 21, 2015
Valid To: October 21, 2040
Issuer: Amazon Root CA 1, Amazon
Serial Number: 067b505c2a6527bc1ebe2da2d19998edb89b2c
Finally, the root certificate from Amazon Root CA 1:
Common Name: Amazon Root CA 1
Organization: Amazon
Country: US
Valid From: May 25, 2015
Valid To: January 16, 2038
Issuer: Amazon Root CA 1, Amazon
Serial Number: 066c9fcf99bf8c0a39e2f0788a43e696365bca
- Take note that each certificate in the chain is issued by the next CA in the chain.
That’s all for part one! Stay tuned to learn more about some of the other technologies surrounding certificates!
