| RUNNING This could take a few minutes...
Digital certificates in the computer and networking world are a tool used to build trust between a customer or client and the server or data provider on a network or over the internet. Below contains information about what Certificates are used for, how they work and what are the standard set of components of a digital Certificate.
The building of trust is not only a logical trust in computer language, but also a sense of reassurance for the people involved with communicating over otherwise insecure channels through the internet of other unregulated computer networks. The use of a digital certificate ensures a high level of confidence that there are no third parties between the client and server who are reading the traffic as it passes over the wire. From a packet level, it is possible to see that Host A is communicating with Host B, but the payload of that communication is encrypted. The Client’s confidence level is dictated by their trust in the signing Certificate Authority’s (CA) reputation in the security realm of the internet. There have been cases in the past where a CA was hacked and invalid certificates were issued (Ex. DigiNotar 2011) which allowed hackers to read the content of “secure” communications via man-in-the-middle attack. These types of security breaches are the types of things that bankrupt companies.
How they work
Digital Certificates use the Public Key Infrastructure (PKI) . Wikipedia defines PKI as, “a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.” Typically, a person or company that has information they would like to securely share with another entity will generate a Certificate Signing Request (CSR) and Private Key then pay a Third Party Trusted Certificate Authority (CA) to sign the certificate using the CSR. The CSR contains information about the Distinguished Name for the certificate, Company information. The Private Key is not provided to the CA, it remains private to the data owners and should not be shared with anyone. After the CA signs the certificate, they provide a Public Key. This key is what clients use to decrypt the payload of the communications.
The Trust and integrity of the CA is important since they are the third party stating, “Yes, we agree this company is who they say they are,” Certificate Authorities which are trusted also have public certificates installed in your “Trusted Certificate Authorities” store in your computer’s certificate store. When accessing a secure site on the internet using a web browser, the certificate presented by the website is loaded, the CA is looked up in your trusted certificate store and if it’s found and the certificate is valid, your browser will load the page with no errors or alerts. If the CA on the certificate is not in the trusted certificate store, the browser will likely display a warning message that the certificate is not trusted or is invalid. The certificate store is occasionally updated during browser updates, or in the case of windows, Microsoft Updates.
A Certificate chain is a hierarchy of all the certificates and their upper level CAs. The top level CA is called the anchor or root CA, these are the top level Certificate authorities who designate “intermediate certificate authorities” which are second level authorities who are entrusted to sign certificates on behalf of the root CAs. A complete and valid certificate chain is when a client is able to read a server’s Public key, the CA that signed that certificate and the CA that signed the intermediate CA.
Public and Private Keys:
The Public and Private key pair are related in that data encrypted with the Public key can only be decrypted with the Private key, or data encrypted with the Private key can only be decrypted with the Public key. When data is to be encrypted for transport, a digital signature needs to be created.
- The data sender calculates a Hash of the data to be sent.
- The hash is encrypted with the server’s private key, which is now referred to as the Digital Signature.
- The data and digital signature are sent to the client which then decrypts the digital Signature using the Public key of the server.
- The client calculates the hash of the data and compares it to the hash of the unencrypted digital signature to make sure they are identical.
- If they are the same, the message is considered to be valid.
PKI certificates follow the X.509 certificate standard. This standard defines the format of the data stored in the certificate. Each certificate contains information about the Version number, serial number, Signature Algorithm ID, Issuer Name, Validity Period, Subject Name, and Subject Public Key Info. Some optional pieces of information are the Issuer Uniqie Identifier, Subject Unique Identifier, and any Extensions.
The Subject Name is the company or person information for the certificate.
The Issuer is the third party CA information, aka the Certificate Signer.
The validity period of a certificate is represented as a start and end date. The fields are named “Not Before” and “Not After.” When a certificate is presented to a client, they validate the date on the certificate using their computer time/date. The “Not Before” date of the certificate is usually the same date the certificate was signed.
Another notable field in the certificate is Subject Alternate Name, this can be an array of DNs or a DN with a wildcard (*) on it. These certificates are known as SAN certificates and are used when more than one DN or hostname needs the ability to use one certificate.
Last Updated: February 13,2017