Hopefully non-technical and humorous way of looking at SSL certificates, a broad look at what they are, and how to identify them...   (this will get updated along the way..)

Certificates are fairly easy to understand, if you don't let the intimidating word "cryptography" get into your head, or all the techno-jargon confuse you (trust me, so easy to do..)

Certificate Authorities

To start .. there are a lot of gears that make up the certificate machine or process.  There are roughly about 100+ companies that are called "certificate authorities¹" or CAs,  but there are really only a handful that considered major players (IdenTrust, DigiCert, Sectigo (Comodo Cybersecurity), Let's Encrypt, GoDaddy, and GlobalSign) and they all are constantly playing leap-frog in regard to keeping up with the crooks and trying to out-do-each-other.    Each of the companies provide the ability to "certificate authority", also known as the "root" or place you can ask if a certificate is valid and can be trusted.   Each CA validates all their customers with verifiable information and use that information to provide a level of trust to others who are asking them "so.. is this site trustworthy?" or "Is this company who they who they say they are?"

There is no "central" company or CA, only a governing committee² that certificate authorities must gain membership to to become a trusted provider of cryptographic technologies such as SSL certificates. 

One such certificate authority is called Sectigo, who is authorized to provide issuance of InCommon Certificates and Comodo Certificates, among a handful of others types (code signing, user certificate, etc..) to the University of Texas.  These companies (like Sectigo) are literally just an the folks that run the servers that take all the cryptographic information within "Certificate Signing Requests" and generate SSL certificates.  They offer various methods to accept CSRs and issue certificates (ACME, web GUI, REST API, and many others).. all to do the exact same thing.. just with different approaches.

What is a certificate? 

A certificate contains a whole slew of fields and information that is used by various servers (like web, application, or other communication servers) to provide identity validation and secure communication between client and server.   When a client connects to a server – the certificate (public part) is sent as part of the negotiation – that provides all the information necessary to validate themselves.  The client then communicates transparently (you really never see this, unless you are really looking) talks with the various intermediary and root (certificate authority) to validate the certificate.  The good or bad news is delivered to the client and the connection is either dropped like a bad habit or earns their little green lock that says they are trusted.  The client and server talk back and forth to figure out (probably decoder rings) how to securely talk with each other and then start talking in secret code that only the client and server know how to translate.

What is in it?

So certificates are just the "data" within a file, not the files themselves.   Certificate files are usually found hanging around with two other badge wearing files that go by "Certificate Signing Request" and "Private Key".   The most common format that the data is found is PEM (which has a very confusion acronym expansion of “Privacy-Enhanced Mail”, because it was also used transferring files over email.) You might even hear it as certificate files being "encoded" in PEM or PEMCO format, which all mean the same thing. There are many other formats that certificate data can be found in, required by a few proprietary services, such as DER, PKCS#7, P7B, PKCS#12, PFX, etc.. If you ever come across one of these format and need PEM, visit (DC) Certificate Format ConversionPreview to learn how to convert between one format and another, and hopefully you will never have to go the other way!

Certificate files (and their friends) are just text files. It is the text within the file that counts, and when they are in PEM format, there are tell-tale text that shows up the very beginning and the very end of the file that will tell which certificate part you are looking at.

Certificate Part

Certificate Part
Open	A certificate will always have "-----BEGIN CERTIFICATE-----" at the top or beginning and "-----END CERTIFICATE-----" at the end or bottom.
Open	A private key, will always have "-----BEGIN PRIVATE KEY-----" at the top or beginning and "-----END PRIVATE KEY-----" at the end or bottom.
Open	A certificate signing request (CSR), will always have "-----BEGIN CERTIFICATE REQUEST-----" at the top or beginning and "-----END CERTIFICATE REQUEST-----" at the end or bottom.

Story Time (Analogy)

Open

So, to use an analogy to help better explain things, think of the wild world of say modern painted canvas art.  Each uniquely painted canvas can be analogous to a certificate, certificate signing request, or private key.   In a perfect world, the art usually has tag or the frame will

Open

indicate what type it is. Unless you are an art expert, there is absolutely no way you can know what the certificate represents (URL or other information) by just looking at it (various colors, shapes, and swirls, etc..)  You have to have a "decoder" (or art expert) to decode the PEM format (or ..to know what style, period, and author to know what the "painting" represents).

Open

One thing is for sure, never count on the filenames (which can be anything, example: xt27sf7sjs.zas), or the file extensions (again, anything, example: *.ccc, *.abc), to identify the type or what the certificate represents.  In this analogy, there are only three types of frames available, so you can immediately tell what the PEMCO format is representing: certificate, certificate signing request, or private key (see above). Now you know what “decoder” to use, so you can ask your art-expert or decoder to tell you what the painting represents.

Decoders

(deciphering the certificate)

Decoders for "Certificates":

• https://certlogik.com/decoder/

• https://comodosslstore.com/ssltools/cert-decoder.php

Decoders for "Certificate Signing Requests":

• https://www.sslchecker.com/csr/decode

• https://certlogik.com/decoder/

Decoders for "Private Keys":

The following local commands using the openssl commands from the OpenSSL package/module, you can decode a private key to learn more about it.
(Installed by default on Unix/Linux, can be downloaded and installed for just about every platform) 

openssl rsa -in <encrypted_private.key> -out <decrypted_private.key>
openssl rsa -in <private.key> -text -noout

What if something goes wrong?

Who is at fault?  Who do I ask for help from?  Who can I blame?

First things first:  Know exactly where the process is failing.  

1. Verify that all three components (the certificate, the certificate signing request, or the private key) of a certificate bundle are valid. 

   1. Decode the certificate!  Check all fields to make sure it matches the FQDN, has a valid expiration date, etc. 

   2. Using the following openssl commands, obtain the “modulus“ and compare them.

      openssl x509 -noout -modulus -in certificate_filename.cer | openssl md5 openssl rsa -noout -modulus -in private_key_filename.key | openssl md5

   3. Review the output:

      ❯ openssl rsa -noout -modulus -in test.key | openssl md5 (stdin)= c66d5ade7c316f123ebed344506d35aa ❯ openssl x509 -noout -modulus -in test.cer | openssl md5 (stdin)= c66d5ade7c316f123ebed344506d35aa

   4. Compare the output from both commands.  If they match, then the private key and certificate can validate each other and are a pair.

       

2. Make sure that filenames match the required naming found in the configuration for a service.  Mismatched filenames can look like other issues. 

3. Make sure you submitted a certificate signing request that was signed by the correct private key. 

   1. Using the following openssl commands, obtain the “modulus“ and compare them.

      openssl rsa -noout -modulus -in <private key filename> | openssl md5 openssl req -noout -modulus -in <CSR filename> | openssl md5

   2. Review the output:

      ❯ openssl rsa -noout -modulus -in test2.key | openssl md5 (stdin)= 4506b36ccc9cff2d0f90e5c1f91e1cfd ❯ openssl req -noout -modulus -in test2.csr | openssl md5 (stdin)= 4506b36ccc9cff2d0f90e5c1f91e1cfd

      Compare the output from both commands.  If the private key is valid and was used to sign the certificate signing request, the output will match.

       

4. You have a valid private key and certificate signing request, but can not get a certificate?

   1. Has the process of submitting the CSR (various methods) and obtaining a certificate broken?  If no certificate is being issued, there is usually an associate error code.  Submit that to the help desk, and they will help you further.  It literally could be the result of local problems, network connectivity, certificate authority maintenance or service issues, and many more.

   2. You have downloaded the certificate, but it does not appear to be right?

      • Is it in the wrong format?

      • Can you download the certificate in a PEM or PEMCO format?

      • If it is in a odd format or not the format your service requires, you can refer to (DC) Certificate Format ConversionPreview to convert it to the appropriate format.
         

5. Still having issues?  None of the above has helped?   Check out: Digital Certificates and the associate (DC) Knowledgebase (KB).

Conclusion

What have we learned?   Never trust a wolf in sheep clothing, aka file names or extensions to tell you what is what, and what the certificate is protecting, has a valid expiration date, and more.    Certificate filename and extension can be anything and many times are never the same from one type of system to another, and can be renamed freely to meet the requirements of your server, configuration or environment.   Filenames usually are most helpful with a descriptive name (once you know what it is...) and one of the pseudo-standard file extensions:  *.cer or *.crt for Certificate, *.csr for Certificate Signing Request, and *.key or *.pk for Private key.

You always need to dig deeper to learn which file is one of the three types of certificate related content:  the certificate, the certificate signing request, or the private key.   View the contents of the file and look for the keywords located in the first and last lines of the content.    Use a online or local decoder to learn what the certificate is protecting, has a valid expiration date, and more. 

Also to keep in mind ... certificates now-a-days are like toilet paper (not painted art) and can be generated, deleted, revoked, and regenerated VERY QUICKLY with NO COST (to "us" - the staff of UT Austin).  So if you think a certificate has been compromised or damaged, you need only to create a new private key and CSR and submit the CSR for a certificate.. and viola .. you have a new certificate.    

This is so much the case in recent days due to the fact that certificates currently have a 1-year/398 day maximum expiration period.  There is talk about even shorting the time period that a certificate is valid, thus it really important for services and system administrators to have a plan to implement some sort of automation to ensure that manual and tedious task of maintaining valid certificates are not an issue and happen automatically with no or very little intervention from a sysadmin.  Check out:  Digital Certificates and the associate (DC) Knowledgebase (KB) for more information.

Footnotes