In the previous article of the series, we understood that TLS certificates are required to prove the identity of a server and entity behind the server — when a browser connects to it, just like a passport proves the identity of an individual. Like government agencies that issue passports after completing the due diligence, we need a trusted central authority/organization to undertake the due diligence before issuing a TLS certificate to an organization – this organization is called a Certificate Authority (CA).
There are two types of CAs – public and private.
Public and Private CAs
Public CAs are commercial ventures where you can buy TLS certificates for a price. There are significant technical and compliance barriers to become a public CA. Some top commercial public CAs are companies like IdenTrust, DigitCert, Comodo SSL etc. Realizing SSL certificates is foundation of web security has given rise to nonprofit public CA, like Lets Encrypt , which as on date has issued 300+ million free TLS certificates.
If you are a public CA, you need to work with all browsers, operating system vendors, hard/soft phone vendors to ensure your root certificate is recognized by them. This activity is conducted through the CA/Browser industry bodies like CA/Browser Forum formed in 2005 to promote industry standards and baseline requirements for internet security.
Many large enterprise software vendors also have their own private CA offering. This is mainly to help the various components from that vendor interact easily/seamlessly by using the certificates issued by the private CA. For example, Avaya Aura System Manager can act as a Certificate Authority out of the box. One can use System Manager’s CA to secure the communications between Avaya Aura® components, Avaya Oceana®, Avaya Breeze® platform, Avaya Analytics™ components, and all the other surrounding components in the solution.
Once the CAs have met the baseline requirement defined by CA/B forum, each vendor(browser, operating systems, soft phone, hard phones, email clients) may have additional compliance /technical requirements to ship a particular CA root certificate as part of their standard installation. For example, the process to get your CA root certificate into the Chrome Trust Store is documented at https://www.chromium.org/Home/chromium-security/root-ca-policy/
Types of Certificates Issued by CAs
CISCO has documented which CA root certificates are shipped and work out of box with their phones. Similarly, Voice vendors like Genesys or AVAYA have their policies before they can include a CA root certificate as part of their soft/hard phone. RedHat relies on a Mozilla included certificate list to decide which CA certificates to include in its O.S (Operating System) releases.
CAs can issue the following types of certificates
Domain Validated (DV) Certificate: This is the most basic type of TLS certificate. It only verifies that the domain name associated with the certificate is registered and controlled by the applicant. This type of certificate is typically issued quickly and is the most affordable
Organization Validated (OV) Certificate: This type of certificate provides a higher level of validation than a DV certificate. The certificate authority verifies the organization’s identity, as well as the domain name ownership. OV certificates are typically more expensive than DV certificates and take longer to issue.
Extended Validation (EV) Certificate: This is the highest level of validation for TLS certificates. It provides the most comprehensive verification of the organization’s identity, domain ownership, and legal existence. The certificate authority conducts a thorough investigation of the organization before issuing an EV certificate. This type of certificate is typically used by banks, financial institutions, and other high-security websites.
Wildcard Certificate: A wildcard certificate is a TLS certificate that secures a domain and all its subdomains. This type of certificate is useful for organizations that have multiple subdomains, as it eliminates the need to obtain and manage separate certificates for each subdomain.
Multi-Domain/SAN Certificate: This type of certificate allows you to secure multiple domain names with a single certificate. You can secure up to 100 domain names by using a multi-domain/SAN certificate.
Code Signing Certificate: A code signing certificate is used to sign and verify the authenticity of software code. This helps prevent malware and other malicious software from being distributed and installed on users’ devices. Code signing certificates are typically used by software developers and publishers.
S/MIME Certificate: An S/MIME (Secure/Multipurpose Internet Mail Extensions) certificate is used to encrypt and digitally sign email messages. It ensures that email messages are not tampered with during transmission and that the sender’s identity is verified. S/MIME certificates are typically used by businesses and organizations that need to send sensitive information via email.
In the last article, we saw how an expired certificate can create havoc for you, so before we wrap up this article, let’s look at some breaches or hacks from the past which can be purely attributed to CA failed policies or governance.
Certificate Authority Lapses and Their Impact on Business
In 2011 DigiNotar was a well-established and reputable certificate authority. It was one of the root CAs for all the major web browsers and issued many of the digital certificates used by the Dutch government for its online services. It took security seriously but one unpatched server compromised CA certificate issue infra leading to its eventual bankruptcy
In 2017, Google decided to distrust Symantec because it had lost faith in Symantec’s certificate-issue policies. Apparently, Google had raised concerns to Symantec about several incidents of mis-issued certificates. An internal audit from Symantec pointed to 30000+ mis-issued certificates over a few years. A few months later, Symantec sold off its certificate-issuing business to DigiCert.
We often tend to blame technology failure for a security breach, which is not always the case. The incidents mentioned above were purely due to human failures or governance issues at Certificate Authorities.
In future articles in this series, we will continue to look at how the technology, people & process dimension have and will impact the progress of internet security.
About Assertion
At Assertion, we’re committed to helping companies see a direct impact on call answer rates, experience better integration of their voice channel data, and secure their customers and themselves from voice scams.
Assertion® SecureVoice™ gives you complete control and visibility into each incoming call and every outgoing call from your company. This means that you now can
- Increase outbound call answer rates by verifying your calls
without using third-party apps - Prevent vishing and impersonation calls on your customers
with live identity assurance capabilities integrated into your website or app - Secure your business, employees, and data from voice scams and attacks
by screening every incoming and outgoing call in real time
You can see all this in action – in your setup.
Sign up for a 30-day no-obligation trial of Assertion® SecureVoice™