PKI & Digital Signatures in CISSP Domain 3: A Deep Dive

To Download the FREE PDF of MindMaps

Your information will remain 100% private. Unsubscribe with 1 click.



Hey, I’m Rob Witcher, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major topics related to digital certificates, digital signatures, Public Key Infrastructures and key management in Domain 3, to understand how they interrelate, and to guide your studies.

This is the seventh of 9 videos for domain 3. I have included links to the other MindMap videos in the description below.

In the last video, video 6 in domain 3, we started our voyage through the wonders of cryptography. Lets now delve a little deeper in what cryptography enables us to do with digital signatures and digital certificates, how we can establish trust on an untrusted network like the internet via Public Key Infrastructures, and how we must carefully manage encryption keys.

Digital Signatures

We’ll begin with digital signatures. Digital signatures provide three major and very useful services: Integrity, Authenticity and Non-repudiation.

We create and use digital signatures in all sorts of different places:

  • Sending emails and using digital signatures to verify the integrity, authenticity and non-repudiation of a message
  • Code signing – so that we can verify that an update we just downloaded for our iPhone actually came from Apple and wasn’t modified in transit
  • Signing legal documents, such as PDFs, allowing others to verify who specifically signed the document

Lets now go through the services that digital signatures provide in a wee bit more detail


Integrity means that we can tell if a message or a file has been changed or modified in any way.


Authenticity means that we can know who the message came from. We know who the sender is.


And Non-repudiation means someone cannot deny the validity of something. There are two scenarios in which we can achieve non-repudiation with digital signatures.


Non-repudiation of origin means the sender cannot deny that they sent exactly the message that was received


And non-repudiation of delivery means the receiver cannot deny that they received the exact message that was sent.

Digital Certificates

Now on to Digital Certificates. Digital certificates are used to verify the owner of a public key. You often need someone’s public key to securely communicate with them and they need yours. You could just exchange public keys across the internet. You could send me your public key, but anyone could intercept and modify the keys, or more likely, swap out your key for theirs. And the major problem is I would have no idea this happened. I would have no idea that the key I received actually belongs to some sketchy character out there on the internet and not you. This is a major problem.

You cannot, for instance, securely communicate with your online bank unless you know you have your banks public key.

Verify the owner of a Public Key

Digital certificates solve this problem. Digital certificates allow us to verify who a public key belongs to. A couple of the important bits of information that a digital certificate contains is the name of the owner of the public key, and a copy of their public key. Thus, allowing us to verify who a public key belongs to.

I’m obviously glossing over a lot of the specifics of how this works. If you want to dig a little deeper, I created a more detailed video on digital certificates which I’ve linked to in the description below.


Digital certificates can be created by loads of different organizations:

  • You can get a digital certificate from one of the big Certificate Authorities such as Comodo, Symantec, Digicert or Entrust, and everyone in the world will trust that certificate
  • You can get a digital certificate from say your company, and that certificate will only be trusted within your company
  • You can even create your own self-signed certificate that no one, but you, will trust

Because certificates can be created by so many different entities in so many different situations, we need a standard to make sure all these certificates are interoperable. That standard is X.509.


Certificate Authorities will typically issue a certificate that is valid for one to two years. An expiry date will be noted in the digital certificate itself and when that expiry date has been reached, or just before it, a new digital certificate will need to be created. This is replacement. The regular replacement of expired certificates.

And you can easily see when a certificate needs to be replaced based on the expiry date noted in a Digital Certificate itself.


Revocation is an entirely different matter. Digital Certificates contain a copy of a public key. A public key is one key in a key pair – the other key being the associated PRIVATE key. The public key can be shared with anyone and everyone. The associated private key MUST remain private. If the associated private key is compromised, you can never trust any communications from that entity. This is where certificate revocation comes into play.

If for instance your private key has been compromised, then you need to immediately tell everyone not to trust your associated public key. The way you do this is by contacting your certificate authority and asking them to revoke your digital certificate. The CA maintains a list of all the revoked certificates. Before you trust the public key in any digital certificate you should first check with the CA to see if the certificate has been revoked. If the certificate has been revoked, then you should absolutely not trust the public key contained within it.

How do you check with a CA to see if a certificate has been revoked? Or more specifically, how would the software you use, like your web browser, check for you? There are two protocols.


CRL - Certificate Revocation List is the older less efficient way of checking with a CA to see if certificate has been revoked. A client asks the CA if a certificate has been revoked, and the CA responds by sending a large file which lists all the certificates that have ever been revoked and then the client needs to search through the giant list to see if the certificate of interest has been revoked or not. Lots of overhead.


OCSP - Online Certificate Status Protocol is a much newer and more efficient protocol. The Client queries the CA for the revocation status of a specific certificate and the CA responds: it’s been revoked you should run screaming OR nope all good, live long and prosper.

I may have just taken some comedic license there with exactly how the CA responds to OCSP queries


The final bit we’ll talk about related to digital certificates: certificate pinning.

The idea here is that if we download a digital certificate from say a server, there is a very small but non-zero chance that an attacker could intercept that certificate and forward on a spoofed certificate. Google DigiNotar if you want to read about a real-world example of where this has happened!

So, if we are worried about being sent a spoofed certificate we can instead trust the local certificate we have on our system – a certificate we have pinned. How did we get this local certificate? The less secure way is to pin the first certificate you receive from a server, the more secure way is to use a piece of software that comes with pre-installed pinned certificates.

Significant issues have actually been found with pinning and it has been superseded with Certificate Transparency – but now you know about pinning in case you see it on the exam.


All right lets now talk about how we create the whole infrastructure that allows us to trust users and systems across an entirely untrustworthy environment like the internet.

Public Key Infrastructures is the broad set of the roles, policies, procedures, hardware, and software that is used to create, distribute, use, store, replace and revoke digital certificates – and we do all this so that we can use digital certificates to bind a public key to it’s owner and trust who or what we are communicating with.

Certificate Authority (Root of Trust)

All the trust in a PKI is ultimately rooted in the certificate authority, which is why the CA is often referred to as the Root of Trust. The CA uses its private key to encrypt some data including the name of the owner and their public key to create a digital certificate. Because the CA is the only entity in the world that has their private key, no one can modify the certificates the CA creates or create spoofed certificates that look like they come from the CA but didn’t.

And on the flip side, anyone can decrypt a digital certificate that has been created by one of the big public CAs because everyone has their public key. How do we all have the big CAs public keys? They come pre-installed in our browsers, like Firefox, Chrome or Safari.

Registration Authority

Before a CA will create a digital certificate for you, they first need to proof your identity, to confirm you are who you say you are.

The role within the CA that performs the identity proofing is known as the RA – the Registration Authority.

Intermediate / Issuing CA

Now I mentioned that the Certificate Authority creates a digital certificate by encrypting a bit of data including the name of the owner and their public key with the CAs private key. That is an oversimplification and in fact a bad idea. If the CA was encrypting new certificates using it’s private key that would mean that private key would have to be on a system that is online – connected to the wildly untrustworthy internet.

And if the CAs private key is ever compromised this whole entire system goes up in flames. No one can trust anyone. It is the end of the world! Okay yes, that is a bit overly dramatic, but it is REALLY bad if the CA’s private key is compromised. You can’t trust any digital certificate the CA has ever issued and therefore you can’t trust a whole lot of entities.

To avoid this major risk, of the CAs private key being stolen, the private key is in a system that is offline, air gaped, not connected to the internet, in a giant vault, within another vault, surrounded by hungry dogs, underneath a mount, in an undisclosed location.

Alright so if the root private key is offline how do certificates get signed and created? The CA’s private key is used to sign intermediate certificates, which can then be used to sign issuing certificates, and those issuing certificates can then be used to sign entity certificates- the certificates that we pay a CA to make for us.

This is often referred to as the chain the trust. You can follow the chain of trust back up to verify that ultimately it was the CAs private key that was used to sign the first certificate in the chain.

So if you get a question asking you which role in the CA issues certificates, the perfect answer is the Issuing CA

Certificate DB (Revocation List)

The CA needs to maintain a list of all the certificates they have ever issued and which have been revoked. This data is stored in the Certificate DB. Each CA maintains their own Certificate DB.

Certificate Store (Local)

End-point systems, like our desktops, laptops and mobile phones, need to securely store our private keys and any other keys and certificates we might need – like the big CAs public keys. The Certificate Store is the local secure storage place for all such keys. Every end-point device will have its own little certificate store.

Key Management

Lets now talk in a little more detail about keys, and why we need to put so much focus and effort into key management. There is an expression I like: the hardest part of security is cryptography and the hardest part of cryptography is key management. Why is key management so critically important?

Kerchhoff’s Principle

Our guy Kerckhoffs summed it up nicely in 1883 which his principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. An attacker can know the algorithm being used, the initialization vector, can have access to the ciphertext – the attacker can know all of this and the information will remain secure so long as the key is kept secret.

This obviously implies that we need to do a very good and very secure job of generating keys, distributing keys, storing keys, rotating keys, disposing of keys and even recovering keys.

So, lets talk through each of these key management activities


Key generation or key creation is all about creating new symmetric or asymmetric key pairs. What is of critical importance is that each new key must be randomly selected out of the entire key space to avoid the plague of cryptography: patterns.


Key distribution is focused on securely transmitting shiny new keys to whoever may need them and no one else.

Diffie-Hellmann, Out-of-band, Hybrid

A few options to know about for key distribution: You could use the Diffie-Hellmann key exchange protocol which uses asymmetric cryptographic techniques to generate the same key for two people without sending the key itself.

You could use out-of-band, which means sending the keys through some other communications channel. You could write out the key and post it in a letter, send it via carrier pigeon or perhaps just call someone and read them a string of 256 ones and zeroes. That’d be fun for everyone involved.

Or more realistically, and much more commonly used, you could use hybrid cryptography. You could encrypt the symmetric key that you need to send to say Alice, with Alice’s public key. You could then send this cyphertext over to Alice and only she could decrypt the ciphertext with her Private key.

We call this hybrid cryptography because you are distributing / sending a symmetric key using asymmetric cryptography, and then once the receiver has securely received the symmetric key you can switch over to symmetric cryptography to encrypt and decrypt lots of data quickly and efficiently. This is exactly how a super popular protocol like TLS works.


When keys have been created and or received they need to be stored in an extremely secure location. There are two pieces of hardware that are purpose built to securely store encryption keys


TPM – trusted platform modules, are little tiny computer chips that are built into end-point devices like a desktop, laptop, or mobile phone, and TPM modules are designed to very securely store encryption keys. A TPM module is required if you want to have whole drive encryption.

HSMs, Hardware Security Modules, are typically external standalone devices that are used to both securely store encryption keys and to act as cryptographic accelerators to for example: quickly and efficiently perform encryption and decryption and verify digital signatures


It is a good idea to periodically change encryption keys. This is often referred to as key rotation, rotating to a new symmetric key or asymmetric key pair. How often encryption keys are rotated is entirely dependent on the value of the data being protected, and the risk of keys being compromised, among other factors.


Sometimes we need to securely destroy every single copy of a key. Defensibly destroy the encryption keys.


Crypto-shredding, Key Destruction

One reason we might want to destroy every single copy of a key is so that we can crypto-shred some data. The idea of crypto shredding is to securely destroy data by destroying the encryption keys used to encrypt the data. If all of the data you want to crypto shred has been encrypted with an excellent algorithm, like AES, and you then destroy every single copy of the key used to encrypt the data – then the data has been crypto shredded – rendered unrecoverable and essentially, therefore destroyed.


Sometimes we may need to recover a lost key, and there are a few different ways we can recover keys

Split Knowledge, Dual Control, Key Escrow

Split Knowledge – split the knowledge of the key up amongst two or more people. In order to recover the key these folks need to get together and combine each of their bits of knowledge to recover the complete key.

Dual Control – two or more people need to perform some action to recover the key. I always think about how they launch a nuclear missile. Two people have to turn their own keys at the same time. Same sorta idea with dual control – in order to recover the key two people have to do something together to recover the key

Key Escrow – a copy of the encryption key is stored, kept is escrow, with a trusted third party. If you need to recover the key you ask for a copy of the key stored with the trusted third party.


And that is an overview of digital certificates, digital signatures, PKI and key management within Domain 3, covering the most critical concepts to know for the exam.

In the next video we will talk about cryptanalysis and how we try to break all of this.

If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.

I will provide links to the other MindMap videos in the description below.

Thanks very much for watching! And all the best in your studies!

Image of a purple ad - Destination Certification