I don't understand any of this. Could you explain what to do like I'm 5?
I’ve got some time to kill, so here goes…
This is probably going to be a massive oversimplification…
Certificates are used for a bunch of different purposes, but fundamentally they are used to perform security-by-encryption.
Certificates effectively are made up of two parts. A private key, and a public key. The “owner” of a certificate receives both parts. The owner will use the private key to encrypt data before it is sent to the “consumer”. The consumer will receive the encrypted data and will need the public key to decrypt it.
The unwritten assumption here is that the consumer(s) all have a copy of that public key, or that any given certificate can be validated. This introduces the concept of a hierarchy of certificate signing.
Certificate signing can be visualised as a “pyramid of trust”. At the apex of the pyramid are a small number of Root Certificate Authorities (RCAs). These RCAs are “trusted” companies who own a ROOT CERTIFICATE. You may have heard of some of these companies (such as Verisign, DigiCert, and
many others…). These RCAs will have a root certificate and typically a number of INTERMEDIATE certificates. The pyramid starts to build because the intermediate certificates are SIGNED by the root certificate. This signing establishes a CHAIN OF TRUST, it “proves” that the intermediate certificate is trusted by the root certificate.
Commercially, any company or end user can request their own certificate(s) by applying to one of the RCAs. The application process is typically called a CERTIFICATE SIGNING REQUEST (CSR). The RCA will typically validate your request. For example, if you are a company requesting a certificate for your web server, the RCA should run domain checks, and company registration checks, along with other checks in order to validate that your are who you claim to be. Once they are satisfied, then they will issue you a certificate signed by one of their intermediate certificates.
The chain of trust is now: your certificate … the RCA’s intermediate certificate … the RCA’s root certificate.
It all hinges on trust. You trust the RCA to be stable, and they implicitly trust your application (you are who you say you are, and that you will use your certificate for the purpose your requested).
For day-to-day usage, the most common use is for your company to encrypt your web site data using secure HTTP (HTTPS). You use your private key to encrypt, and part of the secure handshake exchanges the public key with your visitors. From the perspective of the web browser, the public key is received from the server, and then the web browser (MS Edge, Mozilla Firefox, Apple Safari, etc…) will VALIDATE the certificate it received by checking the chain of trust, something like:
The received cert is signed by well known RCA intermediate certificate.
Check that the intermediate certificate is still valid.
Assuming “valid”, the intermediate certificate is signed by the root certificate.
Check that the root certificate is valid.
So long as those checks are all okay, then the chain is trusted, and the browser will use the certificate to encrypt/decrypt the data between the web browser and the web server.
In order to perform these checks quickly and efficiently most operating systems ship with copies of the root certificates and their intermediate certificates. Having said that, all certificates have an expiry date. Therefore there must be a mechanism for updating those shipped certificates.
Apple uses the “Keychain” to hold those copies of trusted certificates. There is a Keychain Assistant app in Applications:Utilities.
When a shipped certificate is about to expire, a new version of the certificate will be “ready” to replace it. By convention, the operating system vendors will use their software update mechanisms to update the new/replacement certificates. However, when an operating system drops out of support, your machine will no longer be getting certificate updates. At some point one or more of the certificate copies on your machine will expire. That’s when you will notice the “unable to connect” errors when you’re browsing the WWW.
You can accept the loss, or upgrade your OS (if possible), or buy a newer computer that has a later supported OS, or you can manually try to sort it out by downloading the revised root/intermediate certificate and install it to the correct place.
For Mac OS, that means using the Keychain Assistant app. There are two steps:
- Install the certificate
- Trust the certificate
The other members have linked to articles where some of them link to how-to do these steps.
(I’ve deliberately ignored the whole revocation of certificates, this is where the certificate issuer can revoke a certificate if the certificate is compromised, or the business has gone out of business, etc…)
In layman’s terms, certificate validation is a simple chain of trust. For HTTPS connections, your web browser will check that the certificate it received from the web server is valid. Typically there two or three (or occasionally more) links in that chain. All the certificates in the chain must be valid before your web browser will fetch data from the web server.
forums.macrumors.com
