PKI Consortium blog

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.

Certificate Chains, Key Management and the Number of CAs Counted by Web Crawlers – Oh My
November 4, 2013 by Ryan Hurst CRL Microsoft OCSP PKI Policy Revocation SSL/TLS

Have you ever wondered why your web server certificate has a “chain” of other certificates associated with it?

The main reason is so that browsers can tell if your certificate was issued by an organization that has been verified to meet the security, policy and operational practices that all Publicly Trusted Certificate Authorities are mandated to meet. That certificate at the top of the chain is commonly called the “root.” It’s signature on a certificate below it indicates that the organization operating the root believes that practices of the CA below it meets that same high bar.

Certificate Authority Audits and Browser Root Program Requirements
October 15, 2013 by Kirk Hall (Entrust) AICPA CA/Browser Forum CASC ETSI EV ISO ITU Microsoft Policy Qualified Root Program SSL/TLS WebTrust

Recent news stories have highlighted the need for strong security in online communications, and use of SSL certificates issued by a publicly trusted Certification Authority (CA) is perhaps the best way to achieve that. But why should the public trust SSL certificates issued from commercial CA roots, which are embedded as trust anchors in web browsers?

One answer is because of the multiple layers of standards and tough requirements that all commercial CAs must meet – and for which they are audited every year. These standards and requirements have increased from year to year over the past decade.

What is Certification Authority Authorization?
September 25, 2013 by Rick Andrews CAA IETF Policy SSL/TLS

DNS Certification Authority Authorization (CAA), defined in IETF draft RFC 6844, is designed to allow a DNS domain name holder (a website owner) to specify the certificate signing certificate(s) authorized to issue certificates for that domain or website. Usually, the certificate signing certificate will belong to the Certification Authority (CA) that issues SSL certificates to you. It’s a way for you to indicate which CA or CAs you want to issue certificates for your domains. Using CAA could reduce the risk of unintended certificate mis-issuance, either by malicious actors or by honest mistake.

Some Comments on Web Security
June 5, 2013 by CA Security Council Attack CA/Browser Forum CASC Google IETF Microsoft Mis-issued Policy SSL/TLS

Steve Johnson of the Mercury News posted an article on Web security and highlighted some of the issues.

The posted issues help to explain why we created the Certificate Authority Security Council. We want to determine the issues, have them addressed and provide awareness and education on the solutions. The CAs also work with the browsers and other experts in the industry to develop standards for all CAs to be audited against through the CA/Browser Forum.

CASC Happenings at NIST
April 10, 2013 by CA Security Council CASC NIST PKI Policy SSL/TLS TSP

This week members of the CASC will be attending and speaking at the NIST Workshop on Improving Trust in the Online Marketplace. You can also follow the CASC on Twitter for more information and news at @CertCouncil, as well as see some of the presentations after the events on our SlideShare page. Even if you can’t make it to Maryland, you can still watch the event via the live webcast. Please join us for the following CASC member events:

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.

IETF 86 – Web PKI Working Group
March 21, 2013 by Bruce Morton (Entrust) CRL Google IETF OCSP PKI Policy Revocation SSL/TLS Web PKI

At the IETF 86 meeting in Orlando last week, there was a working group meeting discussing the operations of the Web PKI. At the previous IETF 85 meeting a birds-of-a-feather was held to discuss the purpose of having such a group. The result of the meeting was an established group with the charter that states purposes such as:

• Working group will work to improve the consistency of Web security behavior
• Address problems as seen by the end-users, certificate holders and CAs
• Describe how the Web PKI actually works
• Prepare documented deliverables as discussed below

The meeting discussed the charter and the four following deliverables. More information is in the presentation slides; look under the Operations and Management Area, then under WPKOPS.

RSA Recap – Securing Your Site
March 8, 2013 by Ben Wilson BEAST CASC Encryption Firefox Hash Function HSTS OpenSSL Policy RSA SSL/TLS TLS 1.1 TLS 1.2 Vulnerability

At RSA last week a few of us participated in panel discussions that focused on SSL/TLS. During the panel that I moderated on Friday, one theme we addressed was secure server configuration. One of CASC’s goals is to help harden existing SSL/TLS implementations against vulnerabilities—because most SSL/TLS exploits arise from suboptimal website configurations. These vulnerabilities and attacks can be mitigated or even eliminated with proper server configuration and good website design.