PKI Consortium blog
Posts by author Jeremy Rowley
The Latest on Certification Authority Authorization
March 21, 2017 by
Jeremy Rowley
Attack
CA/Browser Forum
CAA
Encryption
Identity
OV
PKI
Policy
Qualified
Things are certainly heating up at the CA/Browser with exciting proposals surrounding inclusion of the Wi-Fi Alliance (WFA) as a subjectAltName otherName, new validation methods, and debates over how the CAB Forum will continue operating. One of these newly passed ballots requires all CAs to check and process a domain name’s DNS Certification Authority Authorization (CAA) resource record prior to issuing a digital certificate.
Background
RFC 6844 created CAA records as a method for domain owners to specify a policy on which certificate authorities are authorized to issue certificates for the associated domain. The basic concept is that immediately prior to issuance, the certificate authority (CA) will check the CAA record and determine whether policy permits creation of the certificate. Issuance is permitted if either a CAA record does not exist for the domain or the CAA record lists a string specified by the CA as authorizing the CA to issue the certificate. Using CAA records, the domain owner is able to control policy at a more granular level, including specifying which CA can issue wildcard certificates and how to report issues. Note, that CAA record checking is an additional requirement that occurs after the CA completes the normal domain verification process required by the CA/Browser Forum’s baseline requirements under Section 3.2.2.
Google Certificate Transparency (CT) to Expand to All Certificates Types
November 8, 2016 by
Jeremy Rowley
Announcement
CA/Browser Forum
Chrome
DV
EV
Google
IETF
OV
Policy
SSL/TLS
The policy change goes into effect October 2017
A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser.
SSL Certificate Validity Periods Limited to 39 Months Starting in April
February 19, 2015 by
Jeremy Rowley
CA/Browser Forum
ETSI
Policy
SSL/TLS
Vulnerability
WebTrust
In accordance with the CA/Browser Forum Baseline Requirements, effective April 1, 2015, Certificate Authorities (CAs) will no longer be able to issue SSL Certificates with a validity period longer than 39 months.
Shortening the validity period to 39 months is the result of much consideration within the CA/Browser Forum to arrive at a duration that allows optimal usability while maintaining the tightest network security. A shortened validity period will significantly improve Internet security by requiring administrators to renew and verify their certificates more often. It will also make it easier for users to keep up-to-date on new advances in security and remain aware of their control over private keys.
Code Signing Baseline Requirements
October 20, 2014 by
Jeremy Rowley
CA/Browser Forum
CASC
Code Signing
Malware
Microsoft
Vulnerability
Code signing certificates are used to sign software objects to authenticate that they originated from a verified source, allowing developers to avoid warnings commonly displayed by application software vendors such as Microsoft operating systems and Java. A fraudulent code signing certificate can wreak havoc on networks, spreading malware and adware without restraint. Certificate Authorities are tasked with ensuring that code signing applicants are legitimate entities and provide accountability for use of the certificate.
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.
Heartbleed Bug Vulnerability: Discovery, Impact and Solution
April 9, 2014 by
Jeremy Rowley
Attack
BEAST
CASC
CSR
DTLS
Encryption
Google
OpenSSL
SSL/TLS
TLS 1.0
TLS 1.1
Vulnerability
On April 7, 2014, a vulnerability in the OpenSSL cryptographic library was announced to the Internet community. Aptly labeled as the Heartbleed bug, this vulnerability affects OpenSSL versions 1.0.1 through 1.0.1f (inclusive). The Heartbleed bug is not a flaw in the SSL or TLS protocols; rather, it is a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. The flaw is not related or introduced by publicly trusted certificates and is instead a problem with server software.
Reducing the Impact of Government Spying
April 4, 2014 by
Jeremy Rowley
CASC
Encryption
Forward Secrecy
Malware
PKI
RC4
RSA
SHA2
SSL/TLS
TLS 1.1
Vulnerability
Last year, Edward Snowden, an American computer-specialist working as a contractor for the National Security Agency (“NSA”), shocked web-users around the world by publicizing documents showing that the NSA was gathering intelligence on Internet users. The realization that the US government was gathering sensitive information has led to a worldwide demand for better protection of online communication and data and a general worry about the effectiveness of existing infrastructures. Specifically, some entities have asked whether PKI is still a robust way to protect online information.
ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
December 18, 2013 by
Jeremy Rowley
Announcement
CA/Browser Forum
CASC
ICANN
MITM
Mozilla
PKI
Policy
Qualified
Revocation
SSL/TLS
Vulnerability
After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .corp and .home reserved as high risk gTLDs. This post serves as an advisory for interested network administrator on how the newest ICANN decisions may affect their networks and certificates.
Improving Code Signing
November 14, 2013 by
Jeremy Rowley
CA/Browser Forum
Code Signing
Identity
Malware
SSL/TLS
Previously, we discussed how code signing certificates play a key role in the trust framework by proving the authenticity of software. As mentioned, code signing certificates act as a certification that the software was unmodified after publication. Although current code signing practices greatly reduce the threats of malware and adware embedded in signed objects, the sophistication of threats has risen and there is a need for improvement. When code signing was new, skilled criminal hackers were the exception and script kiddies were the norm. Now, the skill level and sophistication of criminal networks, and even nation states, have advanced to the point where customized malware is being used to penetrate company networks, steal valuable information, and even tamper with sensitive infrastructure.
Securing Software Distribution with Digital Code Signing
October 16, 2013 by
Bruce Morton
(Entrust),
Jeremy Rowley
CASC
Code Signing
Malware
SSL/TLS
Code signing certificates from publicly trusted Certification Authorities (CAs) fulfill a vital need for authentication of software distributed over the Internet in our interconnected world. As the commonly referred to “Internet of things” continues to grow, consumers have access to millions of applications for their desktops, laptops, and mobile devices. Creative software engineers provide us with applications to cover any of our potential needs or interests. Cybercriminals and others with malicious intent recognize this as an opportunity and seek to trick us into installing malicious software (malware) — programs that hijack our computers, steal our money, or try to inflict harm.