The Packet Blog

I feel that it’s something many people don’t fully grasp until they’re forced to try [and fail] to implement it a few times. Though, that’s likely the case for most topics you encounter in IT. I’m writing this blog to both solidify some things I’ve picked up and share key points of understanding. This is by no means a definitive explanation of the technology-but rather how I interpreted it.

In the world of SSL/TLS, Certificates are a asymmetric key-pair (analogous to a lock and key, except the roles are reversible and exclusive to each key in the pair) with additional fields to designate their purpose and to either prove the validity [signature/integrity] of an entity or protect communication by means of encryption. One key is a referred to as the Private key, and through some complicated functions, a computer can output another Public key that is mathematically tied to the private key.

Each key can encrypt data, but only the other key can decrypt it. Some applications will negotiate a symmetrically-encrypted (PSK-esque) session after the initial handshake period to reduce overhead, since asymmetric encryption is a very mathematically intensive process. The asymmetry of these keys means that a server can hand out a key (called the public key, quite literally) for a device to use when communicating with it, but only the server can decrypt the contents using its private key. This private key is critical in this process to prevent other devices from listening in on an internet-conversation. When using the word certificate, it can be helpful to transpose it with key-pair, at least in my mind, so that I remember what’s actually happening under the hood. This technology is utilized continuously by websites, applications, servers, etc. For example, the lock icon that designates the use of HTTPS on a website at the top is your browser’s way of ensuring the use of a certificate key-pair for encrypting and protecting your connection to this blog.

x.509 Certificates are the main standard used for communications and are the template used for tacking on extra fields. These fields are useful for specifying the purpose of the key-pair, in contrast with it just being a plain key. These fields let you define details about who generated it, what it’s securing (such as the URL or IP of a website), and how it should be used.

All certificate key-pairs are technically generated out of thin air in the sense that they do not have to come from a specific source and can be created on any computer. If the whole purpose of this technology is to protect your data and build a system of trust around your internet communications, then that begs the question of how we can trust a certificate if it can be created on anybody’s machine… The mechanism by which we trust one key-pair versus another is called a Certificate Chain of Trust. This is made possible using a hierarchal structure of “signing” one key with another key. This structure is also referred to as PKI or Public Key Infrastructure.

Certificate Authorities are the “root” of this chain of trust and are always self-signed certificates; since they are/would be the first certificate, there’s nothing to prove their validity. Technically, any certificate can sign any other certificate, but what makes that signature valid is whether or not that signature is already trusted by the devices utilizing them. At this point it’s important to understand that most computers come with a pre-populated list of Trusted Root Certificate Authorities that determine which of these chains (and any certificate that they sign) are trusted for the purposes that they claim [in their extensions]. This list is kept up to date through regular software updates. This is the distinction behind public Certificate Authorities and private Certificate Authorities. Private CA’s are any certificate chain that are generated and maintained internally to an organization as opposed to widely trusted on the internet via software updates and pre-populated lists.

When you go to any “Authority” to give you a web certificate, such as Godaddy, you are technically paying to have them to generate or sign a certificate with their publicly trusted authority. The certificate that you download from their website would have the appropriate extensions added to it that define your website’s URL and the purpose of that key-pair, which is to encrypt communication between the client and the server hosting the site. Alternatively, you could generate your own Root CA and use that to sign your ‘web’ certificate that is identical to the one from Godaddy (same extensions). The only difference between the one from them and the certificate chain you built yourself is that yours won’t be trusted by any devices by default. In order to use an entirely ‘self-generated (and signed)’ certificate chain, you have to manually tell the devices to trust it. Simply, you must install the Root CA on those computers and put them in the same list where the Public ones go. On a windows machine, this can be viewed under the certmgr.msc console.

When a certificate needs to be trusted, what’s actually happening is that the public key (and the extensions associated with it) is bundled together and provided to a certificate authority (public or private) for signing in a form called a Certificate Signing Request [.csr]. If you recall, the public key is what is handed out to devices that want to communicate with a server, so it’s also the key that will contain any information relating to its purpose [x.509 extensions] and the signature proving its validity, which is gained via a signature signing request. To be clear, you’re never going to literally “generate a certificate from a CA”, since the idea is that any computer can generate a key-pair, but rather the chain of trust is determined by the signatures on those pairs being from a CA that is manually or already trusted.

When you request a certificate from a PKI service, what’s actually happening is a key-pair is generated out of thin air and then the public key is [automatically] signed by the CA. So, in the scenario that you have to provide a CSR to accomplish a certificate-bound-task, you’re actually just generating a key-pair and signing the public key of that pair, with the CSR format containing all the extensions needed to make it applicable.

Formats and extensions are also another pain-point when handling certificates. Really, there’s only a couple, Base64 and Binary. Windows likes to use Binary formatting, but any certificate can be converted between the two since it’s technically the same data regardless. Base64 formatting is preferrable because it’s essentially just a text file and can be opened, copied, and pasted easily. See the following link for more details.

Ref. https://www.tutorialsteacher.com/https/ssl-certificate-format

Once again, this is just my understanding of the topic, so feel free to correct any mistakes.