PKI Consortium blog

The Advantages of Short-Lived SSL Certificates for the Enterprise
July 18, 2019 by Doug Beattie (GlobalSign) CRL Mozilla Revocation SSL/TLS Vulnerability
Short validity period certificates are becoming ever more common to reduce the scope of data compromised if a server vulnerability is uncovered, such as HeartBleed. Good security practice dictates changing keys on a regular basis, normally annually, but if you want to limit your exposure further, you can replace your certificates and underlying keys more frequently. Sandstorm is an open source server software that makes it easy to install web apps.

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.

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.

IETF 88 – Pervasive Surveillance
November 26, 2013 by Bruce Morton (Entrust) Attack CRL Encryption Forward Secrecy HSTS IETF PKI Revocation SSL/TLS Vulnerability Web PKI
Internet Surveillance The big news at IETF 88 in Vancouver was the technical plenary on Hardening the Internet which discussed the issue of pervasive surveillance. Pervasive surveillance is a mass surveillance of an entire or a substantial fraction of a population. The surveillance is usually carried out by government, is not targeted and its occurrence may not be overt. It was noted that pervasive surveillance, of the kind revealed in the Snowden-sourced documents, constitutes a misguided and damaging attack on civic society in general and the Internet in particular.

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.

The (Soon to Be) Not-So Common Name
October 8, 2013 by Ryan Hurst CA/Browser Forum CRL Encryption Identity IETF Revocation SSL/TLS Vulnerability
If you are reading this post you are probably already familiar with the use of digital certificates and SSL even if you may not be familiar with the history. Before exploring the history of SSL, let’s review at its core what a digital certificate actually is. Fundamentally, a digital certificate is the binding of entitlements and constraints to a key, in other words a digital certificate would dictate the following, “The holder of the private key associated with this certificate can rightfully use the name John Smith when signing emails.

An Introduction to OCSP Multi-Stapling
May 7, 2013 by CA Security Council CA/Browser Forum CRL IETF OCSP Revocation SSL/TLS Vulnerability
OCSP Stapling OCSP is a protocol used to check the validity of certificates to make sure they have not been revoked. OCSP is an alternative to Certificate Revocation Lists (CRLs). Since OCSP responses can be as small as a few hundred bytes, OCSP is particularly useful when the issuing CA has relatively big CRLs, as well as when the client has limited memory and processing power. OCSP can also provide much more timely information than CRLs about the status of a certificate since the information is generally fetched more frequently.

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.

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.