In this guide, we’ll go over what X509 certificates are and how they’re used in technology. We also cover the risks involved with certificate-based authentication as it pertains to security on the internet. Lastly, we’ve included a list of resources so that you can continue your research about the topic online!
A “x509 certificate validation” is a process that validates whether or not the certificate is authentic. This process can be done in two ways, either by using the trust store or by using a public key infrastructure (PKI).
Please raise your hand if you have a good knowledge of what an X509 certificate is. Let’s fix that now that we’ve acknowledged no one is raising their hands.
Certificates are a complicated issue that is sometimes misunderstood. This lesson tries to alter that by showcasing PKI certificates, X509 certificate samples, and much more.
You’ll receive an excellent understanding of X509 certificates in this article. By the conclusion, you’ll have a good understanding of how they operate on a high level. You won’t become an expert in one article, but by the conclusion of it, you’ll have a good understanding of the vocabulary.
Managing Certificates using Windows Certificate Manager and PowerShell is a related article.
Protecting Assets with Public and Private Keys
Without addressing keys, any explanation of X509 certificates would be insufficient. When terminology like private and public keys are tossed about, you may have heard of the idea of keys. But what is a key, and what does it have to do with certificates?
To make the relationship clearer, consider the notion of keys in the context of a traditional door lock.
A door key will be included when you buy a new door lock. Because the key is exclusive to that lock, no one else will be able to open it.
Consider the lock to be a public key. The lock on your door may be seen by you, your family, or passers-by after it is placed. Anyone can look at it and even try to unlock it, but they will fail. They’d have to use the one-of-a-kind door key that came with the lock to open it. The private key is the one that comes with the lock.
A key pair is the combination of a private and public key.
Exchange of Secrets
You may conceive of the action of inserting the door key into the lock as key exchange. To open the door, the private key (door key) must be exchanged with the public key (lock).
You will readily give away a public key and retain the secret key to yourself in the cryptography realm. After all, who can open the lock is more important than who can view it (exchange keys).
There are a couple of different ways keys are exchanged called Exchange of Secrets algorithms. Exchange of Secrets algorithms focus on deriving and securely transmitting a unique shared secret.
Two popular Exchange of Secrets algorithms you may have heard of are Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH).
Key Trust
You’d offer the key to someone who needed to enter via the door (or a copy of the original, unique key). You only hand over your key to those you know and trust. The person in possession of the private key (door key) has been entrusted with the responsibility of unlocking the door lock (public key).
Key Usage
The objective of the X509 certificate is defined by the key use, which corresponds to the algorithms used by the certificate. The extended key use (EKU) specifies the public key’s intended uses beyond key usage.
X509 Certificates: “Containers” for Public Keys
What is the relationship between private and public keys and the idea of an X509 certificate? Consider a certificate to be a public key. A certificate is a “enclosure” that contains a public key as well as some additional information about the key, such as who it was issued to, who signed it, and so on. Files are used to keep track of certificates.
Later on, we’ll look at a handful of nice X509 certificate samples.
Have you ever come across a certificate file with the PEM or CER extension? That is a certificate (public keys). Later on, you’ll learn more about these formats.
By definition, a certificate does not have to be a public key. A certificate is defined by the combination of the public key and the related attribute data.
A certificate offers a defined and secure structure for communicating with certain systems, as well as qualities that may be used to verify the trustworthiness of a key pair. The X.509 standards govern how certificates are created, which you’ll learn more about later.
The unique identifier of a certificate is its thumbprint.
Each X509 certificate is designed to be used to identify a single topic. Each public key should be individually recognizable, according to the certificate.
A certificate thumbprint, also known as a fingerprint, is a means of identifying a certificate that isn’t as long as the complete public key. A serial number is technically correct, but you’ll learn more about it when it comes to certifying authorities (CAs). In Windows, the fingerprint is a hash of a DER-encoded certificate.
The wide computing issue of fingerprinting is the notion of identifying a bigger data collection with a smaller unique identifier. Morgan Simonson’s blog delves into the fingerprint in further depth.
Defining Important X509 Certificate Attributes
Not only does every X509 certificate need to have a unique identification, but it also has to answer questions like the ones below. That is exactly what the certificate subject should accomplish.
- Who should this certificate be used by?
- Which organization can be relied upon?
- Which user should this certificate be shown to?
The topic is, without a doubt, the most crucial aspect of a certificate. The topic is supposed to contain qualities that reflect who or what the certificate is given to, as described by X.500. A differentiated name (DN) format is used to express it.
The subject of a certificate is a string value with a matching attribute type. The DN for State or Province, for example, is st. The complete name of the state or province where the subject lives (e.g. ST=California) is stored in this attribute type.
The ITU-T X.520 guidelines describe several attribute types and value formats. RFC 4519 is another resource for particular attribute types and value formatting suggestions.
Because the X509 certification criteria are simply guidelines, many individuals rely on their own judgment when defining a topic. The topic is designed to indicate the last entity you have faith in. How can you trust anything utilizing the supplied public key if the topic does not reflect this?
To put it another way, if you allow numerous users to access a system using the same user identity, you can’t hold any one person responsible for their conduct. This approach muddles the trust paradigm that certificates are supposed to support.
In the picture below, you can see how Windows depicts an X509 certificate and, more especially, the certificate topic.
An example of an X509 certificate
Cryptext.dll is used to see the properties of a certificate.
Alternative Name for the Subject (SAN)
A Subject Key Identifier (SAN) is a certificate extension that enables you to utilize one certificate for numerous topics (SKI). Some of the SANs used by Google are shown in the example below. When you add additional domains to a certificate, you’re basically telling it to trust each topic to use the same private key.
Other than DNS names, a SAN may contain numerous sorts of GeneralNames. To support SANs using GeneralNames, the client must first read the certificate. The majority of customers, such as web browsers, are only concerned with the DNS name SAN.
You can see the SAN below in this An example of an X509 certificate.
In a Windows certificate, the subject alternative name
Some of the SAN properties that Google’s certificate has.
Getting to Know Encoding
We speak with one other in a variety of languages; similarly, computers have their own language. This is a binary language, and multiple encoding techniques are used to make binary more useable for others, much as we would do with English to other languages.
Encoding has a particular function. Encoding converts human-readable extension values into a format that computers can understand. Encoding formats not only make it simpler for computers to store and send X509 certificates, but they also make it possible for humans to read them.
Integers are easy for computers to deal with, and encoding allows you to transform numerical values to alphabetic values or even binary blobs. Working with computers necessitates this translation, and certificates depend on encoding to effectively send information to computers. The standards for accomplishing such conversions are defined by encoding formats.
- The Abstract Syntax Notation (ASN.1) The serialization format for each of the fields in certificates is one standard.
- ASCII – The American Standard Code for Information Interchange (ASCII) assigns a binary value to each of the computer control and printable characters that are used in most human-readable communications.
- Base64 is a character encoding technique for binary data inside the ASCII character set. These are the certificates where you can read “BEGIN CERTIFICATE” or other reference text if you open them in a text editor.
- DER – Distinguished Encoding Rules (DER) specifies a different encoding method for ASN.1 data in the form of consecutive octets. The encoded output is not visible as ASCII, which is an essential factor with DER.
As you can see below, the encoding algorithms vary. Notice how the certificate.crt file begins with ——-BEGIN CERTIFICATE——-, then goes through a series of random characters and numbers before ending with ——-END CERTIFICATE——-. All of the characters are legible by humans. The first certificate is encoded in Base64.
Take a look at the certificate’s second sample now. cer is a certificate file. The content of this file differs significantly from that of the Base64 certificate. This X509 certificate has been DER-encoded.
In PowerShell, a DER-encoded certificate is shown.
The difference between files encoded in Base64 and those encoded in DER.
Understanding the Different Types of X509 Certificate Files
It’s important to remember that a certificate is nothing more than a public key with some information stored as a file. Many different sorts of files reflecting various types of certificates may be found in the wild. The file extension distinguishes each kind of file. When we talk about a KEY file, we’re talking about the file extension.
You’ll find all of the common sorts of certificates identified by their file extension, as well as their function, listed here.
Several references to PKCS may be found in the list below. The Public Key Cryptography Standards, or PKCS, are a collection of guidelines that describe how different types of certificates are generated. Check out this useful Wikipedia page for further details.
- PFX – PFX files are most typically encountered in a Windows environment, although they are a standard format that may be used on any operating system. A certificate, the public key and extensions, and a private key encrypted with a password are all included in PFX files. The PKCS #12 standard specifies PFX.
- P12 – P12 is specified by the PKCS #12 standard, much as PFX. Although both file formats reflect the same format in current cryptographic implementations, PKCS #12 is the formal successor to the PFX format.
- P7B — An ASN.1 container containing public keys for all layers of a certificate authority chain, as explained below. A PKCS #7 file is used to distribute numerous public keys in a private PKI and is often used to manually build up a trust with CAs.
- P7C – The P7C file type is functionally identical to the P7B file type, however it is merely another common extension for a PKCS #7 file.
- A DER file is a public key that has been DER-encoded.
- CER — A DER or Base64 encoded public key. A CER file is commonly encoded using DER.
- CRT – A CRT is often Base64 encoded, however this is not always the case.
- KEY – A KEY file, whether encrypted or not, is usually a Base64 encoded private key.
- PEM – A reference to a Base64 encoded certificate; although a single PEM file might include several keys, it is typically assumed that the PEM file contains a private key. A PEM Base64 encoded private key file, either encrypted or unencrypted, is the most popular format.
- PKCS #10 defines a CSR, which is used to submit a public key to a CA to be signed and issued extra fields such as a serial number. In most circumstances, a CSR will include the request’s ASN.1 structure encoded in Base64.
- REQ – A Windows command that specifies the enrollment policy parameters that are utilized to generate the CSR.
- CRL – A certificate revocation list (CRL) is a file that lists the certificates that have been revoked by a CA, their revocation status, and the cause for the revocation.
The X509 Cert Ecosystem is a public key infrastructure (PKI) solution.
Remember how someone was holding the door key to a door lock earlier? You only have one door in such situation. But what if you find yourself unexpectedly in charge of dozens or hundreds of apartments? Keeping track of all of those door keys is going to be a nightmare!
Furthermore, residents will not remain in that unit indefinitely. Some individuals will retain the key or create illegal copies of it. To prohibit entry, you’ll need to replace the door locks. You’ve lost faith in the previous tenants.
How do you manage hundreds of units with renters coming in and out all the time? A Public Key Infrastructure is the solution (PKI).
PKI is a role-based, policy-based, and procedure-based environment for managing public keys. To distribute, utilize, maintain, and delete X509 certificates, PKI represents an all-encompassing collection of many distinct areas of interest. It’s basically everything you’ll need to handle and maintain certificates at a large scale.
In the sections that follow, we’ll dissect several of the most popular components of a PKI and explain their functions.
Your Parents are Certificate Authorities (CAs).
The principle of maintaining trust is at the heart of a PKI. However, since managing hundreds or thousands of trust relationships directly isn’t cost-effective, you’ll need a mediator.
You’ll need a third-party who has previously been recommended by the first party. Certification authorities (CAs) are third-party mediators recognized by an Authority Key Identifiers (AKI) extension obtained from the public key used to sign the certificate.
Consider yourself as an X509 certificate when you were a kid. Your parents probably taught you not to trust strangers. But what if your trusted parents introduce you to a stranger and tell you it’s OK to trust them? You’d probably go along with it and put your faith in the stranger. After all, if your parents have faith in them, so should you.
Your parents are played by a CA. Your parents (a CA) put their confidence in you and introduce you to strangers. They do it by signing the stranger’s public key, indicating that they are trustworthy.
A CA’s principal function is to serve as a trustworthy mediator.
Creating Trust with X509 Certificates
A CA establishes confidence between indirect parties by being a well-known trustworthy entity. A CA “issues” certificates to establish confidence between parties. When we say that a CA producing a certificate, we actually mean that the CA is checking the required extensions and attaching CA-generated extensions to build the certificate.
When a CA produces an X509 certificate, it will digitally sign the certificate’s public key with its own private key. A CA marks a certificate in such a manner that everyone knows it trusts this public key via the signing procedure. DocuSign has a fantastic diagram that gives a decent summary of this particular idea.
The serial number for each certificate is another example of a CA-generated extension, and each serial number must be unique for that particular CA, according to the RFC design standards.
The harmful use of PKIs with malware is an example of inadvertent trust in contemporary news. Where the malware’s designers acquired genuine certificates that are implicitly accepted by most systems, making it more difficult for your systems to recognize the malware files as malicious.
Removing Trust from X509 Certificates
The CA is also in charge of cancelling X509 certificates that are no longer valid. The CA adds these revocations to a Certificate Revocation List (CRL). Instead of waiting for a certificate’s validity period to expire, CAs may use revocation to actively invalidate it.
For certificates to work as intended, they need to have a high level of trust. Points of Distribution help to ensure confidence by giving a reference point where you may get the issuer’s certificate and revocation lists and compare them to the certificate you’re using.
The techniques and locations for obtaining CRLs are provided by a CRL Distribution Point (CDP). CRL updates are a passive revocation validation mechanism that pulls updates at predetermined intervals. By keeping CRL caches, the Online Certificate Status Protocol (OCSP) actively asks the revocation status of a given certificate.
Though revocation validation through CRLs or OCSP is possible, it must be supported and enforced by the client, which is not always the case.
Tiering
A PKI may be composed of numerous CAs or a single CA, which are referred to as tiers.
Chaining X509 Certificates
As you’ve seen, trust is a crucial consideration when utilizing certificates. A certificate issued by a trustworthy CA must be trusted or validated by all parties involved.
The United States Federal PKI public papers are an excellent illustration of how this scales. These are excellent resources for sustaining an inter-organizational trust relationship via the use of CAs.
Signing X509 Certificates
The term “certificate signing” is often used, but what precisely does it imply? Certificates are all about trust, as you’ve previously learnt. A CA signs an X509 certificate to create trust. When you sign a certificate, you give it a unique cryptographic hash that tells everyone who reads it that they can trust it. It was signed by a reputable certification authority.
CAs issue certificates in a PKI hierarchy, but where those certificates are utilized depends on the kind of CA that signs them.
When a PKI has just one CA, that CA is the root. Because there is no other CA, that CA must create its own self-signed certificate. Following that, the CA provides certificates that are signed by its own certificate.
If a PKI contains more than one CA, a root CA or an intermediate CA that links back to the root CA signs all CAs.
Self-signed certificates are created when a device utilizes the same private key that matches to the public key while creating an X509 certificate. You may, however, ask a CA to sign your certificate with its own private key.
Algorithms for Signatures
Algorithms for Signatures focus on validating the authenticity of a message from a remote peer. A digital signature is a message digest from a hashing function encrypted with the senders private key. The recipient decrypts the digital signature using a copy of the sender’s public key. The recipient can then compare the digest of the received message against the one decrypted from the digital signature. When the digests match, the authenticity of the message is valid.
Asymmetric encryption is the ability to generate cipher text without the use of a previously known secret. The combination of a Exchange of Secrets algorithm with a signature algorithm is the foundation of asymmetric encryption.
The most common digital signature algorithms are listed below.
- Rivest–Shamir–Adleman is a trio consisting of Rivest, Shamir, and Adleman (RSA)
- Algorithm for Digital Signatures (DSA)
- DSA with Elliptic Curve (ECDSA)
Requests for Certificate Signing (CSRs)
Certificate Signing Requests (CSR) are used by issuing CAs to enable clients to submit public keys for issuance. Based on the defined issuance rules, a CA accepts a CSR and issues signed X509 certs. In other words, trusting a CA involves trusting the public keys it signs.
Hashing
Hashing is a complicated subject, and I won’t even attempt to cover it in this piece. On their YouTube channel, the Computerphile team offers a solid summary. Hashing is concerned with taking an input item and producing a unique output hash for it. A digest is the name for the output hash. Changing the input item in the tiniest manner will result in a completely different and unrelated digest.
Secure Hash Algorithm (SHA) 2 algorithms will be used in modern implementations. SHA 2 refers to the algorithms SHA 256, SHA 384, and SHA 512.
A list of common hashing algorithms may be found below.
- SHA 256
- SHA 384
- SHA 512
- MD 5 (Message Digest)
Policy on Certificates
The certificate policy (CP) extension provides a reference to the CA’s current policies for the supplied PKI and should be aligned as a Certification Practice Statement (CPS) describing the organization’s policy for maintaining the given PKI.
Points of Distribution
Authority Information Access is another sort of distribution point mentioned in certificates (AIA). These AIAs provide the procedures and places for obtaining copies of the certificate issuer’s information, which is most typically the issuing CA’s public key.
Summary
When you’re given a question like the one at the beginning of this article, you should feel more at ease raising your hand slowly. In all honesty, I hope this post has shed some light on the intricacies of X509 certificates and Windows’ implementation of these standards. While assisting you in understanding some of the fundamental components that will aid you in dealing with certificates in the future.
At least now, when someone requests for your certificate’s public key, you may indicate whether they want it DER or Base64 encoded, and because they won’t know, you’ll give them both anyway.
Additional Reading
The “x509 certificate format” is a public key cryptography standard that allows for the secure transmission of information. This article will cover what an x509 certificate is, how they are formatted, and their use in everyday life.
Related Tags
- x509 certificate decoder
- x 509 certificates for dummies
- x509 certificate generator
- x509 certificate extensions
- what does an x.509 certificate look like
