There has been a lot of misleading information flying around within the security industry and various tech blogs regarding Certificate Authorities (CA), Security, and the function of SSL Certificates. Lots of finger pointing with no foundation of knowledge on who does what. The confusion is how encryption keypairs work, controlled, and managed, vs what Certificate Authorities (CA) actually do when they issue their different certificate products, and how browsers enforce the security behind SSL Certificates. Security is not all in the hands of the Certificate Authorities (CA). It all started with a CA named VeriSign.
What/Who Are The Certificate Authorities?
VeriSign headquartered in Virginia became one of the world’s first and biggest CA, providing third party authentication of public keys used for encryption. This provided legitimacy to the internet in a time where there were no standards to online encryption or authentication to who was actually running websites. As the industry grew and the need for more digital certificate auditing was needed other CAs sprouted around the world such as Thawte and Geotrust/Rapidssl. Eventually VeriSign acquired the other CAs through acquisitions but they still functioned independently within VeriSign. Over the years many other CAs have developed. All one needs to do to become a CA’s is create their own root certificate and put in a petition to the CA/Browser Forum, and various operating system software application developers like Apple or Microsoft.
Symantec later on down the road acquired VeriSign’s CA division, which not only had their flagship certificate products (Now Symantec) but also had smaller certificate authority subdivisions that featured their own certificate products. These are managed and handled differently. A certificate product from the DV (Domain Validated) RapidSSL division is by no means handled the same way as a Verisign/Symantec issued certificate product.
Not All SSL Certificates or CA’s Are The Same.
Back when SSL Support Desk was a student majoring in Computer Information Systems my professor used Domain Validated (DV) certificates such as the ones provided by RapidSSL or Comodo to become familiar with the process of key encryption. Learning how public keys are handled, processed and vetted from CAs varies from the level of authentication and the different SSL products they provide.
A DV issued certificate is a simple certificate that does not provide any insights into authentication. Basically a DV certificate will state that the website owner of www.domain.com for example is owned and operated by www.domain.com. DV certificates state nothing about who is managing the website or application, and this can be a issue when depending on how web browsers depict visually the different levels of authentication.
I would never buy anything from a ecommerce website without knowing the company that is responsible for running it. Primarily DV issued certificates were just meant for internal testing or they are setup by website hosting providers for initially building websites, bare minimum validation encryption, but that has changed with Let’s Encrypt.
The DV Certificate Issue.
Let’s Encrypt is a certificate authority supported by various companies such as Hostpoint, Zendesk, and Google Chrome. Its concept is basically a road to hell paved with good intentions. Its seducing 100% automation and free cost was to strive to secure the internet with encryption, but it has actually opened the doors to hackers/phishers all over the world. This automation of DV only certificates leads Let’s Encrypt to issue bad certificates to “PayPal” phishing sites everyday. This creates a huge Security loophole that hackers exploit. Hackers tend to not want to spend any money when they know they can exploit something for free. Web browsers unfortunately do not understand the differences of a phishing website compared to an actual one, and so particularly dangerous websites are being marked as trustworthy then really they are not.
Higher Levels of SSL Certificate Authentication OV & EV.
Other more secure SSL certificates that are issued are Organization Validated (OV) or Extended Validation (EV) certificates. Which are a higher standard of Authentication. In the above image of the two side by side PalPal sites the one on the left that states PayPal, Inc. is a EV certificate which requires a human element of auditing than that of a DV certificate. Authentication teams of the certificate authorities vet the information of the Organization behind the owner of the website. It used to be that there were great differences on showcasing the different authentication levels but in recent years browsers have changed this visually. When looking at the details of an OV/EV issued certificate you will see that it will contain more information on who is running the website, stating for example “Pay Pal Inc.” A DV certificate will not state the organization. Also, Typically these OV/EV type of certificates have a cost associated with them.
Think of all the different digital certificate from the CA’s as individual products (not all are created equal) Some certificates issued by a CA will feature malware scanning, the ability to display a digital seal for e-commerce, unlimited reissues, etc.. Some CAs depending on their product may have a feature referred to as a revoke and replace. The actual Symantec SSL Certificate retail product line features some key options that are presented to the user/admin of the certificate when a replace is needed. Depending on the scenario will distinguish how the replacement is handled. Its just one of the features of their retail SSL products while a RapidSSL free product may not have this feature.
As an admin purchasing an SSL Certificate It really comes down to understanding your products. Just like buying a car know what you are purchasing and ensure it’s the right fit for you. There are different levels of authentication behind issued certificates DV, OV, and EV. Browsers will showcase these levels of authentication differently, and they change this often. A DV certificate is fine if its just data to data communication or some sort of internal site, but if you are on a banking, medical, ecommerce you may want to think twice. For website visitors remember the PayPal phishing website example provided and proceed with caution.
How Certificate Security Controlled & Who Enforces It?
Each CA has what is known as a Certificate Revocation List (CRL). They include a field within a digital certificate as a reference point for browsers/applications to check to see if a certificate is good or not. At the speed of light a web-browser such as Safari, Firefox, Internet Explorer will check the CRL link that the certificate provides to see if the certificate has been revoked. Firefox and Internet Explorer will not allow you to access a website if the certificate running on it has been revoked. The revocation reasons are many and typically you can still bypass this, but as a user will need to proceed with caution. Encryption will still take place, but you will just see a warning in the browser or a red URL mark. No biggy if you know the reason why or do not care.
For some reason Google Chrome does not check this extension. They do Something called CRL sets. Google gathers Certificate Revocation Lists from “participating” Certificate Authorities, trims the list down to include certificates that “they think are important” and then sends it out to Chrome. This means that the browser doesn’t need to contact the Certificate Authority CRL list and removes possible size performance and privacy overheads. The only problem here is that the list is not definitive. If Chrome does not have a CRL for a particular CA or chooses not to care, it will always trust certificates. I have seen this situation occur many times where a certificate shows it is revoked in an Internet Explorer or Firefox browser but not in Chrome. In addition, modern computers/smartphones have the ability to overcome any performance issues associated with a speed of light security check.
From a technical perspective it is by the design of the browser or application that connects to the system/website that decides to care whether or not a certificate is revoked. Encryption will still take place. Internally many firewalls may not allow browsers or other application to make the callout to a CA’s CRL list for various internal reasons so they could can end up becoming unaware of a revoked certificate.
At its basic fundamentals an SSL Certificate issued by any CA is nothing more than a third party audit. It states that the CA has reviewed the order information and the public key that has been provided, and lastly checks to see if it meets the standards of the industry set by the CA/Browser Forum. If everything checks out then it is issued. After an SSL Certificate is issued everything rests with the technical admin on its management of the public/private keypairs. Some CA’s offer a complete management portal in order to help assist but that functionality can vary and ultimately the CA is not responsible for the secret private key that is managed by the admin. The security portion that a CA can control is from the different levels of auditing they provide and their CRL lists. Yet, this means nothing if a browser or application refuses to acknowledge the CRL list the CA provides, and homogenizes the level of authentication by generic visual representations that goes behind its issuance.
If you would like to read more on the DV certificate issue visit Netcraft’s Article: “Let’s Encrypt and Comodo issue thousand of certificates for phishing.”