PKI Consortium blog

Who Sets the Rules Governing Certification Authorities?
August 19, 2014 by Kirk Hall (Entrust) CA/Browser Forum Code Signing DV Encryption ETSI EV Google Hash Function Identity IETF Microsoft Mozilla OCSP Policy Revocation Root Program SSL/TLS WebTrust

Every time something positive is published about SSL and encryption,such as Google’s recent decision making use of https encryption a favorable rating factor for a website, or negative, such as the Heartbleed issue – bloggers and others always post questions about public Certification Authorities (CAs), including general questions on who sets the rules that govern CAs. Some bloggers seem to assume there are no rules or standards, and that CAs can operate without any requirements or limitations at all — that’s incorrect.

Think Twice Before Using DV for E-Commerce
March 12, 2014 by Dean Coclin DV Encryption EV OV Phishing SSL/TLS

In a previous blog (What Are the Different Types of SSL Certificates?), we described the various types of SSL certificates available from publicly trusted Certificate Authorities (CAs).  CAs are often asked by their customers which certificate type should be used for websites conducting E-Commerce, rather than for just encryption of sensitive data. For the latter case, a Domain Validated (DV) certificate will work fine. A DV cert allows for encryption to take place between the browser and the server. However, because DV certificates do not contain any identification information, they SHOULD NOT BE USED for E-Commerce.  Why? Let’s look deeper at the differences between these certificates.

How Organizations Are Authenticated for SSL Certificates
November 22, 2013 by Kirk Hall (Entrust) CA/Browser Forum CSR DV EV Identity OV Phishing Policy SSL/TLS

Certification Authorities (CAs) are trusted third parties that authenticate customers before issuing SSL certificates to secure their servers.

Exactly how do CAs authenticate these organizations? And where are the rules that determine what CAs must do during authentication?

The Rules on Customer Authentication

In the past, there were no common rules applicable to CAs as to minimum steps required to authenticate a customer before issuing an SSL certificate. Instead, each CA was permitted to create its own authentication processes, and was only required to describe the process in general terms in its public Certification Practice Statement (CPS). In many cases, the CPS authentication description was vague and hard to understand, and some CAs were less diligent than others during authentication.

What Are the Different Types of SSL Certificates?
August 7, 2013 by Dean Coclin DV Encryption EV Identity Phishing SSL/TLS

Domain Validation (DV)

A Domain Validated SSL certificate is issued after proof that the owner has the right to use their domain is established. This is typically done by the CA sending an email to the domain owner (as listed in a WHOIS database). Once the owner responds, the certificate is issued. Many CAs perform additional fraud checks to minimize issuance of a certificate to a domain which may be similar to a high value domain (i.e. Micros0ft.com, g00gle.com, b0fay.com). The certificate only contains the domain name. Because of the minimal checks performed, this certificate is typically issued quicker than other types of certificates. While the browser displays a padlock, examination of the certificate will not show the company name as this was not validated.

Self-Signed Certificates Don’t Deliver Trust
April 2, 2013 by Bruce Morton (Entrust) CRL DV EV NIST OCSP Policy SSL/TLS

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

• Owner says who they are
• Owner issues on their own policy
• Owner is responsible for quality
• Owner may not follow industry guidelines
• Owner may not provide certificate status
• Compromised certificates may not be able to be revoked
• Owner is not audited
• Issuer of certificate may not be authorized by the domain owner
• Certificates may not be renewed if there are no reminders
• Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-Trusted CA-Signed Certificate Model

• CA verifies the owner of the domain and the certificate applicant
• CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
• CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
• CA updates policy based on industry best practices
• CA provides certificate status through CRL and OCSP
• Compromised certificates can be revoked
• CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
• Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
• CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
• Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.