PKI Consortium blog

Posts by tag CRL

    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. In order to solve the problem of setting up DNS without too much complication, Sandstorm announced the release of Sandcats.io. Sandcats.io is a free DNS service which takes 120 seconds to go from an empty Linux virtual machine to a working personal server with a DNS name and HTTPS. The DNS service runs on the sandcats.io server while the “personal server” runs on each individual customers’ computers.

    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.

    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.

    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.

    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.

    Participate in our community discussions and/or join the consortium