Certificates 101 Quick Start Guide
Article ID: 430417
Updated On:
Products
Issue/Introduction
This article will cover some basic information and troubleshooting steps for Certificates.
Environment
n/a
Cause
n/a
Resolution
What is a Certificate?
There are several different types of Certificates, but for our purposes we are generally referring to an SSL Server Certificate.
- An SSL Server Certificate is basically an Identification Card for a specific Server, it tells the client who the Server is
- A Self-Signed certificate is the server introducing itself, like a stranger. "Hello, I'm the Enforce Server" for example.
- A CA-Signed certificate is like someone else introducing the server. "This is my friend the Enforce Server".
Both Self-Signed and CA-Signed certificates will encrypt the traffic and protect the communication. The difference is the CA-Signed certificate comes from an authority that is trusted, versus the Self-Signed certificate which is the server itself telling you who it is.
Self-Signed: Think of this as a stranger introducing themselves.
CA-Signed: Think of this as a friend introducing you to someone new.
What are Public Keys and Private Keys?
Private Keys -- Confidential Key used to decrypt data. This key should NOT be shared.
Public Keys -- Shared key used to encrypt data, This is the key that is shared with other servers.
Key Pair -- A key pair would be both the private key and public key for the same Certificate.
What is a Certificate Chain?
Certificate Chain -- This is a hierarchical list of certificates that were used to sign the SSL Server Certificate. Think of this like a chain of custody.
Certificate Chain components:
- Root -- This is the originating Certificate, this would typically be the "CA". This is the highest, most trusted certificate. There will only ever be ONE Root Certificate.
- Intermediate -- This is a subordinate Certificate, this will always be signed by a Root Certificate, and is then used to sign SSL Server Certificates. There can be more than one Intermediate Certificate.
- SSL Server -- This Certificate identifies the SSL Server. This can be self-signed, signed by an intermediate, or signed by a root certificate., There should only ever be ONE SSL Server Certificate.
Certificate Extensions and what they mean?
(.cer, .crt, .cert, der) -- These extensions can ONLY carry a Public Key
(.p7b) -- This extension can include the Public Keys and the full certificate chain, but cannot contain the Private Key.
(.p12, .pfx, .pem) -- These extensions can carry Private Keys, Public Keys, and the full certificate chain, and are generally treated as Keystores as opposed to Certificates.
(Other) -- There are other extensions out there, but they are not typically seen or used with DLP.
How to verify a certificate key pair matches?
When verifying a Certificate Key Pair (Public/Private of the same Certificate), you will want to compare the Serial Number, or the Fingerprint of the two Certificates, and they should match.
How to verify a certificate chain?
When verifying a Certificate Chain, each Certificate will have two Identifiers
- AuthorityKeyIdentifier
- SubjectKeyIdentifier
These two Identifiers tell you the hierarchical structure of the key chain which can then be followed.
AuthorityKeyIdentifier: This would be the identifier of a higher level certificate that signed the existing certificate.
SubjectKeyIdentifier: This would be the identifier for a lower level certificate, one that was signed by the existing certificate.
So if we were to look at a Server Certificate, you would notice that this has an AuthorityKeyIdentifier which would match the SubjectKeyIdentifier of the Intermediate Certificate that was used to sign it. You would also note that it does not have a SubjectKeyIdentifier, because a Server Certificate would never be used to sign another certificate.
Let's look at a quick example...
ROOT Certificate:
Serial Number: 55ae2331bf3cd296427ca357c1aa6285
Authority Key Identifier: Does Not Exist (Root is the highest Authority, there is nothing higher to sign it)
Subject Key Identifier: 0000: E8 BC EE DC 03 6D 42 60 11 03 8A D########## 23 .....mB`......m# 0010: 73 AE FF 24
Intermediate Certificate:
Serial Number: 1800000009af37c22edb95635a000000000009
Authority Key Identifier: 0000: E8 BC EE DC 03 6D 42 60 11 03 8A D########### 23 .....mB`......m# 0010: 73 AE FF 24
Subject Key Identifier: 0000: 41 DF A0 1C 4F 95 97 FF 58 34 0A AB 0########## A...O...X4.....U 0010: B1 D6 04 9F
Server Certificate:
Serial Number: 460000001896f3d21037d3d8a7000200000018
Authority Key Identifier: 0000: 41 DF A0 1C 4F 95 97 FF 58 34 0A AB 0########## A...O...X4.....U 0010: B1 D6 04 9F
Subject Key Identifier: Does Not Exist (The Final Certificate is the lowest authority, there is nothing for it to sign)
There are a couple of things for us to note here...
- The Serial Numbers are all unique, unlike the previous request to match certificates, these are all unique certificates and will not match on the Serial Numbers.
- Here we can see that the ROOT Certificate was used to sign the Intermediate Certificate as noted by the matching Blue Identifiers.
- Here we can also see that the Intermediate Certificate was used to sign the Server Certificate as noted by the matching Red Identifiers.
- This is the "Certificate Chain", we can follow that chain from the ROOT Certificate to the Server Certificate
- Here you will also note that the Intermediate Certificate is the only one to have BOTH a SubjectKeyIdentifier, and an AuthorityKeyIdentifier. The AuthorityKeyIdentifier will always point to the ROOT Certificate (or Higher Certificate), while the SubjectKeyIdentifier will always point to the Server Certificate (or Lower Certificate).
How to tell if a certificate is Self-Signed or CA-Signed?
- With a Self-Signed Certificate the Owner and Issuer will match.
Owner: CN=<FQDN>, OU=DLP, O=Symantec, L=Lehi, ST=UT, C=US
Issuer: CN=<FQDN>, OU=DLP, O=Symantec, L=Lehi, ST=UT, C=US
- With a CA-Signed Certificate the Issuer will be updated to the Intermediate Certificate that was used to sign it.
Owner: CN=<FQDN>, OU=DLP, O=Symantec, L=Lehi, ST=UT, C=US
Issuer: CN=<Intermediate>, DC=beyond, DC=com
How to tell if a certificate contains the private key or the public key or both?
There are 3 different types of "EntryType" that you may see in your certificates.
- PrivateKeyEntry: This tells us that it holds a Public Key, Private Key and corresponding Certificate Chain.
- Private Key
- Public Key
- Cert Chain
- TrustedCertEntry: This tells us that the Certificate contains a single public certificate
- Public Key
- SecretKeyEntry: This contains a Symmetric Cryptographic Key, which is not used by DLP, so you should not see this particular EntryType.
- A Symmetric Cryptographic Key
Alias name: tomcat
Creation date: Mar 23, 2026
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
How to query the SSL Server for it's public certificate?
Using #17 from the Certificates.bat script we can query an external SSL Server for it's certificate.
( The certificates.bat script file is part of the article: Example Script to automate keytool commands )
Replace the <SSL Server IP Address> with the IP Address of your target Server. You can use the Enforce Server as an example of what to expect.
Enter in the port to your target SSL Server, in this case we are targeting the Enforce server and will use port 443.
You will then see your Server Certificate returned...
You can now match your Serial Number or Fingerprints to your Server Certificate to confirm the match.
Additional Information
Return to the Certificate's Quick Start Guide
Attachments
Feedback
