PKI Consortium blog

What Are Subordinate CAs and Why Would You Want Your Own?
June 26, 2019 by Doug Beattie (GlobalSign) CA/Browser Forum Chrome Code Signing CRL ECC eIDAS Encryption EV HSM Identity Microsoft OCSP PKI Policy Revocation RSA S/MIME SSL/TLS

Digital certificate and PKI adoption has changed quite a bit in recent years. Gone are the days where certificates were only synonymous with SSL/TLS; compliance drivers like stronger authentication requirements and digital signature regulations (e.g. eIDAS) have greatly expanded the role of PKI within the enterprise.

As PKI usage has expanded, conversation has moved beyond just the number and type of certificates needed and onto deeper dialogue about custom PKI deployments. A large part of the conversation is around subordinate CAs, sometimes referred to as Issuing or Intermediate CAs, and why an organization might want their own. Let’s discuss.

Why Is Certificate Expiration Necessary?
October 19, 2016 by Bruce Morton (Entrust) Attack CA/Browser Forum EV Hash Function Identity OCSP Policy RSA SSL/TLS Vulnerability

The Long Life Certificate – Why It Doesn’t Exist

Why is certificate expiration even necessary? Wouldn’t it be better if I could just buy a certificate with a long life before expiration? It would really simplify certificate management if it could be installed and forgotten. Simple, no management required, just file-and-forget.

Extra Trips are for Frequent Flyers, Not SSL/TLS Performance
October 30, 2014 by Wayne Thayer Firefox Forward Secrecy Google HSTS OCSP Revocation RSA SSL/TLS

TLS is quickly becoming a de facto requirement for every website due to increased concerns about spying and Google’s recent move to use HTTPS as a factor in search engine ranking. In a recent article we explained how HSTS helps website operators to ensure that their site is always using TLS, but now we want to ensure that your performance isn’t sacrificed in the name of enhanced security. While the myth that TLS slows down a website has been debunked, some basic settings can make a site using TLS even faster.

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.

In the Wake of Unauthorized Certificate Issuance by the Indian CA NIC, can Government CAs Still be Considered “Trusted Third Parties”?
July 24, 2014 by Ben Wilson CA/Browser Forum CAA CASC Chrome ETSI Firefox Google Microsoft Mis-issued Mozilla OCSP PKI Policy Revocation SSL/TLS Trust List WebTrust

Short answer: Government CAs can still be considered “trusted third parties,” provided that they follow the rules applicable to commercial CAs.

Introduction

On July 8 Google announced that it had discovered several unauthorized Google certificates issued by the National Informatics Centre of India. It noted that the Indian government CA’s certificates were in the Microsoft Root Store and used by programs on the Windows platform. The Firefox browser on Windows uses its own root store and didn’t have these CA certificates. Other platforms, such as Chrome OS, Android, iOS, and OS X, were not affected. See http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html

CASC Heartbleed Response
May 8, 2014 by CA Security Council CASC Chrome CRL Google Malware OCSP Revocation SSL/TLS

The recent Heartbleed issue has reawakened interest in SSL certificate revocation (see Adam Langley’s blog, Larry Seltzer’s articles here and here, and Steve Gibson’s web pages)

Several years ago, the CA Browser Forum convened a special Revocation Working Group to explore issues and solutions. Leading CAs were actively involved in that group, and many of them invested in moving their OCSP responders to high-performance, high-availability Content Delivery Networks (CDNs) to respond to browser vendors’ requests for increased performance and reliability.

Revocation – A Cure For the Common Heartbleed
April 28, 2014 by Jeremy Rowley Attack CASC Chrome CRL Google Identity OCSP Revocation SSL/TLS

The Heartbleed bug spurred server administrators worldwide to work closely with Certification Authorities (CAs) in rekeying and reissuing potentially vulnerable SSL certificates. Part of this effort included revoking existing certificates used on vulnerable servers to ensure obtained private keys are not later used in a man-in-the-middle attack against the website. Unfortunately, in recent days, certain news reports and blogs addressing certificate revocation and checking for revoked certificates online have failed to discuss the benefits of revocation, instead focusing on the minority of circumstances where widely deployed revocation is not perfect. In the interest of providing balanced information to the public, we, as members of the CA community and as individuals generally interested in a high level of Internet security, would like to help clarify some of the issues confused by these reports and blogs.

Certificate Reputation
March 28, 2014 by Bruce Morton (Entrust) Microsoft MITM OCSP PKI SSL/TLS

One of the advantages of having multiple certification authorities (CAs) from which to choose an SSL certificate is that customers have flexibility to choose a CA that meets their specific needs, or even use a number of CAs for redundancy or to have access to a broader toolset. The disadvantage for end users, however, is that they often may not know if a particular CA was authorized to issue the certificate, and there could be a chance that the certificate was fraudulently obtained.

CA Security Council Members Presentation at RSA 2014 Conference: New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet
March 17, 2014 by Kirk Hall (Entrust) Attack CAA CASC Chrome EV Google IETF Microsoft Mis-issued OCSP Revocation RSA SSL/TLS Vulnerability

CA Security Council (CASC) members Trend Micro, Go Daddy, and Symantec participated in a discussion panel at the 2014 RSA Conference in San Francisco on February 24 entitled “New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet.” Panel members included Kirk Hall of Trend Micro (Moderator), Wayne Thayer of GoDaddy (Panelist), and Rick Andrews of Symantec (Panelist).

Introduction to the Topic

Hall began by introducing the topic – all three alternative technologies (Certificate Transparency or CT, Certificate Authority Authorization or CAA, and Certificate Pinning) are intended to make the internet safer by dealing with mis-issued digital certificates, including so-called “rogue” certs like those obtained by a hacker from the now-defunct Diginotar Certification Authority (CA). Mis-issued certs generally present the greatest potential danger when they are for the most popular fraud target domains, such as mail.google.com, login.yahoo.com, login.live.com, etc.

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.